Merkle Airdrop

What Is a Merkle Airdrop?

A Merkle airdrop is a token distribution method that uses a Merkle tree to let eligible recipients claim tokens from a smart contract by proving their inclusion in a predefined list. Instead of sending tokens to every address individually, the project computes a Merkle tree off-chain from all eligible addresses and amounts, then stores only the 32-byte root hash in the distribution contract. Recipients claim their tokens by submitting a compact proof that their address and amount are part of the tree.

The pattern was first proposed by Richard Moore (creator of the ethers.js library) in a March 2018 blog post titled "Merkle Air-Drops: Make Love, Not War." Moore demonstrated distributing 2.5 million tokens to 1 million addresses with a deployment cost of roughly $0.90 and a per-claim cost of roughly $0.17. The approach was then popularized at scale by Uniswap's September 2020 UNI airdrop, which became the canonical reference implementation for the pattern.

How It Works

A Merkle airdrop involves three phases: tree construction, contract deployment, and user claiming.

Tree Construction (Off-Chain)

The project compiles a list of eligible addresses and their corresponding token amounts. Each (index, address, amount) tuple is hashed to create a leaf node. The leaves are then paired and hashed iteratively into a binary tree until a single root hash remains:

1. Collect all eligible (address, amount) pairs from snapshot data or on-chain activity
2. Hash each pair using keccak256 to produce leaf nodes
3. Sort and pair adjacent leaves, hash each pair to produce parent nodes
4. Repeat until a single 32-byte Merkle root remains

The full eligibility list and tree structure are published off-chain, typically as a JSON file hosted on IPFS or a web server, so users can generate their proofs.

Contract Deployment (On-Chain)

The distribution smart contract stores three pieces of state: the ERC-20 token address, the Merkle root, and a bitmap for tracking which claims have been made. Deployment cost is constant regardless of the number of recipients because only the 32-byte root is stored.

// Simplified Merkle Distributor (based on Uniswap pattern)
contract MerkleDistributor {
    address public token;
    bytes32 public merkleRoot;
    mapping(uint256 => uint256) private claimedBitMap;

    function claim(
        uint256 index,
        address account,
        uint256 amount,
        bytes32[] calldata merkleProof
    ) external {
        require(!isClaimed(index), "Already claimed");

        // Verify the Merkle proof
        bytes32 node = keccak256(
            abi.encodePacked(index, account, amount)
        );
        require(
            MerkleProof.verify(merkleProof, merkleRoot, node),
            "Invalid proof"
        );

        _setClaimed(index);
        IERC20(token).safeTransfer(account, amount);
    }
}

Claim Process (User Perspective)

From a user's perspective, claiming tokens follows a straightforward flow:

1. Visit the project's official claim page and connect a wallet
2. The frontend checks the address against the published eligibility list
3. If eligible, the page displays the claimable amount and generates a Merkle proof
4. The user signs a transaction calling claim() on the smart contract, passing their index, address, amount, and proof
5. The contract verifies the proof against the stored root, marks the claim as used, and transfers tokens

The user pays the gas fee for their own claim transaction. For a tree with 100,000 addresses, the proof contains roughly 17 hashes (log2 of the number of leaves), making verification computationally cheap.

Bitmap Claim Tracking

The Uniswap implementation introduced an optimization for tracking which addresses have already claimed: instead of using a mapping(address => bool), it packs 256 boolean flags into a single uint256 storage slot using bitwise operations. Each claim index maps to a specific bit position. This reduces storage write costs by approximately 45% compared to individual boolean mappings.

Merkle Airdrops vs. Standard Airdrops

In a standard (push-style) airdrop, the project sends tokens to each recipient in separate transactions. Each ERC-20 transfer costs approximately 65,000 gas. For 250,000 recipients, this means 250,000 transactions and roughly 16.65 billion gas in total, all paid by the project.

Notable Examples

Uniswap UNI Airdrop (September 2020)

Uniswap distributed 150 million UNI tokens (15% of the 1 billion total supply) to approximately 250,000 eligible addresses. Every address that had interacted with the protocol received 400 UNI, including roughly 12,000 addresses that had only submitted failed transactions. Liquidity providers received an additional allocation of approximately 49 million UNI.

The claim window ran until November 30, 2023, over three years after launch. Approximately 90.8% of eligible wallets claimed within the first month. Around 30,000 addresses (roughly 12%) never claimed, leaving approximately 12 million UNI unclaimed. The Uniswap/merkle-distributor contract became the canonical open-source reference for the pattern.

ENS Airdrop (November 2021)

The Ethereum Name Service distributed 25 million ENS tokens (25% of the 100 million total supply) to 137,689 eligible addresses. Within four days, over 14.4 million tokens had been claimed. By the end of the first week, 59.6% of eligible addresses had claimed. The claim window closed on May 4, 2022, and 5.4 million unclaimed tokens were transferred to the DAO treasury.

Arbitrum ARB Airdrop (March 2023)

Arbitrum distributed 1.275 billion ARB tokens (12.75% of total supply) to approximately 625,000 eligible addresses, filtered from 2.3 million wallets after Sybil resistance analysis removed roughly 72% of applicants. The median allocation was 1,250 ARB, with a maximum of 10,250 ARB per address.

Use Cases

While token distribution is the most common application, the Merkle proof pattern extends to several related use cases:

• Governance token distribution: protocols reward early users with governance tokens using Merkle claims, establishing decentralized ownership
• Retroactive rewards: projects snapshot historical activity and distribute rewards to past contributors without needing to process thousands of transfers at once
• Allowlist minting: NFT projects use Merkle roots to manage allowlists for minting events, verifying eligibility on-chain without storing every allowed address
• Vesting airdrops: extensions like Sablier combine Merkle claims with token streaming, releasing claimed tokens gradually over time rather than all at once
• Multi-round distributions: protocols run recurring reward programs by updating the Merkle root periodically with new eligibility data

Risks and Considerations

Gas Costs for Claimants

While Merkle airdrops eliminate gas costs for the distributor, each claimant must pay gas to submit their claim transaction. During periods of high network congestion, the gas cost can exceed the value of smaller allocations, making claims uneconomical. Mass claiming immediately after announcement can itself spike gas prices, creating a rush where early claimers pay less than latecomers.

Unclaimed Tokens

Because users must actively claim, a significant percentage of allocations often go unclaimed. Uniswap saw roughly 12% of addresses never claim, and ENS had roughly 40% unclaimed after the first week. Projects typically set a deadline after which unclaimed tokens revert to the treasury or are burned. Users who miss the window lose their allocation permanently.

Phishing and Scam Claim Pages

Airdrop announcements attract scammers who create fake claim pages designed to steal funds. These phishing sites impersonate the official interface and prompt users to approve malicious token transactions or sign harmful messages. Users must verify the official contract address and claim URL before connecting their wallet.

Second Preimage Attacks

A known vulnerability in naive Merkle tree implementations: an attacker can construct a fake leaf by concatenating two legitimate 32-byte leaf hashes to create a 64-byte value that hashes to a valid intermediate node. OpenZeppelin mitigates this by double-hashing leaves. Projects should always use audited libraries like OpenZeppelin's MerkleProof rather than implementing verification from scratch. A smart contract audit is critical for any distribution contract holding significant value.

Sybil Farming

Airdrop farmers create hundreds of wallets to interact with protocols, hoping to qualify each one for a Merkle airdrop. This dilutes rewards for genuine users. Projects counter this with on-chain analytics and Sybil detection: Arbitrum filtered out 72% of applicant wallets as suspected Sybil addresses before generating its Merkle tree.

Why It Matters

Merkle airdrops solved the fundamental scalability problem of on-chain token distribution. Before this pattern, distributing tokens to thousands of addresses required proportional on-chain costs, making large-scale airdrops prohibitively expensive. By compressing an entire eligibility list into a single root hash and letting users self-serve claims, the pattern enabled the massive community distributions that became a defining feature of DeFi governance.

The same cryptographic principle applies beyond token airdrops. Any system that needs to verify membership in a large set without storing the full set on-chain can use Merkle proofs. This includes allowlist verification, reward distribution, and eligibility checks across smart contract platforms. For a deeper look at how token distribution models shape protocol economics, see the research on sustainable tokenomics and DeFi revenue models.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.