Multisend vs. Individual Transfers: Batching Solana Transactions Correctly

You can send a token to 200 wallets one transfer at a time. It works, but it uses about 15 times as many transactions as it needs to, and you lose a safety property that batching gives you for free. This post compares the two.

The size limit behind batching

A Solana transaction can be at most 1,232 bytes, which is what fits in one UDP packet, the way transactions travel across the network. One SPL token transfer instruction with its account references takes up a good share of that. In practice one transaction holds roughly 15 to 20 transfers. It holds more when recipients already have a token account and fewer when the same transaction has to create one.

Every tool that sends in bulk hits the same ceiling, because the protocol sets it. What differs is whether a tool fills each transaction up to the limit, or sends one transfer per transaction and leaves most of the 1,232 bytes empty every time.

What one transaction per transfer costs you

Sending 200 transfers as 200 transactions means:

• 200 signatures. You approve each one separately in your wallet, which gets tedious after the first handful.
• 200 base fees. Each is small (5,000 lamports), but they add up one by one instead of being shared across a batch.
• No atomicity. Each transfer succeeds or fails by itself, with no link to the others.

In batches of about 15, the same 200 recipients take roughly 14 signatures, which makes a real difference to how long the whole thing takes to click through.

Atomicity is the bigger benefit

Convenience is the smaller gain. Within one batched transaction, either every instruction succeeds or none of them do. If transfer 12 of 15 fails because of a bad account, an authority problem or a balance that runs out, the whole transaction reverts, including the 11 transfers that would have gone through. No batch can leave some of its recipients paid and others silently skipped.

Separate transfers don't work that way. Each one stands alone, so a failure at transfer 150 says nothing about transfers 1 to 149. That sounds like an advantage until something goes wrong. You're left working out by hand who was paid, who wasn't and why, when you could have had a simple pass or fail for each batch and retried the failed one as a unit.

Tracking what already landed

A good batching tool records which batches have succeeded. If a send is interrupted by a dropped connection, a closed tab or a batch that needs another try, resuming it doesn't pay the same recipients twice. Each batch is atomic, and the batches are independent of each other. A failed batch 8 doesn't affect batches 1 to 7 or 9 to 14, so a resume only has to retry batch 8.

Multisender fills each transaction as far as the limit allows: 19 SOL transfers, or 9 token transfers with room to create the recipients' token accounts. It also cuts the signing down further. You approve once, and Solstack's server sends every batch with a key made for that send. It records completed batches, so a resumed send never pays anyone twice. The Multisender docs walk through it.