Crypto Newbie / Simulators / Merkle Airdrop
Merkle Airdrop Simulator — Gas-Efficient Token Distribution
Every major crypto airdrop — Uniswap (UNI), Optimism (OP), Arbitrum (ARB), Ethereum Name Service (ENS) — uses a Merkle tree. The project commits to a list of (address, amount) pairs by publishing the 32-byte Merkle root on-chain. Each user proves their inclusion with a small proof (log₂(N) hashes), and the contract verifies. This simulator builds a real Merkle tree from a claim list, generates proofs, and shows you the gas savings vs the naive approach.
Airdrop claim list
Merkle root (on-chain)
2f47b4a6
This single hash commits to the entire list. The contract stores just this — not the full list. Each user reveals their claim with a proof at claim time.
Tree layers (bottom-up)
Layer 3 (root)
Layer 2
Layer 1
Layer 0 (Leaves (per-claim hashes))
Proofs per user
Each user gets a small set of sibling hashes — log₂(N) hashes per proof. The contract uses these to walk from the user's leaf up to the stored root.
| Proof for | sibling hashes |
|---|---|
| 0xAlice... | 9337c96dced26fd4d0b64645 |
| 0xBob... | bb6f7484ced26fd4d0b64645 |
| 0xCarol... | a741c720ea190bd2d0b64645 |
| 0xDave... | 95d8a814ea190bd2d0b64645 |
| 0xEve... | 212415b83d8322e3ad1d219f |
| 0xFrank... | 0ed198ba3d8322e3ad1d219f |
| 0xGrace... | 65ff97e7e4b0f302ad1d219f |
| 0xHenry... | 9ebd97d1e4b0f302ad1d219f |
Verify a claim (what the contract does)
✓ Proof verifies against root — claim approved, tokens sent.
Tamper test — change one claim's amount
Cost comparison
Hash operations per claim
3
Est. gas cost per claim
$3.25
Est. cost if storing all claims on-chain
$8.00
Savings: $-18.0000
Why not just store the claim list on-chain?
A 10,000-address airdrop, stored naively, requires 10,000 SSTOREs (~20k gas each) = 200M gas. At typical Ethereum rates that's $10,000+ just to store the list. Plus the contract code to look up entries. With a Merkle tree, the project stores ONE 32-byte hash (~$5 to deploy) and a tiny verification function. Users pay their own claim gas (~$3 each), but most never claim — the project's cost stays low even at scale.
How a Merkle proof works
A Merkle tree is built by hashing pairs of leaves to form a parent, then pairs of parents to form a grandparent, all the way up to a single root. To prove your leaf is in the tree, you provide the SIBLING hashes at each level — log₂(N) hashes total. The contract walks up the tree from your leaf, combining with each sibling, and checks the final hash equals the stored root. The simulator above shows this visually: each user has a proof of just 3 hashes for an 8-claim drop.
Tamper resistance — the security property
If you change even one bit of one claim, that claim's leaf hash changes, which changes the parent, which changes the grandparent, all the way up to the root. To 'tamper undetectably', you'd need to find a hash collision — computationally infeasible with SHA-256 (or FNV-1a in our toy version, less secure but the principle is the same). The simulator's tamper test demonstrates: change one claim, the proof for that claim immediately fails against the unchanged root.
Why airdrop frontends matter
The Merkle root only knows hashes. To CLAIM, a user needs their proof — typically a JSON array of sibling hashes for their address. Project frontends host this lookup: enter your wallet address, get back the (amount, proof) for your claim. If the frontend goes down, technically you can still claim — but you'd need to rebuild the proof yourself from the original claim list. This is why some skeptics keep local copies of every drop's claim data: in case the official frontend disappears years later.
Frequently asked questions
+What stops someone from forging a claim?
Two things: (1) the merkle proof must verify against the stored root, and forging a valid proof for an address that isn't in the original list requires finding a hash collision — computationally infeasible. (2) Most airdrops also verify msg.sender == claimedAddress, so even with a valid proof, you can only claim TO the address that was originally listed. Some projects allow delegation (claim on behalf of) via signed messages.
+What if a user loses their proof?
They can regenerate it from the original claim list as long as that list is preserved (usually on IPFS, GitHub, or the project's website). The chain only stores the root, not the list. As long as one copy of the list exists somewhere, anyone can recompute any user's proof. Most projects pin the claim list to multiple IPFS gateways for decades-long durability.
+Can the project change the airdrop after launching?
Only if the contract allows updating the merkle root. Most production airdrops make the root immutable at deployment — once set, it cannot be changed. This means the project must finalise the claim list BEFORE deployment; any missing addresses can't be added later without a separate top-up airdrop with its own root.
+Why is the simulator's gas cost so much smaller than real Ethereum?
Toy numbers. Real Ethereum gas costs for keccak256 are ~30-50 gas per byte hashed, plus storage and control flow. A real claim transaction runs $2-15 in gas depending on network congestion. The simulator's $0.005-per-claim is illustrative — the SHAPE of the savings (linear in claims for naive storage, logarithmic for Merkle) is what matters.
+What's the difference between a Merkle airdrop and a regular ERC-20 transfer airdrop?
Regular transfer airdrop: project sends tokens to every address in a list, paying gas for each transfer (so for 10k addresses, project pays 10k × transfer gas). Merkle airdrop: project deploys a contract with root, USERS pay their own claim gas. Trade-off: transfer airdrops are 'push' (recipients don't have to do anything) but expensive for projects. Merkle airdrops are 'pull' (recipients must claim) but cheap for projects. Modern airdrops are nearly all merkle-based.