How a Merkle tree proves your airdrop eligibility on chain

05 September 2026

Airdrop claims present a fundamental problem. The protocol needs to prove you are on the list without revealing the whole list on chain, because publishing every eligible address directly costs too much gas. A Merkle tree solves this with a single hash.

A Merkle tree is a cryptographic data structure. You take every eligible address, hash it, and pair hashes together. Then you hash those pairs. Continue until a single hash remains. That final hash is the Merkle root.

The protocol does this work off chain. It collects all addresses that meet the snapshot criteria, builds the tree, and stores the tree and the root. When deployment happens, the smart contract receives only the root hash. Nothing else. The contract stores that root as a single bytes32 value.

This is the core economy: one state variable holds the entire eligibility set. Compare that to an on-chain whitelist, which stores every address separately. A whitelist of 100,000 addresses costs hundreds of dollars in gas just to deploy. A Merkle root costs the same whether the list has ten addresses or ten million.

How a user submits a Merkle proof

You do not just show up and claim. The protocol publishes the full Merkle tree somewhere accessible, typically a website or an IPFS file. You find your address in that tree. Alongside it you find the branch hashes needed to reconstruct the path from your leaf to the root. That set of hashes is your Merkle proof.

Your claim transaction includes two things: your address, and that proof. The smart contract takes your address, hashes it, then repeatedly hashes it together with each proof hash, following the exact pairing order the tree used. If the final computed root matches the stored root, you are eligible.

OpenZeppelin provides a standard implementation of this verification logic. Their MerkleProof library contains a single function: verify. It takes the proof array, the stored root, and the leaf hash. It returns a boolean. The contract checks this boolean and, if true, releases the tokens.

The gas cost of verification stays small because the proof size grows logarithmically with the tree size. A tree of 1,000,000 leaves requires a proof of about 20 hashes, each 32 bytes. The caller pays for those bytes in calldata and for the hashing operations in execution. That cost is typically a few dollars at most. The rest of the eligible users pay nothing at all.

Why not just use a signature

Some airdrops use signature-based eligibility. The protocol signs a message saying this address is eligible, and the user submits the signature. This works but creates a different trade-off. The protocol must manage a signing key. The signature must be generated per user. Merkle proofs require no signing key at all. The protocol publishes the tree once, and any user can independently verify their inclusion.

There is a weakness. The Merkle proof reveals your position in the tree to anyone who sees your transaction. Observers learn which proof hashes you needed. They can reconstruct the branch. They still cannot forge eligibility for an address not in the tree, but they learn more about the tree structure than they would from a signature. This privacy concern matters for some protocols. Most airdrops accept the trade-off.

As of August 31, 2026, no on-chain pair has been found for tilly-aidog.site. The site does not currently host a live token. This page explains the mechanism generally, because the mechanism itself is used widely across the space.

The Merkle tree approach has become standard for a reason. It lets protocols commit to large eligibility sets with minimal on-chain cost. It lets users verify their own eligibility with tools that anyone can run. It works today on every EVM chain. The pattern is mature, well-tested, and documented in OpenZeppelin's contracts. If you see an airdrop claim page asking for a Merkle proof, this is what is happening under the transaction.

Back to airdrops