Airdrops & Multisend
How to Do a Merkle-Tree Airdrop on Solana
How Merkle-tree claim-based airdrops work, why large projects use them instead of direct sends, and the real tradeoff against simpler batched distribution.
There are two ways to run a token airdrop on Solana. In a direct send, the distributor pays the fees and rent to push tokens into every recipient's wallet. In a Merkle-tree claim, the distributor publishes one commitment on-chain and each recipient pays a small fee to claim their share. For very large airdrops the second approach changes the cost completely.
The problem with direct send at scale
A direct-send airdrop to 100,000 wallets means paying for roughly 100,000 associated token accounts (about 0.0015 SOL rent each) plus the fees to send to all of them. That's more than 150 SOL before any recipient does anything. The person running the airdrop pays all of it up front, whether or not the recipients want the tokens.
How a Merkle-tree airdrop works
- Build a Merkle tree off-chain. Each recipient's address and amount is hashed into a leaf. Pairs of leaves are hashed together, and so on up the tree, until one Merkle root is left. This single 32-byte hash commits to the whole list and every amount, and the list itself never goes on-chain.
- Publish only the root. The distributor deploys a small on-chain program, or uses an existing claim program, that stores the root and holds the tokens behind it. It's one cheap write whether the list has 100 entries or 100,000.
- Recipients claim one by one. To claim, a wallet submits its address, its amount and a Merkle proof, a short list of sibling hashes. The program combines the leaf with those hashes and recomputes the root. If it matches the published root, the claim is valid and the program sends or mints the tokens.
- Each recipient pays for their own claim. The rent for their token account and the network fee come from the claimer's wallet.
What makes this safe is that a valid proof only exists for a leaf that was in the original tree. Nobody can build a proof for an address or amount that wasn't included when the root was computed.
The tradeoff
| Direct send | Merkle-tree claim | |
|---|---|---|
| Who pays for token accounts | Distributor, up front, for everyone | Each recipient, only if they claim |
| Cost of recipients who never engage | Paid in full | Nothing |
| Recipient effort | None (tokens arrive in the wallet) | Must send a claim transaction |
| Best for | Hundreds to low thousands of recipients | Tens of thousands and up |
| Complexity | A batched transfer | A dedicated on-chain claim program |
The real question is who pays for recipients who never engage. With a direct send, the distributor pays full rent for every address on the list. Dead wallets, abandoned accounts and people who will never look at the token cost as much as your most active holders. A Merkle claim only spends rent on wallets that come to claim, which is often a small part of the list. In exchange, every recipient has to take an action and pay a small fee, and you have to write, audit and deploy a claim program instead of sending a batch of transfers.
Which one to use
For most community airdrops, with a few hundred to a few thousand recipients, a Merkle claim program isn't worth the extra work. A direct send is simpler, recipients don't have to do anything, and the rent is manageable. Merkle claims make sense at very large scale, or when you expect a large share of the list never to claim.
Solstack's Airdrop tool uses the direct-send model: snapshot the holders, set a distribution and send in batches. For how that works, see How to airdrop SPL tokens to a list of wallets and the Airdrop docs.