Intermediate· Lesson 6 of 8· 3 min

Airdrops, multisends and holder snapshots

Sending a token to a thousand wallets is a batching problem, a cost problem and a bookkeeping problem. Solve all three before you sign the first batch.

What one send really is

A token transfer moves a balance between two token accounts. If the recipient has never held the mint, their token account does not exist yet, so the transaction first creates it — an instruction to the Associated Token program — and you pay its rent deposit, about 0.0015 SOL. The transfer itself costs a share of one 5,000-lamport fee. For a distribution to new holders, the deposits are nearly all of the cost.

Batching

A transaction is capped at 1,232 bytes. Each transfer adds an instruction and one or two account keys, so a batch holds roughly 15–20 transfers, fewer when accounts must be created. One signature covers the whole batch, and the batch is atomic: every transfer in it lands or none does.

The pipeline

1. Build the list: one address and one amount per row. Decide amounts in display units and let the tool convert by the mint's decimals.
2. Validate: reject malformed addresses, flag duplicates, drop zero amounts, and decide whether to send to program-owned accounts (usually not).
3. Cost it: count recipients without a token account for this mint; multiply by the deposit; add fees. Fund the sender wallet with a margin.
4. Batch and sign: one wallet prompt per batch. Simulation shows the transfers and the account creations.
5. Confirm and record: a batch is done only when confirmed. Keep the signature per batch, and never resend a batch whose result you don't know.

12345

1. One top-level “create idempotent” instruction expands into these inner steps.
2. Ask the Token program how big the account must be, extensions included.
3. The System Program creates it, funded by the sender.
4. The deposit: 0.00148844 SOL, the 2026 rate for 165 bytes.
5. Assigned to the Token program, which now owns the account's data.

Duplicates and retries

The failure that costs money is the double send: a batch times out, you resend, and it turns out the first one landed. Use the “idempotent” form of account creation so a re-run never fails on an account that already exists, and treat a batch as unknown until you have looked up its signature. Avoiding duplicate or failed sends sets out the bookkeeping; Multisender and Airdrop do it for you and show each batch's status.

Snapshots

A holder snapshot is the list of every token account for a mint with its balance at a moment, read from the chain. It is the input to most airdrops — reward holders, exclude the pool and the team, weight by balance — and it needs three decisions: which accounts to exclude (liquidity pools, exchange wallets, the deployer), whether to aggregate by owner wallet rather than token account, and which block counts as the moment. Holder Snapshot exports the list as CSV ready for the airdrop tool.

Claim-based airdrops

For very large lists the sender pays nothing up front by putting a Merkle root on-chain and letting each recipient claim with a proof, paying their own fee and deposit. The trade-off is that many never claim. Merkle-tree airdrops explains the mechanics.