Multisend vs. Individual Transfers: Batching Solana Transactions Correctly

Sending a token to 200 wallets one at a time works. It's also roughly 15x more transactions than it needs to be, and it gives up a safety property that batching provides for free. Here's what actually changes between the two approaches.

The size limits that force batching

Solana transactions max out at 1,232 bytes — the size of a UDP packet, since that's how transactions propagate across the network. A single SPL token transfer instruction, including its account references, takes up a meaningful slice of that budget. In practice, this caps a single transaction at roughly 15–20 transfers, depending on whether recipients already have a token account (skipping account creation saves space) or need one created as part of the same transaction.

This isn't a tooling choice — it's a hard protocol constraint. Any tool doing bulk transfers, batched or not, runs into this same ceiling. The only question is whether the tool packs transfers efficiently up to that limit, or sends one transfer per transaction and leaves most of that 1,232-byte budget unused on every single one.

What individual transfers actually cost you

Sending 200 transfers as 200 separate transactions means:

• 200 signatures to approve, one at a time, in your wallet — tedious well past a handful of recipients.
• 200x the base network fee overhead, though each fee is small individually (5,000 lamports), it adds up linearly instead of being amortized across a batch.
• No atomicity — each transfer either succeeds or fails entirely on its own, with no relationship to the others.

Batched into ~15-per-transaction chunks, the same 200 recipients need roughly 14 signatures instead of 200 — a meaningful difference in how long the process actually takes to click through.

Atomicity: the property batching actually protects

This is the part that matters more than convenience: within a single batched transaction, all instructions succeed or none do. If transfer #12 in a batch of 15 fails — a malformed account, an authority issue, insufficient balance discovered mid-transaction — the entire transaction reverts, including the 11 transfers that would otherwise have succeeded. Nothing partial happens; no batch ever leaves you in a state where some recipients got paid and others silently didn't from the same attempt.

Individual, unbatched transfers don't have this property by nature — each stands alone, so a failure in transfer #150 has zero effect on whether #1 through #149 succeeded. That sounds like an advantage, but it means a bulk send with individual transactions can leave you with a confusing partial state to reconcile by hand — which recipients got paid, which didn't, and why — instead of a clean batch-level pass/fail you can retry as a unit.

Tracking what's already landed

A batching tool worth using tracks which batches have already succeeded, so that resuming an interrupted send (network hiccup, closed tab, a batch that needs a retry) doesn't re-send to recipients who already got their transfer. This matters specifically because batches are atomic but independent of each other — a failed batch #8 doesn't affect batches #1–7 or #9–14, so a good resume flow only needs to retry the one that didn't land.

Multisender batches transfers to this ~15-per-transaction limit automatically and tracks completed batches so a re-run never double-sends. Full walkthrough in the Multisender docs.