How to Do a Merkle-Tree Airdrop on Solana

There are two fundamentally different ways to run a token airdrop on Solana: direct send, where the distributor pays gas and rent to push tokens into every recipient's wallet, and Merkle-tree claim, where the distributor publishes a single commitment on-chain and each recipient pays their own small fee to claim their allocation. For very large distributions, the second approach changes the cost equation entirely.

The problem direct send has at scale

A direct-send airdrop to 100,000 wallets means the distributor pays for roughly 100,000 associated-token-account creations (~0.002 SOL rent each) plus the transaction fees to batch-send to all of them — on the order of 200+ SOL before a single recipient does anything. That cost is fully borne by whoever's running the airdrop, up front, whether or not recipients ever actually want or use the tokens.

How a Merkle-tree airdrop works instead

1. Build a Merkle tree off-chain. Every recipient's address and allocation amount is hashed into a leaf; leaves are paired and hashed together repeatedly up to a single Merkle root — one 32-byte hash that cryptographically commits to the entire recipient list and every amount, without needing to store the list itself on-chain.
2. Publish only the root. The distributor deploys a small on-chain program (or uses an existing claim program) storing just that root, plus the token supply it's backed by. This is a single, cheap on-chain write regardless of whether the list has 100 or 100,000 entries.
3. Recipients claim individually. To claim, a wallet submits its address, its allocated amount, and a Merkle proof — a short list of sibling hashes that, combined with the claimed leaf, recomputes up to the published root. If the recomputed root matches, the program is convinced the claim is legitimate and mints or transfers the tokens.
4. Each recipient pays their own claim transaction. Rent for their own token account, plus the network fee, comes out of the claimer's wallet, not the distributor's.

The cryptographic property that makes this work: a valid proof can only be constructed by someone who actually has a genuine leaf in the original tree — there's no way to forge a proof for an amount or address that wasn't included when the root was computed.

The real tradeoff

	Direct send	Merkle-tree claim
Who pays for token accounts	Distributor, up front, for everyone	Each recipient, only if they claim
Cost for non-participants	Paid regardless	Zero — unclaimed tokens cost nothing
Recipient effort	None — tokens just arrive	Must submit a claim transaction
Best for	Hundreds to low thousands of recipients	Tens of thousands+
Complexity	A batched transfer	A dedicated on-chain claim program

The core tradeoff is who bears the cost of recipients who never engage. In a direct send, the distributor pays full rent for every recipient regardless of whether they ever look at the airdrop — dead wallets, abandoned accounts, and dust-threshold non-participants all cost the same as an engaged recipient. A Merkle claim only spends rent on wallets that actually show up to claim, which is often a fraction of the total list — but it shifts a small action (and a small fee) onto every recipient, and adds real engineering complexity: a claim program needs to be written, audited, and deployed, not just a batch of transfers.

Which one you actually want

For most community-sized distributions — hundreds to a few thousand recipients — the added complexity of a Merkle claim program rarely pays for itself; direct send is simpler, requires zero action from recipients, and the total rent cost is manageable. Merkle claims earn their complexity at genuinely large scale, or when a meaningful share of the recipient list is expected never to claim.

Solstack's Airdrop tool runs the direct-send model — snapshot holders, set a distribution, batch-send. For the mechanics of that approach specifically, see How to airdrop SPL tokens to a list of wallets and the Airdrop docs.