What does it mean to airdrop tokens?
To airdrop tokens means sending, or making claimable, a set token allocation to a list of wallet addresses you choose, usually to reward past activity, seed a new community, or spread ownership at launch. The list and amounts come from a snapshot; delivery itself happens on-chain, either pushed straight to each wallet or made available for holders to pull.
Every airdrop comes down to the same two decisions: who is eligible, and how they receive tokens. Get the first wrong and you invite Sybil farming. Get the second wrong and you either burn your budget on gas or leave real holders confused about how to claim. The same push-versus-pull choice shows up when delivering a token sale allocation or a vesting unlock, but an airdrop is usually the first time a project has to make the call.
Most teams do not pick one mode forever. A small retroactive reward for a hundred early testers is a natural fit for a direct push, while a public community airdrop with an open eligibility form usually ends up as a claim once the list grows past a few thousand wallets. This guide covers both delivery mechanics, MultiSender and Merkle claim, and the six steps to run either one from snapshot to verification.
MultiSender vs Merkle claim: which should you use?
MultiSender and Merkle claim are the two ways to deliver an airdrop, and the choice comes down to who pays gas and how large your list is. MultiSender batches transfers into one funded transaction, so tokens land in every wallet instantly with no action from the holder. A Merkle claim publishes a single eligibility root on-chain and lets each holder submit a proof to pull their own allocation, paying their own gas.
| MultiSender (push) | Merkle claim (pull) | |
|---|---|---|
| Who pays gas | You, for the whole batch | Each holder, for their own claim |
| Best list size | Small to mid-sized, fixed lists | Large lists, thousands to millions |
| Delivery | Instant, no action needed | Self-serve, holder claims when ready |
| Unclaimed tokens | Not applicable, already sent | Stay in the contract until claimed or swept |
| Fixing a mistake | Hard, tokens have already moved | Easy, pause or correct before anyone claims |
Neither mode is strictly better. A 500-wallet loyalty drop is cheap and simple to push directly. A 200,000-wallet community airdrop is far cheaper to run as a claim, because the gas bill shifts from you to whoever actually wants the tokens.
How do you airdrop tokens in 6 steps?
Airdropping tokens follows the same sequence regardless of which delivery mode you pick: snapshot who is eligible, filter out bad actors, choose push or claim, fund the contract, distribute, then verify. Skipping the filtering step is the most common way projects waste allocation on Sybil wallets instead of real holders.
- Snapshot eligible holders. Pull the wallet list and amounts from on-chain activity, a form, or your CRM, at a fixed block or date so the list cannot be gamed after the fact.
- Build and Sybil-filter the list. Deduplicate wallets, apply activity thresholds, and remove addresses that look like one actor splitting across many wallets.
- Choose MultiSender or a Merkle claim. Small, fixed list: push it directly. Large or open-ended list: publish a claim instead.
- Fund and deploy. Fund the MultiSender batch or the claim contract with the full distribution amount, on the chain your token already lives on.
- Distribute. Send the batch transaction, or open the claim window and publish the claim link on your own domain.
- Verify. Confirm the on-chain transfers or claims match your snapshot, and publish the contract address so holders can check their own allocation.
A CSV import at step 1 saves the most time: format the snapshot once and reuse it for both the batch send and the claim tree. Before you announce publicly, run a small test batch or a handful of test claims first, wrong-network reverts and already-claimed checks are much cheaper to catch on a testnet than in front of your community.
What is a MultiSender airdrop?
A MultiSender airdrop pushes tokens to a batch of wallets in one or a handful of transactions, funded and signed by the issuer. It is a push distribution: nothing is required from the recipient, tokens simply appear in their wallet. That makes it the simplest way to reward a known, fixed list, a team, early testers, past customers, without asking anyone to come back and claim.
The tradeoff is who pays and who can recover a mistake. You cover every recipient's gas up front, so cost scales directly with list size, and once a batch transaction confirms, a token sent to the wrong or an inactive wallet cannot be pulled back. MultiSender works best for lists small enough that the total gas bill is trivial, and clean enough that you trust every address on it. It also suits time-sensitive rewards, a loyalty drop tied to an event or a milestone, where you want every wallet funded the moment the campaign goes live rather than waiting on holders to come claim it.
What is a Merkle claim airdrop?
A Merkle claim airdrop commits your entire eligibility list to a single 32-byte root stored on-chain, then lets each holder submit a short proof to claim their own allocation. It is a pull distribution: the contract, not the front end, decides who is eligible, so a claim link can be public without exposing tokens to anyone not on the list.
This is the same mechanism a token claim portal uses to hand out sale deliveries and vesting unlocks, and the mechanics, proof size, gas cost, and how to keep a claim contract fail-closed, are covered in full in our guide to running a token claim portal. For an airdrop specifically, the appeal is scale: a proof grows only about log2(n) hashes, so per OpenZeppelin's MerkleProof library, even a list of a million wallets needs a proof of roughly twenty hashes to verify.
How do you build and Sybil-filter your recipient list?
You build the list from a snapshot of the activity you want to reward, then filter it before you commit to a root or fund a batch, never after. Deduplicate wallets, cap or exclude addresses with no history beyond the qualifying action, and cross-check for clusters of wallets funded from the same source or acting in lockstep, a classic Sybil signature.
Sybil filtering is now standard practice at scale. Before distributing ZRO, LayerZero removed 803,273 wallets, about 59% of applicants, as Sybil. Your project does not need that volume of filtering to justify the step: the principle holds whether you are screening a few hundred addresses or a few hundred thousand. A cleaner list means more of your allocation reaches real holders instead of farmed wallets, and a tight Sybil definition up front saves a dispute later.
Filtering belongs before you freeze the list, not after tokens are already moving. Once a MultiSender batch confirms or a Merkle root is committed and funded, removing a bad address means a correction round, not a quiet fix. Treat the eligibility list itself as the deliverable you spend the most care on, the delivery mechanic is comparatively mechanical once the list is right.
What happens to tokens nobody claims?
In a push MultiSender airdrop, this question does not apply, tokens are already delivered. In a Merkle claim, unclaimed tokens sit in the contract until claimed or until a deadline you set, and partial claims are the norm rather than the exception. Uniswap's September 2020 airdrop made 400 UNI claimable by 251,534 addresses, and Dune Analytics found that while 90.8% claimed within the first month, roughly 30,000 wallets never claimed at all.
Plan for that leftover. Announce a claim deadline, remind holders before it closes, and use a contract that lets you sweep unclaimed tokens to a treasury afterward rather than stranding them permanently. If you want claimed tokens to keep unlocking gradually instead of releasing in full, pair the claim with a vesting schedule so the airdrop and the unlock run on one contract.
How much does it cost to airdrop tokens, and on which chains?
Airdropping tokens costs little beyond network gas: there is no percentage cut on a distribution, only a small per-transaction fee plus whatever the chain charges to execute. A MultiSender push costs you gas for every wallet in the batch. A Merkle claim costs you gas once, to deploy and fund the contract, and each holder covers their own claim after that.
Saleium runs both airdrop modes near-free, a per-transaction fee plus network gas, with CSV import so you can upload a recipient list directly instead of formatting a Merkle tree by hand. Airdrops deploy on five EVM chains, BNB Chain, Polygon, Base, Arbitrum and Avalanche, with other EVM chains available on request, so you can distribute on whichever chain your token already lives on. Airdrops are also the one product available on Saleium's free plan, so a project can push or open its first claim campaign before committing to a paid tier.
Set up an airdrop campaign on your own domain, whether you are pushing a small list today or opening a claim for a much larger one later.