Many-to-many transfers on Solana: one sender per recipient
Multi-sender pays a list from one wallet. Many-to-many keeps each sender with its own recipient. What a row costs, and which rows get skipped.
A many-to-many transfer keeps each sending wallet with its own recipient. Wallet 1 pays address 1, wallet 40 pays address 40, and the two rows never touch. Each row is a separate transaction, signed by the wallet that holds the money.
- One transaction per pair, signed by its own sender. Row 40 failing leaves row 41 alone, because the rows share no account and no signature.
- The platform fee is 0.001 SOL per transfer, added as a second instruction inside the sender's own transaction. Nothing is collected up front and nothing is escrowed.
- In token mode a recipient who has never held that mint needs a token account, and the sender funds it with 0.00203928 SOL. On a list of fresh addresses that one line costs twice the platform fee.
- A run takes up to 2,000 pairs, signed and broadcast in chunks of 100, then confirmed in batches of 256 with a 90 second ceiling.
- A SOL row that would leave its sender holding more than nothing but less than 0.00089088 SOL is skipped rather than quietly adjusted, because the network refuses that account.
Three shapes of bulk transfer
Most bulk sending on Solana is one wallet paying a list. A treasury pays 3,000 claimants: one signer, one funding source, one balance to watch. That is what Multi Sender is for, and for an airdrop it is the correct shape.
Sweeping is the same picture reversed. Forty wallets each send what they hold to a single address, so there are forty signers and one destination. Batch Collector covers that side.
Neither one can express the third case. You have forty wallets and forty destinations, and destination 12 must be paid by wallet 12 and by nothing else. Running a multi-sender forty times gets you there after forty rounds of copying. Running it once does not get you there at all, because every address would be paid from the same wallet, which is the link you were avoiding in the first place.
| Shape | Signers | Tool | The job it fits |
|---|---|---|---|
| One wallet to many addresses | 1 | Multi Sender | Airdrop or payroll from a treasury |
| Many wallets to one address | one per row | Batch Collector | Sweeping a fleet back into a main wallet |
| Many wallets to many addresses, paired | one per row | Many to Many | Rotating a fleet, one old wallet to one new one |
The pairing is the whole feature. Many to Many reads two address columns and an amount, holds the row together, and signs it with the wallet named on that line.
What one row costs
Three lines can appear on a row, and the sending wallet on that row pays all of them. There is no shared funding account, so a wallet that cannot cover its own row does not borrow from the one above it.
| Line | SOL mode | Token mode |
|---|---|---|
| Platform fee | 0.001 SOL | 0.001 SOL |
| Network fee | 0.000005 SOL | 0.000005 SOL |
| Recipient's token account | not applicable | 0.00203928 SOL, and only when that recipient has never held this mint |
Read the third row twice, because it is the line that surprises people. Sending an SPL token to an address that has never touched it means creating an account to hold it, and Solana charges a rent deposit for that account. The deposit is roughly two hundred times the network fee and twice the platform fee. On a hundred fresh recipients it is about 0.204 SOL of the bill, and the platform fee is 0.1.
The deposit is not burned. It sits in the recipient's token account and comes back to whoever closes that account later, which is a different job covered in pulling SOL back from empty accounts. If the recipient already holds the mint, the line disappears entirely. The runner checks all one hundred destination accounts in a single call before it signs anything, so the estimate you see is the estimate you pay.
The rows that get skipped
Two checks run before a row is signed, and both of them stop the row rather than change it.
The first is plain arithmetic. If the sending wallet cannot cover its amount plus the fees plus any token account it has to open, the row is marked and left alone. Nothing partial is sent.
The second is stranger and worth understanding, because it looks like a bug the first time it happens. Solana refuses to leave an account holding a balance that is above zero but below the rent-exempt minimum, which is 0.00089088 SOL for an ordinary wallet. Emptying an account completely is fine. Leaving 0.0005 SOL in it is not. So a row that sends a wallet down into that gap gets flagged as rent dust and stays unsent.
The alternative would be to shave the amount down until it fits, and that is worse. You typed a number. A tool that sends a different number without telling you is a tool you cannot reconcile against a spreadsheet afterwards. Send the whole balance instead, or lower the amount so the leftover clears the minimum. There is more on where that minimum comes from in the rent explainer.
Why one transaction per row matters
Batching several transfers into one transaction is cheaper on network fees and worse on everything else. A packed transaction is all or nothing, so one bad destination address takes down the twenty good transfers sitting next to it. It also needs every sender in the batch to sign the same transaction, which for forty separate wallets means forty signatures on one object and a size limit you will hit long before row forty.
Splitting per row costs 0.000005 SOL each, which is not the part of the bill anyone should optimise. What it buys is that a failure is a single line in the results table with a reason attached, and rerunning means rerunning that line.
Signing still happens in your browser. The private keys you paste stay on the page, each transaction is signed locally, and only the signed bytes go to the server for broadcast. That is the same arrangement described in the wallet stack playbook, and it is why the tool can act for forty wallets without any of them being connected through an adapter.
When you actually need it
Wallet rotation is the honest answer for most people. You have a set of wallets with history you would rather leave behind, you generate a fresh set with Wallet Generator, and you want old wallet 7 to fund new wallet 7 and nothing else. One run, forty pairs, forty independent transactions.
The second case is a payout list where the payer differs per line. Several projects, several treasuries, one spreadsheet. Multi-sender cannot express that at all, because it has exactly one source.
The third is redistribution after a snapshot, where each holder is paid from a wallet you have already assigned to them. If instead every recipient is paid from one place, you want the airdrop path and not this one, and the cheapest way to airdrop to thousands compares those costs properly.
Run the first pass with two rows. The results table tells you what a row actually cost, including any token account deposits, before you commit two thousand of them.
This article is educational and is not financial, investment, legal, or tax advice. Solana tokens are highly volatile and most lose all value. Do your own research and never risk funds you cannot afford to lose. J Tools does not recommend any specific token or trade.
Frequently asked questions
How is this different from running Multi Sender several times?
Multi Sender has one funding wallet by design, so running it repeatedly still pays every recipient from that wallet. Many to many changes the sender on every line. If your rows only differ in the recipient, use Multi Sender and save yourself the setup.
Does a failed row cost anything?
A row rejected before signing costs nothing, because no transaction reached the network. A row that is signed, broadcast and then fails on chain pays its network fee like any failed Solana transaction. The platform fee is an instruction inside the same transaction, so it does not settle unless the transfer does.
Can senders and recipients overlap?
Yes. A wallet can appear as a sender on one row and as a recipient on another, and the rows are independent transactions, so ordering between them is not guaranteed. If row 2 spends what row 1 delivers, split them into two runs.
What is the maximum number of pairs?
Two thousand per run. They are signed and sent in chunks of one hundred and confirmed in batches of up to two hundred and fifty-six, with a ninety second ceiling on each confirmation wait, so a full run is a few minutes rather than a few seconds.
Why was my row marked as rent dust?
The amount would have left the sending wallet holding something between zero and 0.00089088 SOL, and Solana rejects an account in that state. Send the full balance so the wallet ends at zero, or reduce the amount so the remainder clears the minimum.
Do I need SOL in a wallet that is only sending tokens?
Yes. Even in token mode the sending wallet pays the network fee and the platform fee in SOL, plus the token account deposit when the recipient needs one. A wallet holding tokens and no SOL cannot send anything.
Related reading: the Multi Sender guide for the one-to-many case, bulk wallet generation for building the destination set, and Solana rent explained for the deposits behind both numbers above.
Written by the J Tools team. We build and run 40+ Solana tools in production, from token creation to on-chain wallet analysis, and write from what we see on mainnet, not theory. Published: 30 Aug 2026. Last reviewed: 30 Aug 2026.
