If you have used Base for more than a few months, you have probably seen an airdrop claim page at some point. You connect a wallet, the site checks something, and it either tells you that you are eligible for a certain amount of tokens or that you are not. Most people never think about what happens in that split second check. It is worth understanding, because the mechanism behind it is one of the more elegant pieces of engineering in crypto, and knowing how it works also makes it easier to spot a fake claim page.
This article covers how legitimate airdrops are structured. For the scam side of things, meaning tokens that show up in your wallet uninvited or fake claim sites, see our articles on unsolicited tokens and airdrop scams and Sybil attacks and airdrop farming.
The snapshot: freezing a moment in time
An airdrop starts with a snapshot. A project decides on a block number, sometimes announced in advance and sometimes not, and at that exact block it records the state of the blockchain: which addresses held a certain token, used a certain app, provided liquidity, or met whatever criteria the project has chosen.
The snapshot is a still frame, not a live feed. Anything you do with your wallet after that block does not change your eligibility for that particular airdrop. This is why some projects deliberately keep the snapshot block secret until after it has passed, so that nobody can rush in at the last minute purely to qualify.
From that snapshot, the project ends up with a list, usually thousands or millions of addresses, each paired with an amount of tokens it plans to distribute.
Why not just send the tokens directly
In theory a project could just send tokens to every address on that list. In practice, sending thousands or millions of on-chain transfers is expensive and slow, since each transfer costs gas. So most projects flip the model: instead of pushing tokens out to everyone, they let each eligible wallet pull its own tokens by calling a claim function.
That still leaves a problem. The claim contract needs some way to check "is this address on the list, and if so, for how much" without literally storing the entire list on-chain, which would also be expensive. This is where Merkle proofs come in.
What a Merkle tree actually does
A Merkle tree is a way to take a large list of data, in this case addresses and their token amounts, and compress it down into a single short value called a root hash. It works by repeatedly hashing pairs of entries together: first the individual address-and-amount entries are hashed, then those hashes are paired up and hashed again, and so on, layer by layer, until only one hash remains at the top.
That single root hash is small enough to store cheaply in the claim contract itself. The project publishes it as part of deploying the airdrop.
The clever part is what is called a Merkle proof. If you are on the list, the project's claim website can hand you a short chain of hashes, your proof, that lets the smart contract recompute the path from your specific entry all the way up to that stored root hash. If the math checks out and lands exactly on the same root, the contract has cryptographic confidence that your address and amount really were part of the original list, without ever needing to store or check the whole list on-chain.
If your address was not part of the original snapshot, there is no proof that will produce the correct root, so the claim simply fails.
What actually happens when you click "Claim"
When you connect your wallet to a legitimate claim page, the site typically looks up your address in a copy of that original list it hosts off-chain, and if you are on it, generates your Merkle proof automatically. Clicking "Claim" then sends a transaction to the claim contract containing your address, your allotted amount, and that proof. The contract verifies the proof against its stored root, and if it matches, transfers the tokens to you and marks that entry as claimed so it cannot be used twice.
This means the eligibility check you see on a claim page, "you are eligible for X tokens," is really just a preview of a proof that has not been submitted on-chain yet. Nothing is guaranteed or transferred until you send the actual claim transaction and pay the gas for it.
Why claim windows expire
Many airdrops set a deadline, often weeks or months after launch, after which unclaimed tokens are returned to the project's treasury or a community fund. This is partly practical: keeping a claim contract funded and monitored indefinitely has a cost, and partly intentional, since it discourages projects from being pressured to top up allocations for addresses that never claimed. If you are ever notified of an airdrop you are eligible for, it is worth checking the deadline rather than assuming it will always be available.
Reading a claim page with this in mind
Understanding this mechanism gives you a few concrete things to check before claiming anything:
- A real claim contract address should be verifiable on Basescan, and its source code should be public and readable, similar to what we describe in what does a verified contract on Basescan mean.
- The claim transaction should only interact with the claim contract itself. If a "claim" prompts you to sign a broad token approval or a message that looks like a permit for unrelated assets, that is a red flag rather than normal airdrop behavior, as covered in our piece on token approvals.
- Legitimate projects announce snapshots and claim pages through their own official channels, not through unsolicited direct messages telling you to "check your eligibility" on a link.
The cryptography behind an airdrop claim is genuinely neat: it lets a project prove your eligibility out of a list of millions without ever putting that list on-chain. But the proof only verifies that you are on a specific list. It says nothing about whether the site asking you to submit that proof is the real one, so the usual wallet safety habits still apply every time you claim.