In this article
Four families of onchain tool send one payment to several wallets: a wallet's built-in batch send, a multisend contract, a splitter contract and an onchain payment router. The criterion that separates them is who has to hold the money before it is divided: you, a contract, or nobody in between.
Three other methods are often mentioned for the same job and do something different: one transfer per wallet by hand is several payments, an exchange's or custodian's batch withdrawal pays from an account the custodian controls, and a streaming or vesting tool pays over time.
This article compares the seven on the same criteria, for a business or a professional who is not a developer: who holds the funds first, whether it is one transaction, how the network fee behaves as wallets are added, whether a token approval is needed, how shares are expressed, whether a recipient can check their share beforehand, and what a wrong address costs. It names families of tools, not products.
The gas figure is the one given in the Ethereum Foundation's developer documentation for a simple transfer; the rounding figure is a worked example detailed below.
What kinds of tool send one payment to several wallets?
Seven families of tool can get one sum of stablecoin to several wallets, and they differ first on who holds the funds before the division and on whether the division is a single transaction. The table sets them side by side on those two points and on the situation each one suits.
| Family | Who holds the funds first | One transaction for all wallets? | Suits |
|---|---|---|---|
| One transfer per wallet, by hand | You, in your own wallet | No, one transaction per wallet | Two or three recipients, paid rarely |
| A wallet's or multisig wallet's batch send | You, in that wallet | Yes, when the wallet is a smart-contract wallet | A business that already keeps its funds in such a wallet |
| A multisend or batch-transfer contract | You, then the contract moves them from your wallet | Yes | A payout list of fixed amounts, from a few wallets to hundreds |
| A splitter contract | The splitter contract, until the shares are distributed or claimed | The deposit is one; the distribution may be separate | The same group and the same percentages, payment after payment |
| A streaming or vesting tool | The stream or vesting contract, for the whole period | No, recipients are paid over time | Pay that accrues: salaries, grants, vesting |
| An exchange's or custodian's batch withdrawal | The exchange or custodian | No, each withdrawal is processed separately | Funds already on deposit with a custodian |
| An onchain payment router | The paying client, until the payment; nobody in between | Yes, the client's payment and every share | One client payment owed to several agreed parties |
Two of these rows are easy to confuse. A multisend contract starts from money you already hold and sends amounts you typed. A router starts from money a client has not paid yet and divides it as it arrives. If the client has already paid you, the choice is among the other rows.
A splitter contract and a multisend contract differ in the same way. A splitter is a destination: it has its own address, and whatever lands there is divided by percentages fixed when it was created. A multisend contract is an action: it holds nothing, remembers nothing, and does what your one transaction tells it, once.
What does "one transaction" guarantee?
A single onchain transaction is all or nothing: either every transfer inside it happens or none of them does. This property is called atomicity, and it is the practical difference between a batch and a series of separate payments.
The Solidity documentation, the reference for the language most contracts on Ethereum-compatible networks are written in, describes a transaction as a change that "is either not done at all or completely applied". The Ethereum Foundation's developer documentation states the mechanism from the other side: when execution fails partway, the network reverts any changes made so far. For a payout, a batch of four transfers cannot end with two wallets paid and two unpaid: if the third fails, the first two are undone.
That guarantee has a cost and a limit.
The cost is the fee of a failed attempt. The same documentation notes that when a transaction fails during execution, the changes are reverted but the gas already used for the work is still consumed. A batch that fails pays nobody and still costs you a network fee.
The limit is that atomicity protects completeness, not correctness. One transaction guarantees that every transfer on the list happened, not that the list was right. A batch that pays the right amount to a wrong address succeeds, completely and finally.
Sending by hand has no such guarantee. Each transfer is its own transaction: if you notice a mistake after the third, some recipients are paid and others are waiting.
A custodian's batch withdrawal is not atomic in this sense either. You submit one list, but the custodian processes each withdrawal as its own operation, on its own schedule and under its own review.
Who must hold the money before it is divided?
With six of the seven families, somebody holds the full amount before it is divided: you, a contract or a custodian. Only an onchain payment router divides a payment that no intermediary has held, because the division happens inside the paying client's own transaction.
It decides who is exposed. When you hold the full amount first, the other parties depend on you to send their share, whatever the tool. When a contract holds it, as a splitter or a vesting contract does, everyone depends on that contract's code behaving as described. When a custodian holds it, everyone depends on the custodian's processing and on its right to pause a withdrawal. Each is a dependency the parties should know about before the payment.
It decides the timing. A batch you fund yourself pays the others when you get round to sending it. A splitter pays when someone triggers the distribution or when each recipient claims. A router pays everyone at the moment the client pays, because it is the same transaction.
Holding the funds first is not a weakness in itself. A business paying twelve contractors from its own treasury should hold the funds first: it decides when to release its own money. The question only sharpens when the money belongs to several parties from the start.
Why does a batch of tokens need an approval?
A contract cannot move tokens out of your wallet unless you have first authorised it to, so a multisend contract or a router needs a token approval before the payment; a transfer you send yourself does not. The ERC-20 standard, the Ethereum specification that stablecoins such as USDC follow, defines the two paths. The transfer function moves tokens from the caller's own balance. The transferFrom function lets a third party move them, and the standard says it should fail "unless the _from account has deliberately authorized the sender". That authorisation is the approval, described in the standard as allowing a spender to withdraw from your account "up to the _value amount".
In practice, a wallet that holds the tokens and sends them itself needs no approval, whether it sends one transfer or a batch of its own. Paying into a splitter needs none either: it is a plain transfer to the splitter's address. A multisend contract, a streaming tool and a router all pull tokens from a wallet, so each needs an approval from whoever funds the payment, as a separate transaction the first time.
Approve the amount of the payment unless you have a reason to approve more. How approvals last and how to review old ones is a subject of its own.
How does the network fee change as wallets are added?
Every method costs more as recipients are added, but separate transactions pay the fixed cost of a transaction once per wallet, while a batch pays it once in total. No method makes the tenth recipient free.
The Ethereum Foundation's developer documentation gives 21,000 units of gas as the cost of a simple transfer of the network's native currency, and gives the total fee as the units of gas used multiplied by the price per unit. A token transfer uses more than that base figure, because the token's contract has to run to update two balances. Each transfer sent by hand pays the base cost again. A batch pays it once and then adds the work of each token transfer, so the fee still grows with the number of wallets, more slowly per wallet than separate transactions do.
Three practical points follow.
The fee is paid in the network's native currency, not in the stablecoin. Whoever sends the transaction needs a small balance of it, even when the payment is entirely in a stablecoin.
Who pays the fee changes with the family. By hand, with a wallet batch or with a multisend contract, you pay it. With a router, the paying client pays it, as part of paying. With a splitter that lets each recipient claim, each recipient pays the fee of their own claim. With a custodian, there is no gas for you to pay; the custodian usually charges its own withdrawal fee per withdrawal.
A batch has a ceiling. A block can only hold so much work, so one transaction cannot pay an unlimited number of wallets. Long payout lists are cut into several batches, each atomic on its own.
Percentages or fixed amounts, and what about rounding?
Batch tools take fixed amounts, splitters and routers take percentages, and in every case the network only moves whole numbers of the token's smallest unit. The second table compares the families on how shares are expressed, on approvals and on whether a recipient can check their share before the money moves.
| Family | Shares set as | Token approval needed? | Can a recipient verify their share before payment? |
|---|---|---|---|
| One transfer per wallet, by hand | Fixed amounts, typed one by one | No | No, only once the transfer arrives |
| A wallet's or multisig wallet's batch send | Fixed amounts | No | Only the wallet's co-signers see the batch before it is sent |
| A multisend or batch-transfer contract | Fixed amounts, usually pasted as a list | Yes, by the sender | Only if the sender shares the list; the tool does not show it to them |
| A splitter contract | Percentages, fixed at creation | No | Yes, the percentages and addresses are readable in the contract |
| A streaming or vesting tool | An amount over a period | Yes, by the funder | Yes, once the stream exists |
| An exchange's or custodian's batch withdrawal | Fixed amounts | No | No, the list sits in the sender's account |
| An onchain payment router | Percentages of the incoming payment | Yes, by the paying client | Yes, the shares are agreed before the client pays |
A token has no fractions at the level of the network: a balance is a whole number of the smallest unit, and the token's decimals setting tells wallets where to put the decimal point for display. The ERC-20 standard describes it with an example: a value of 8 "means to divide the token amount by 100000000 to get its user representation". The standard also makes this field optional, which is why a careful tool reads the value from the token's contract instead of assuming it.
USDC is commonly issued with six decimals, so its smallest unit is 0.000001 USDC and 12,000 USDC is recorded as 12,000,000,000 units. Check the figure the token's contract reports on the network you use before relying on it. Two consequences follow.
A pasted list in the wrong unit is wrong by a factor of a million. A tool that expects display amounts wants 1,800. A tool that expects raw units wants 1,800,000,000. Read the confirmation screen, which shows what will be sent, before signing.
Percentages do not always divide evenly. Split 100 USDC three equal ways at six decimals and each wallet receives 33.333333 USDC. That pays out 99.999999 USDC and leaves 0.000001 USDC that belongs to nobody on paper. Every percentage tool has a rule for that remainder: it goes to the last recipient, to the first, or stays in the contract. The sum is trivial; the rule matters to a recipient reconciling to the last unit. With fixed amounts, making them sum to the total is your job.
What does a wrong address cost?
A transfer to a wrong but valid address is final under every family: no tool listed here can recall it, and atomicity does not help because the transaction did exactly what it was told. What differs between families is when the address is fixed, and who has had the chance to check it by then.
The Ethereum Foundation's documentation describes a transaction included in a finalised block as effectively permanent. In day-to-day terms, the only way back from a wrong address is for whoever controls that address to send the money back voluntarily. If nobody controls it, the money is gone.
Many wallets reject an address with a typing error, because Ethereum-style addresses can carry a checksum in the pattern of capital and small letters. That catches a mistyped character. It does not catch a correct, valid address that belongs to the wrong person: a row shifted in a spreadsheet, an old address reused, an address copied from the wrong message.
The families differ on timing. With a batch, the addresses are fixed when you build the list, and a list of forty is not read as carefully as a single address. With a splitter, they are checked once, at creation, and every later payment inherits that check. With a router, each recipient confirms their own destination before the client pays.
The checks themselves are short, and they are the same whatever the family.
- Get each address from its ownerAsk each recipient for their address through a channel you already use with them, and ask which network it is for. An address copied from an old payment or from a transaction history is not confirmed.
- Confirm the token and the networkThe same stablecoin exists on several networks. A recipient whose wallet or exchange account does not support the network you send on may not be able to reach the funds.
- Compare the whole addressCompare every character against what the recipient sent, not only the first and last four. Have a second person do the same.
- Check the totalAdd the amounts and compare with the sum you mean to pay. In the worked example below, 6,000, 3,000, 1,800 and 1,200 must give 12,000.
- Read the confirmation screenBefore signing, check the number of recipients, the total and the token shown by the wallet. If any of the three differs from your list, stop.
What does each family require to send 12,000 USDC to four wallets?
For the same job, both the number of transactions and the party who must hold the 12,000 USDC beforehand change with every family. The worked example: 12,000 USDC is to reach four wallets in shares of 50%, 25%, 15% and 10%, which is 6,000, 3,000, 1,800 and 1,200 USDC. The four amounts sum to 12,000 and the four percentages to 100.
| Family | Transactions | What must be true before sending | When each wallet is paid |
|---|---|---|---|
| One transfer per wallet, by hand | 4, signed by you | You hold 12,000 USDC and enough native currency for four fees | One after the other, as you send each |
| A smart-contract or multisig wallet's batch send | 1, after the required co-signers approve | The wallet holds 12,000 USDC; the co-signers are available | All four together |
| A multisend or batch-transfer contract | 2 the first time: 1 approval, 1 batch | You hold 12,000 USDC; you approved the contract for at least 12,000; the list is in the unit the tool expects | All four together |
| A splitter contract | 2 if one call distributes, 5 if each recipient claims; plus creating the splitter once | The splitter exists with the four addresses and 50/25/15/10; whoever pays sends 12,000 USDC to its address | At distribution, or when each recipient claims |
| A streaming or vesting tool | 1 approval and at least 1 to create the streams, then withdrawals | You hold 12,000 USDC and lock it for the period | Gradually, over the period |
| An exchange's or custodian's batch withdrawal | None signed by you; 4 withdrawals processed by the custodian | 12,000 USDC plus withdrawal fees on deposit; the four addresses accepted by the custodian | Separately, as each withdrawal is processed |
| An onchain payment router | 2 by the paying client: 1 approval, 1 payment | The four shares and addresses are agreed; the client holds 12,000 USDC | All four together, when the client pays |
The counts assume the first use of each tool; an approval already in place for a sufficient amount is not repeated. The splitter's two cases are one deposit plus one distribution call, or one deposit plus four claims.
Atomicity can be seen at work in this example. Suppose the multisend list carries 18,000 instead of 1,800 for the third wallet. The batch now totals 28,200 USDC against a balance of 12,000. The ERC-20 standard says a transfer should fail when the balance is insufficient, the batch runs out of tokens partway, and the whole transaction is reverted: nobody is paid, and you lose only the network fee. Now suppose the slip is 1,080 instead of 1,800. The batch totals 11,280 USDC, well within the balance. It succeeds, the third wallet is 720 USDC short, and nothing on the network flags it. The first error was caught by the mechanism. The second can only be caught by a person reading the list.
Is a streaming or vesting tool the right tool for this?
A streaming or vesting tool pays several wallets over time from funds locked in advance, so it answers a different question from sending one payment to several wallets at once.
What it does well: the full amount is locked at the start, so recipients can see the funds exist, and each recipient withdraws what has accrued on a schedule visible from the first day. That suits a salary paid continuously, a grant released over a year, or a token allocation that vests.
Where it stops: it is not a way to deliver 12,000 USDC today. The funds sit in a contract for the whole period, which is the longest holding time of any family here. Some tools let the funder cancel a stream and recover what has not yet accrued, and others do not; check which before funding one.
Where does an onchain payment router fit, and what is Shaka?
An onchain payment router fits one case: a payment that a client is about to make and that is owed to several parties in agreed shares. Shaka is one such router. It takes one payment in and pays every party their share at the same moment, in one transaction. It routes the payment and never holds the funds.
Each party's share is set as a percentage of the deal, and each recipient can sign their share before the client pays; signing costs the parties nothing. Destinations are fixed and signed before the payment, so the money cannot be redirected at the last minute. The client pays once, through a payment link. The payment is onchain and final, every party can see that the others were paid, and the record of who was paid what stays available onchain. A deal has at most 20 recipients.
Where it does not fit is as clear. Shaka is not a payout tool for money you already hold: if the 12,000 USDC is in your wallet, a batch send or a multisend contract is the family for the job. It is not a payroll tool, and it does not pay over time. It is not an escrow service: it does not hold a payment pending a condition, and a deal that needs funds held until something is delivered needs an escrow service. A payout to more than 20 wallets is outside its limit.
How do you choose between them?
The choice depends on four things: where the money is now, how many wallets, whether the shares are fixed amounts or percentages, and whether the same group is paid again. Start from where the money is, because that one rules out most of the families.
The money is already in your own wallet, and there are two or three recipients. Send by hand. It needs no new tool and no approval, and the lack of atomicity costs little at that size.
The money is in your business's smart-contract or multisig wallet. Use its batch send. The co-signers review the whole payout as one item, and it is one transaction with no approval to a third-party contract.
The money is in an ordinary wallet and the list is long, with fixed amounts. A multisend contract is built for this. Budget for the approval and treat the list as the thing to audit.
The same parties share every incoming payment in the same percentages. A splitter contract removes the repeated work: payers send to one address. The contract holds the money until it is distributed or claimed, and someone pays the fee of each claim.
The money is on deposit with an exchange or a custodian. Its batch withdrawal avoids moving the funds twice. Expect separate processing per wallet and a fee per withdrawal, and make sure each recipient can receive on the network the custodian sends on.
The money has not been paid yet, and it belongs to several parties. An onchain payment router divides it as the client pays, with shares each party saw beforehand. It requires that the parties agree their shares and destinations before the payment, and that the client is willing to pay onchain.
The money should arrive over time. A streaming or vesting tool, and none of the others.
