Design a Crypto Identity-Linked Airdrop

Problem statement

Design an identity-linked airdrop platform that distributes tokens to unique real participants while preventing mass exploitation by sybil wallets. The platform must define eligibility from identity evidence (proof-of-personhood, partial KYC, or scored on-chain history), freeze a reproducible snapshot at a pinned block height, build a Merkle tree of (address, amount) allocations, publish the root to a settlement contract, serve cryptographic proofs to millions of claimants during a claim storm, verify each claim exactly once on-chain, expose live distribution statistics, and operate an appeals path for wrongly excluded humans.

This is not a web giveaway with a database flag. The moment a claim settles, the source of truth moves from our infrastructure to a public chain we do not control. A double-claim is not a row conflict we can roll back; it is an irreversible transfer. Therefore the design separates eligibility truth (off-chain, recomputable, appealable until freeze) from settlement truth (on-chain, immutable, enforced by a claimed-bitmap). The off-chain platform may degrade, be DDoSed, or lose an identity provider; the contract must still make double-spending impossible and must never depend on our API being up.

Why the problem is distinctive

A conventional backend retries a write. An airdrop cannot retry a settlement: the chain is the only arbiter, and every claim is publicly observable, front-runnable, and phishable. Three properties collide: uniqueness (one human, one claim), privacy (personhood proven without leaking identity), and availability (five million claimants arriving in the first hour). Merkle proofs solve availability and verification cheaply because proofs are public and stateless; nullifiers and zero-knowledge personhood solve uniqueness and privacy; a frozen, content-addressed snapshot solves dispute and reproducibility. A strong answer keeps these three mechanisms separate and names the invariant each one protects.

Public operating baseline versus design assumptions

Public evidence shows the category is real and large. Uniswap's September 2020 UNI airdrop granted 400 UNI per eligible historical address through an on-chain Merkle distributor, with roughly a quarter-million eligible wallets reported by public dashboards. Arbitrum's March 2023 ARB airdrop distributed 1.275B ARB, 12.75% of initial supply, to hundreds of thousands of publicly reported eligible wallets using historical activity criteria and sybil exclusion. Jupiter's January 2024 JUP airdrop sent 1B JUP to roughly 955,000 Solana wallets via a Merkle-proof claim program, and its claim site experienced launch-day congestion. Tools for Humanity publicly reports millions of World ID verified humans using iris-uniqueness plus zero-knowledge nullifiers. These are cited public figures, not requirements for our fictional system.

For capacity planning this answer explicitly assumes: 5,000,000 eligible addresses , a 30-day claim window , a 60% claim rate (3,000,000 claims), 40% of claims in the first 24 hours , and a 10x burst inside the peak hour. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold.

The four architectural planes

1. Identity plane: personhood proofs, KYC attestations, passport-style scores, nullifier registry, privacy minimization.
2. Eligibility plane: snapshot jobs, sybil filtering, allocation scoring, Merkle tree build, signed root manifest, appeals.
3. Settlement plane: Merkle distributor contract, claimed bitmap, batch claims, paymaster sponsorship, token custody rules.
4. Experience plane: claim UI, proof CDN, live stats fan-out, support console, phishing defense, status communication.

A strong interview answer keeps these planes separate: the experience plane may melt down during the claim storm while the settlement plane remains correct, and the identity plane may be unavailable while already-issued nullifiers keep working from cache.