# One Transaction, Every Party Paid What atomic payment splitting actually changes — and why it matters for B2B deals. --- ## The way money normally moves in a multi-party deal Let me describe a deal that is completely ordinary. Three parties are involved: a subcontractor, a platform that brokered the work, and a logistics provider who handled delivery. The buyer sends the total amount to whoever's holding the relationship — usually the platform. The platform then initiates a wire to the subcontractor. Then another to the logistics provider. Each transfer is a separate event. Each has its own confirmation window. Each can fail independently. In multi-hop payment flows, a single transaction may settle across three or four institutions sequentially. Each settlement leg must be confirmed independently before the payment can be considered fully reconciled. In practice this means the subcontractor is waiting on an institution that is waiting on a platform that is waiting on a buyer's bank. Nobody can see the full picture in real time. The problem is structural, not operational. Multi-party settlements bring a significant operations challenge: managing payments across multiple stakeholders, each with their own rules, timelines, and expectations. When those expectations diverge — and they frequently do — someone absorbs the friction. Usually the smallest party in the chain. ### What can actually go wrong Start with timing. Settlement files arrive on different schedules. Currencies get reported at different FX rates. Refunds and chargebacks are categorized inconsistently. A transaction that appears "approved" in one system may show as "pending" in another for 24 to 48 hours. That 24-to-48 hour window is not a rounding error. It is a window during which the subcontractor is owed money but does not have it, and the platform is holding funds that belong to someone else. Then there's counterparty risk. Settlement risk is the risk that one party delivers payment or securities but does not receive the counter-value in return. Pre-settlement risk is the risk of default before the transaction's final settlement. In a three-party sequential transfer, this risk compounds at each hop. If the platform receives funds and then has a banking problem — or simply decides to delay — downstream parties have no recourse except to wait and follow up. Then there's the reconciliation burden. Reconciliation is the one that bites at month-end. Every payout leg — each seller, each commission line, each partner cut — has to be matched back to the single sale that created it. Miss that and a settlement report becomes a pile of outgoing transfers with no obvious link to the order they belong to, and someone spends a day rebuilding the trail by hand. With a single payment provider, a finance team matches two datasets: internal transaction records and one external settlement file. With multiple providers, the team must match internal records against five, ten, or more external datasets simultaneously, each with its own file format, settlement cycle, fee structure, and identifier scheme. None of this is exceptional. Payment reconciliation across multiple providers is one of the most expensive operational problems in payments, and most organizations treat it as a normal cost of doing business. What I want to argue is that it doesn't have to be — not because you can throw software at the reconciliation problem, but because you can eliminate the condition that creates it. ## What changes when the split is atomic The word *atomic* has a precise meaning in computer science: an operation that either completes entirely or does not execute at all. There is no intermediate state where half of it has happened. In a single atomic action, multiple obligations are linked so that partial completion cannot occur. If any required condition fails, the whole set of transfers fails and reverts. Applied to payment splitting, this means: total funds arrive, the contract executes the distribution to every party, and all of those transfers land in the same block. Not sequentially. Not conditionally on downstream steps succeeding. All at once, or nothing. A single transaction can perform an asset exchange between two or more parties — and because the exchange takes place in a single transaction, it comes with a guarantee of atomicity, meaning that all of the asset transfers take place simultaneously, or none take place at all. That is a fundamentally different primitive than what I described above. In sequential transfers, there are as many settlement events as there are parties. In an atomic split, there is exactly one. ### No intermediate state means no one holds your money in transit In the sequential model, the platform holds funds between receipt and distribution. That's not a design choice — it's an architectural inevitability. You can't forward money instantly to three parties through traditional rails, so someone has to be in the middle, holding everything, while the legs complete. Atomic settlement means "all-or-nothing" execution: either every linked leg of a transaction settles, or none of them do. That property eliminates or sharply reduces principal risk by conditioning one final transfer on the other. In an atomic split, there is no moment where the platform holds the subcontractor's share. The funds arrive at the contract and route out to every party in the same execution. The platform never had custody of the subcontractor's portion — it went directly. This isn't a trust question. It's a temporal one. The intermediate state simply doesn't exist. ### All parties paid or none — and why that's the right failure mode The failure mode in sequential transfers is partial completion: the buyer pays, the platform receives, and then the subsequent legs fail or stall. The subcontractor may not be paid. The logistics provider may not be paid. The deal is "done" in the buyer's accounting but unfinished for everyone else. Atomicity inverts this. By using cryptographic guarantees rather than institutional trust, these transactions ensure value transfers either happen completely or not at all. If the split can't complete — if there's a problem with any recipient address, if gas is miscalculated, if any condition in the contract isn't met — the whole transaction reverts. The buyer's funds return. Nothing is half-done. This feels like a harder failure at first. In practice it's a much cleaner one. A full revert is unambiguous. There's nothing to reconcile, no partial state to dispute, no one holding funds that belong elsewhere. Both parties know exactly what happened: nothing. They can retry with correct parameters. Contrast that with a sequential system where leg two completes and leg three fails — now you have an underpayment, a dispute, and an accounting problem that may take weeks to resolve. ## The mechanics, conceptually Here's what the transaction actually does: 1. **Total in.** The buyer sends the full agreed amount to the contract in a single call. 2. **Shares computed.** The contract holds the allocation logic: party A gets X%, party B gets Y%, party C gets the remainder. These ratios are set in the contract terms, agreed in advance. 3. **Simultaneous out.** In the same execution, the contract transfers each party's share to their address. 4. **Same block.** All transfers — every output — land in the same block. From the chain's perspective, they happened at the same moment. The mechanics are simpler than most people expect. At its core, a revenue sharing smart contract has three components: a way to receive funds, a list of recipients with their percentage shares, and a distribution function that sends the right amount to each person. Smart contract arithmetic is deterministic: the same inputs always produce the same outputs. There are no rounding disagreements, no "we paid you wrong this month" corrections, and no deliberate manipulation. The buyer doesn't need to know how the split works internally. The sender does not need to be aware that the funds will be split, since it is handled transparently by the contract. The split can be in equal parts or in any other arbitrary proportion. The buyer sends one transaction. Every party receives their share. The buyer's accounting reflects one payment event. Each recipient's accounting reflects one receipt event. Nobody has to reconcile a payment waterfall. ## Why atomicity is the key property You could build a system that tries to approximate this — a platform that receives a payment and immediately fires off multiple transfers. That's not atomic. Between the receipt and the outbound transfers, there's a window. The platform has custody. The outbound transfers can fail independently. The system has state. Atomicity eliminates that window. Atomic settlement is easiest when both legs are within one deterministic execution environment. It becomes more fragile as soon as it spans ledgers or touches legacy systems. When everything executes in one block on one chain, the question "did everyone get paid?" collapses into a single binary: did the transaction confirm? If yes, every address received exactly its computed share. There is no per-party status to check. The settlement report writes itself from the transaction receipt. This removes whole categories of dispute. In sequential systems, disputes arise from timing differences, from funds held in transit, from the question of who is responsible when leg three fails after legs one and two completed. Pre-settlement risk is the risk that a counterparty will default prior to the expiration date of the contract, prior to the final settlement of the transaction. Settlement risk is the counterparty risk during the settlement process. It arises because the parties do not execute their obligations at the agreed time. Atomicity makes both of these irrelevant. There is no pre-settlement period for the split itself — you're either in the transaction or you're not. There is no sequential obligation that can be skipped. ## Design considerations you actually have to get right Describing atomicity as "the whole thing happens at once" obscures real engineering problems. Here are the ones that matter. ### Share math on-chain Rounding is a practical issue that many teams overlook. If you split 1,000 tokens three ways evenly (33.33% each), you distribute 999 tokens and have 1 token left over. Over millions of transactions, this "dust" adds up. The clean solution is to compute N-1 shares as fixed amounts and assign the remainder — whatever integer is left — to the last recipient. This is deterministic and prevents dust accumulation. It slightly advantages or disadvantages the last party by at most one token unit per transaction, which is negligible at scale but should be disclosed. The alternative — truncating all shares and leaving dust in the contract — means the contract slowly accumulates a balance that belongs to no one. That creates a different problem: who governs the dust? In terms of recipient allocations, the split creator sets the total number of shares. As such, recipients holding small shares may be negatively impacted by rounding on small distributions, potentially leading to financial losses. This is especially acute with tokens that use six decimal places instead of eighteen. Test your math against the actual token precision you'll be handling. ### Gas limits as a practical recipient ceiling The contracts do not impose a maximum limit on the number of recipients for a split. Consequently, the practical limit is governed by the gas limit of the network's transactions. Every outbound transfer in the split costs gas. As the recipient list grows, so does the total gas cost. We recommend not creating splits with more than 400 recipients. Be cautious of this constraint when creating large splits, as it may result in funds being irretrievably locked due to the gas limit restrictions of the network. For B2B deals with a small number of defined parties — three to fifteen, typically — this is a non-issue. But if you're building a system that routes to variable recipient lists, cap and test. ### Edge cases that cause real failures Edge cases are where most bugs hide. Your test suite should cover: distributing zero-value deposits, splitting amounts that create rounding dust, having the maximum number of beneficiaries claim simultaneously, a beneficiary wallet being a contract that consumes extra gas, a token with non-standard decimals, and attempting to withdraw when the balance is zero. Each of these scenarios has caused real production failures in deployed revenue sharing contracts. The contract-as-recipient case is particularly worth testing carefully. If a recipient address is itself a smart contract with a `receive()` function that does complex work, it consumes more gas than a plain wallet receipt. In the worst case, a single malicious or poorly-designed recipient contract can consume enough gas to cause the entire split transaction to fail. One approach: cap the gas forwarded to each recipient call. The downside is that this breaks composability for recipients who need to do more work on receipt. The right answer depends on your trust model for recipient addresses. ### Finality On-chain transactions, once confirmed past a reasonable depth, are irrevocable. This is the property that makes the primitive useful — and the property that makes errors expensive. There is no "undo" on a confirmed split. If the shares are wrong, the funds went to the wrong amounts. If a recipient address is wrong, the funds went to an uncontrolled address. The right response to this is not softening finality with a multisig escape hatch on every transaction — that reintroduces governance overhead and the possibility of disputed interventions. The right response is validating inputs aggressively before the transaction is ever signed. Confirm recipient addresses. Confirm share math sums to 100%. Run simulations against the contract before committing to mainnet amounts. Finality is a feature, but it demands that correctness be enforced upstream, not patched downstream. ## Why we built this for B2B specifically Consumer payment splitting is a solved problem — Venmo, Splitwise, and a dozen others handle it adequately. The reason it's solved is that the trust requirements are low and the stakes are small. If a split goes slightly wrong between friends, someone sends a correction. B2B deals are structurally different. Counterparty credit risk is an important consideration in B2B transactions because it can directly impact a company's ability to maintain operations and meet its financial obligations. This risk refers to the possibility that the other party in a transaction — such as a supplier, customer, or partner — may fail to fulfil their financial or contractual obligations, whether that's making delayed payments, defaulting on loans, or failing to deliver agreed-upon goods or services. The stakes in B2B deals are high enough that trust requires a mechanism — not just a promise. Sequential transfers require the weakest party in the chain to trust the strongest. A subcontractor trusts the platform. The platform trusts the buyer's bank to clear. Every hop is a trust dependency. A counterparty's trust erodes after repeated payment uncertainty, affecting future deal terms. In B2B relationships that repeat — and the valuable ones always do — this erosion is a real cost. A subcontractor who has been held on float twice will price the risk of a third time into the next contract. That's not irrational. That's correct behavior under uncertainty. Atomic splitting doesn't just mechanically improve the payment. It changes the trust structure of the deal. Every party knows, before the transaction is signed, exactly what they will receive if the payment goes through. They know it because it's in the contract — not in an email, not in a promise, not contingent on how quickly the platform processes outbound wires that week. The contract is the agreement. The execution is the settlement. They happen together. That is a different kind of deal. It is the kind of deal we are building toward at kooky — not because it is narratively cleaner, but because the mechanics are genuinely better, and the disputes it prevents are real ones that real businesses currently absorb as a normal cost of doing business. They don't have to be.