Private Airdrop

The most common technical implementation. A project generates a Merkle tree (a cryptographic hash tree) off-chain, where each leaf node contains a hash of an eligible recipient's address and their allocated amount. The Merkle root is stored on-chain. Users submit a Merkle proof (a path of hashes) to a smart contract to claim their tokens, proving inclusion without revealing the full list of recipients. This is gas-efficient and private until claims are made.

• Example: Uniswap's UNI airdrop used this method.

Uses zero-knowledge proofs (ZKPs), like zk-SNARKs, for maximum privacy. Eligibility criteria and recipient lists are kept entirely private. Users generate a ZK proof that demonstrates they satisfy the airdrop's conditions (e.g., held a specific NFT before a snapshot) without revealing which NFT or their on-chain history. The smart contract verifies only the proof. This prevents sybil attackers from reverse-engineering criteria.

• Example: Projects like Tornado Cash have used similar mechanisms for private governance distribution.

Employs stealth address protocols. The distributing entity encrypts the airdrop details (amount, token type) using the recipient's public key. A smart contract holds the encrypted data. Only the recipient, with their private key, can decrypt the message to discover and claim the assets sent to a one-time stealth address. This method hides the link between the recipient's main address and the airdrop transaction on-chain.

A multi-phase process that hides information until a reveal period. First, the project commits a hash of the recipient list (the commit phase). Later, they reveal the actual list, allowing users to verify the commitment was honest. This prevents front-running based on early list visibility. Variations can hide amounts until reveal. It's a simpler cryptographic primitive than ZKPs but provides temporal privacy.

Airdrops executed on privacy-focused Layer 1 or Layer 2 networks. These chains (e.g., Aztec, Secret Network) have native privacy for transactions and smart contract state. The airdrop contract's balance and transfer logic are encrypted. Recipients interact with the contract using privacy-preserving transactions, making the transfer of funds, the recipients, and the amounts completely opaque to public blockchain observers.

Often combined with the above distribution methods. Instead of a lump-sum claim, the airdropped tokens are distributed via a vesting contract that streams tokens linearly over time (e.g., using the Sablier or Superfluid protocol). This implements release schedules and cliffs privately. The claim mechanism (Merkle, ZKP) grants access to the streaming contract, not a token balance, adding a time-based dimension to the private distribution.

The core cryptographic primitive enabling private airdrops. A Zero-Knowledge Proof allows a user to cryptographically prove they are eligible (e.g., hold a specific NFT or crossed a token threshold in a past snapshot) without revealing which asset or the exact amount. This preserves user privacy on-chain.

• Example: Using a zk-SNARK to prove membership in a Merkle tree of eligible addresses without disclosing the Merkle proof path.
• Key Property: Completeness, soundness, and zero-knowledge.

Many ZKP systems require a trusted setup ceremony to generate public parameters. If the secret 'toxic waste' from this setup is not properly destroyed, it could allow malicious actors to create false proofs and illegitimately claim airdrops.

• Mitigation: Use ceremonies with multiple participants (e.g., Perpetual Powers of Tau) or transition to trustless proof systems like STARKs that do not require a trusted setup.

A key challenge is preventing Sybil attacks while maintaining privacy. The system must ensure one real-world user cannot claim multiple times, but without linking their claims together on-chain.

• Techniques: Use of semaphore-style nullifiers or sparse Merkle trees to prevent double-spending of the same proof. Each claim generates a unique nullifier, preventing reuse without revealing the user's main identity.

The integrity of the private airdrop depends entirely on the correctness and inaccessibility of the eligibility snapshot. If the snapshot data is manipulated or leaked, the system's fairness is compromised.

• Requirement: The snapshot must be generated in a verifiably correct manner (e.g., from a specific, immutable block hash). The Merkle root or commitment must be published on-chain, while the underlying data is kept private by the issuer.

Users must trust the airdrop issuer in several critical ways:

• Honest Snapshot: The issuer correctly included all eligible users.
• Proof System: The issuer implemented the ZKP circuit correctly without backdoors.
• Parameter Security: The trusted setup was conducted honestly (if applicable).

This is a trust-minimized, not trustless, model. Audits of the circuit and setup are essential.

A security and UX trade-off exists in where the ZKP is generated.

• On-Chain Generation: Maximizes trustlessness but is currently prohibitively expensive in gas fees.
• Off-Chain Generation (typical): The proof is generated in the user's wallet. This requires trusting the wallet's proving software hasn't been tampered with to leak private data.

Best Practice: Use audited, open-source prover clients.

A token distribution event that is openly announced and claimable by a broad, permissionless audience, often used for marketing, community building, or protocol decentralization. Key characteristics include:

• Transparent eligibility criteria (e.g., snapshot of past users).
• Public claim process accessible to anyone meeting the criteria.
• Often results in immediate public trading and price discovery.

A time-based release schedule that locks distributed tokens (from airdrops, team allocations, or investor rounds) for a predetermined period. This mechanism prevents immediate sell pressure and aligns long-term incentives. Common structures include:

• Cliff Period: A duration (e.g., 1 year) before any tokens unlock.
• Linear Vesting: Tokens release gradually (e.g., monthly) after the cliff.
• Private airdrops to teams or investors are almost always paired with vesting schedules.

A distribution model where token allocation is proportional to a user's prior contribution or engagement with a protocol. It is a subset of public airdrops designed to reward early, active users. Criteria often include:

• Historical usage metrics (e.g., transaction volume, liquidity provided).
• Governance participation or community contributions.
• On-chain activity proofs from a snapshot date.

The set of techniques used to prevent malicious actors from creating many fake identities (Sybils) to claim disproportionate rewards in an airdrop. This is a critical design consideration for public and meritocratic drops. Common methods include:

• Proof-of-Personhood verification (e.g., World ID).
• On-chain history analysis to filter out low-activity or cloned wallets.
• Anti-Sybil algorithms that cluster related wallet addresses.

A financial instrument used in private fundraising that grants the right, but not the obligation, to purchase tokens at a fixed price in the future. They function similarly to traditional stock options in web3. Key aspects:

• Often issued to early investors or advisors alongside equity.
• Exercise price and expiry date are predefined.
• Conversion typically occurs during a Token Generation Event (TGE), which may coincide with a private airdrop to warrant holders.

The practice of strategically interacting with protocols to qualify for anticipated future airdrops. Users perform actions (e.g., bridging small amounts, minting NFTs) to appear as legitimate users. This creates challenges for airdrop designers:

• Distinguishes between organic users and farmers.
• Can lead to network congestion and inflated metrics.
• Forces more sophisticated eligibility analysis and Sybil resistance.