Airdrop claims: distinguish eligibility from distribution
An airdrop allocation, a successful claim and ongoing application use are different observations. Research should reconcile the distribution contract’s eligibility population with actual token movements before treating a headline allocation as adoption or completed distribution.
OpenZeppelin’s MerkleProof reference documents membership verification relative to a Merkle root. It does not define every airdrop’s eligibility, funding or duplicate-claim rules. Check those properties in the actual distribution contract and allocation construction.
Start with the allocation object
Identify network, distributor, token, root version, allocation file and claim window. Record leaf fields, such as index, account and amount, according to that deployment. A proof matching the root supports membership under the construction; it does not prove every person received the allocation intended by marketing.
Check whether allocations are per address, per index or another unit. Several leaves may belong to one account. One person can control multiple eligible accounts. Preserve unique leaves, unique accounts and allocated token quantities as separate totals.
Inspect how repeat claims are prevented. A contract might store claimed indexes or account flags, but the rule is deployment-specific. Read state and successful claim events together. Counting submitted calls can include reverted duplicate claims without additional distribution.
Hypothetical allocation and claim funnel
Assume a fictional campaign has 1,000 eligible leaves for 100 tokens each, allocating 100,000 tokens. There are 900 distinct eligible accounts because some have multiple leaves. At the cutoff, 600 leaves have successful claims and 60,000 tokens have been transferred to claimants.
| Stage | Hypothetical count or quantity | Denominator |
|---|---|---|
| Eligible leaves | 1,000 | Allocation construction |
| Eligible accounts | 900 | Distinct encoded accounts |
| Claimed leaves | 600 | 60% of leaves |
| Distributed amount | 60,000 tokens | 60% of allocation |
| Unclaimed allocation | 40,000 tokens | Remaining valid allocation |
Leaf and amount coverage match only because each leaf has the same allocation. If large allocations claim first, token coverage can substantially exceed leaf coverage. Report both ratios rather than calling either one “the claim rate” without a label.
Suppose claims involve 550 distinct accounts. Then 550/900 is about 61.1% account coverage, different from the 60% leaf rate. None of these ratios establishes 550 distinct people or active customers. Every figure is hypothetical.
Reconcile funding and unclaimed amounts
Compare successful token transfers with claimed-state changes. Account for token-specific transfer behavior rather than assuming the emitted allocation equals the actual receipt. Keep failed and pending claims out of successful distribution.
Reconcile opening token balance, funding, successful distributions, authorized recoveries and closing balance. Remaining token balance does not necessarily equal unclaimed allocation: the distributor can be overfunded, underfunded, contain unrelated deposits or have a recovery mechanism. Read the deadline and post-deadline treatment before labeling the remainder forfeited.
If the root changes, retain both versions and determine whether claims made under the old root remain valid or consume entitlement under the new one. Combining two allocation files without deployment-specific rules can count the same entitlement twice. A published replacement file alone does not show that the contract adopted it.
For adoption research, define a separate post-claim window and action. Claiming a subsidy is not evidence of willingness to pay. Do not infer sale from a transfer away without checking the receiving context. Retention requires its own account-level recurrence rule and coverage limits.
Keep eligibility, execution, actual distribution, remaining obligations and later usage in separate columns. Recheck after root updates, deadline changes, funding or recovery transactions. This measures campaign mechanics without turning allocations into a user census.
Audit the allocation file independently of claim execution. Verify unique leaf keys against the deployed construction and sum allocation amounts using the actual token decimals. A duplicate row in a downloaded file is not automatically a second entitlement, while a distinct index for the same account may be intentional. Keep the contract’s eligibility key as the basis for reconciling the file to successful claims.
FAQ
Does a Merkle proof mean tokens have been received?
No. It can support eligibility under a root. Successful execution and actual receipt need separate evidence.
Is remaining balance the unclaimed amount?
Not necessarily. Funding, recoveries, token behavior and contract terms can make those amounts differ.