Merkle Drop for LPs

LPs claim rewards by submitting a Merkle proof—a small cryptographic data packet—instead of the protocol iterating over all eligible addresses on-chain. This shifts the computational and gas cost from the protocol to the individual claimant, making large-scale distributions economically viable.

• Key Benefit: Dramatically reduces the protocol's upfront gas expenditure for distribution.
• User Experience: Claimants pay a one-time gas fee only when they choose to claim their allocated rewards.

The integrity of the entire reward distribution is secured by a single Merkle root stored on-chain. Each LP's eligibility and reward amount are encoded in a leaf node within a Merkle tree. To claim, an LP provides their leaf data and the sibling hashes (the Merkle proof) needed to reconstruct the path to the root.

• On-Chain Verification: The smart contract hashes the provided data and verifies it matches the stored root.
• Tamper-Proof: Any alteration to the reward list would invalidate the Merkle root, making fraud detectable.

Any address can independently verify its inclusion in the drop by checking the public Merkle tree data. There is no need for a centralized allowlist or a privileged transaction from the protocol admin to initiate each claim.

• Self-Service Model: LPs interact directly with the claim contract using proofs generated off-chain.
• Full Auditability: The complete list of recipients and amounts can be cryptographically verified against the on-chain root, ensuring transparency.

Rewards are calculated based on a historical snapshot of LP positions (e.g., Uniswap v3 LP NFT holdings or staked token balances at a specific block height). This allows for retroactive reward programs that incentivize past behavior without requiring continuous on-chain tracking.

• Common Use Case: Distributing governance tokens to early LPs or rewarding users of a previous protocol version.
• Fixed Allocation: The total reward pool and individual allocations are determined off-chain at the snapshot moment.

The protocol bears the one-time cost of generating the Merkle tree and publishing the root. All subsequent claim transaction gas costs are borne by the recipients. This creates a claim pressure dynamic where LPs must decide if the reward value justifies their individual gas cost.

• Protocol Efficiency: Enables distribution to thousands of addresses with minimal protocol capital.
• Claim Rate: A portion of rewards may remain unclaimed if the gas cost exceeds the reward value for some users.

Contrasts with other common reward mechanisms for LPs:

• vs. Continuous Emissions: Merkle drops are for one-time, retroactive distributions; emissions are ongoing, real-time rewards.
• vs. Simple Transfer Loop: A contract looping through addresses to send tokens is prohibitively expensive for large sets. Merkle drops are the scalable alternative.
• vs. Centralized Claim Portal: Removes the need for a trusted backend server to approve claims, enhancing decentralization and security.

Unlike traditional airdrops that require a contract to hold and transfer tokens to every eligible address, a Merkle Drop stores only a single Merkle root on-chain. Users submit a Merkle proof to claim, paying their own gas. This eliminates the massive, upfront gas cost for the project and prevents funds from being locked in a contract. For example, distributing to 100,000 users could save the project hundreds of ETH in deployment and transfer fees.

Traditional airdrop contracts are high-value targets for exploits, as they hold the entire token allocation. A Merkle Drop contract holds zero tokens until claimed. The funds remain in a secure treasury or multisig wallet. The on-chain contract only needs to verify the cryptographic proof, drastically reducing the attack surface. This design also prevents loss from contract bugs or private key compromises of the distribution wallet.

Merkle Drops enable precise, complex eligibility criteria calculated off-chain (e.g., LP providers based on a Uniswap V3 snapshot). The eligibility list and individual allocations are hashed into the Merkle tree. This allows for:

• Retroactive rewards for past contributors.
• Weighted distributions based on contribution size or duration.
• Exclusion of sybil wallets or known exploit addresses identified after the snapshot.

Claiming is a permissionless, self-service transaction. Users have full control over when and if they claim their tokens, avoiding the surprise of unsolicited tokens in their wallet (which can be a security risk). They can batch the claim transaction with other actions or wait for lower gas fees. This shifts the operational burden from the project to the user, who acts as the transaction initiator.

The Merkle root published on-chain serves as a public commitment to the entire distribution list. Anyone can verify the integrity of the drop by reproducing the Merkle tree from the published eligibility data. This creates cryptographic proof that the distribution was fair and unaltered, addressing trust issues common in opaque, manual airdrop processes.

A standard airdrop requires the project to broadcast thousands of transactions simultaneously, spamming the network and increasing gas prices for everyone. With a Merkle Drop, claims are spread out over time as users initiate them individually. This prevents the network gas spikes typically associated with large airdrop events and is a more considerate design for the broader ecosystem.

The process relies on a Merkle tree, a cryptographic data structure. The project generates a tree where each leaf node contains an eligible address and its allocated amount. The Merkle root of this tree is published on-chain. To claim, a user submits a Merkle proof—a small set of hashes—that cryptographically proves their inclusion in the tree without revealing the entire list of recipients. This ensures data integrity and permissionless verification.

Merkle Drops dramatically reduce on-chain gas costs. Instead of the project initiating thousands of individual transactions (a costly airdrop), the cost is shifted to the recipients who choose to claim. Only the Merkle root (a single 32-byte hash) needs to be stored on-chain. This model is cost-effective for issuers and allows distribution to massive recipient sets that would otherwise be prohibitively expensive.

A major practical consideration is the claim window. Since the contract holds the allocated funds, they become vulnerable if users never claim them. Projects must set a clear expiry. After this deadline, unclaimed funds are typically made available for the project to reclaim or redirect (e.g., to a treasury). Users must be proactive in monitoring and claiming within the specified period to avoid losing their allocation.

While the claim process is trustless, the initial setup is not. Users must trust that:

• The published Merkle root is correct and includes all eligible addresses.
• The project has not maliciously excluded valid participants.
• The source data (e.g., LP snapshots) was accurate and fairly compiled. Transparency in publishing the full Merkle tree data for independent verification is crucial for mitigating these setup risks.

While Merkle proofs prevent others from stealing a specific allocation, the public nature of blockchain transactions introduces other risks. A malicious actor could front-run a user's claim transaction, though they cannot redirect the funds to themselves. They could, however, grief users by claiming allocations for random, ineligible addresses to waste the contract's gas, potentially making legitimate claims fail if the contract runs out of funds.

A Liquidity Provider (LP) is a user who deposits an equal value of two tokens into a decentralized exchange's (DEX) liquidity pool. In return, they receive LP tokens, which are fungible tokens representing their share of the pool. These tokens are used to track ownership and entitle the holder to a portion of the trading fees generated by the pool. Merkle Drops for LPs use these LP token holdings (often at a specific block height) as the eligibility criterion for distributing a reward token.

An Airdrop is a distribution of tokens or coins to a set of wallet addresses, typically for free. Traditional airdrops involve the project initiating a transaction to each eligible address, which can be gas-intensive and inefficient. A Merkle Drop is a specific, optimized type of airdrop that shifts the gas cost to the claimer and uses a Merkle tree for verification. This makes it the preferred method for large-scale, retroactive distributions to thousands of users, such as rewarding past LPs.

The Claim Contract is the on-chain smart contract that facilitates the Merkle Drop. Its core functions are:

• Storing the Merkle root, which commits to the list of eligible recipients and amounts.
• Allowing users to call a claim function, providing their address, allocated amount, and a Merkle proof.
• Verifying the proof against the stored root. If valid, it transfers the tokens from the contract to the claimant.
• Marking the address as claimed to prevent double-spending. This design makes the distribution permissionless and trust-minimized.

A Snapshot is the act of recording the state of the blockchain (e.g., LP token balances) at a specific block number. For a Merkle Drop targeting LPs, the project takes a snapshot of all addresses holding a particular LP token. The eligibility list and reward amounts are calculated based on this historical state. Using a snapshot ensures the drop rewards past behavior and prevents users from quickly depositing liquidity just to qualify. The Merkle root is generated from this frozen snapshot data.

Gas optimization is a critical design goal for Merkle Drops. Compared to a standard airdrop where the distributor pays gas to send tokens, a Merkle Drop optimizes costs by:

• Batching verification: Distributing the cost of a single root hash on-chain.
• Shifting gas burden: The claimant pays the gas to execute the claim transaction.
• Minimizing on-chain data: Only the root hash is stored, not the entire list. This makes large-scale distributions economically feasible and is a key reason for the mechanism's popularity in DeFi.