What a merkle airdrop actually is.

A merkle airdrop distributes tokens without ever writing the recipient list on-chain. Instead of storing thousands of addresses, the contract stores a single 32-byte hash called a merkle root. Each recipient shows up, proves their own entry belongs under that root, and takes their share.

The whole design exists to move a cost. Nothing about it is cryptographically exotic, and understanding it takes about five minutes.

The problem it solves

Sending tokens to a list means one transfer per address, and every transfer is a separate write to chain state. The cost scales with the list and it is paid entirely by you, up front, for every recipient, including everyone who never comes to collect.

On a list of a few hundred that is merely expensive. On a few thousand it stops being a plan. Worse, you pay for the roughly half of any airdrop list that never claims anything.

A merkle airdrop inverts that. You write one hash. Each recipient pays their own gas, and only if they actually want the tokens.

How a merkle tree turns a list into one hash

Take the list of recipients and amounts. Hash each entry. That gives you a row of hashes, called leaves. Now hash them in pairs, giving a shorter row. Hash that row in pairs. Repeat until one hash remains. That final hash is the root.

Two properties make the structure useful:

• The root commits to every entry. Change one address or one amount anywhere in the list and the root changes completely. It is a fingerprint of the exact list.
• You can prove one entry without revealing the rest. To show your leaf sits under the root, you need only the sibling hash at each level, which is a handful of values rather than the whole list.

That short set of siblings is your merkle proof.

What actually happens when you claim

The contract does not look you up in a list, because there is no list. It rebuilds the root from what you hand it.

1. You submit your index, your address, your amount and your proof.
2. The contract hashes your entry into a leaf.
3. It combines that leaf with each sibling in your proof, level by level, until it has a root.
4. If that root equals the one published at creation, your entry was in the original list and has not been altered. If it does not, the claim reverts.

Nobody is trusted at any point in that sequence. The proof either rebuilds the root or it does not, and a forged entry cannot, because finding a different input that hashes to the same root is the thing hash functions are built to make infeasible.

What the design guarantees, and what it does not

A merkle root is a strong commitment to a specific list. It is not a statement about whether that list is fair, and the two get confused constantly.

• It guarantees the list cannot change quietly. Any edit produces a different root, and the root is public from the moment the airdrop is created.
• It guarantees nobody can claim twice. The contract records each claimed index in a bitmap, so a second attempt on the same index reverts.
• It says nothing about who is on the list. A root commits to a snapshot; it does not tell you the snapshot was taken honestly. That is a question about the creator, not about the cryptography.
• It does not by itself stop a creator taking the tokens back. That depends on what the contract permits after the deadline, which is worth reading before you rely on a claim window.

How HoodLock implements it

The airdrop contract publishes a root at creation and never lets anyone alter it. Specifically:

• No admin function can move a funded airdrop's tokens or change its root. Not the creator, not us. Redistributing would mean creating a different airdrop.
• A deadline is optional, and zero means forever. An airdrop created with no deadline is claimable indefinitely and its tokens can never be swept.
• If a deadline is set, it must leave a real window. The contract enforces a minimum of seven days, because a deadline short enough that nobody can realistically claim is a way to look generous without being generous.
• Unclaimed tokens return only after the deadline. The sweep is creator-only and rejects any call before the deadline passes, so the claim window and the sweep window cannot overlap.
• Claiming is free of protocol fees. The fee is charged once, to the creator, at creation. Claimants pay gas and nothing else.

The mechanics of running one are in the airdrops reference, and how to airdrop tokens on Robinhood Chain walks through the actual steps.

Common questions

Why not just send the tokens to everyone?

Because a transfer to each address is a separate state write, and the cost scales with the list. A few hundred recipients is expensive; a few thousand is prohibitive. A merkle airdrop writes one hash at creation and moves the per-recipient cost to the recipient, who pays gas only if they want the tokens.

What is a merkle proof?

The short list of sibling hashes needed to rebuild the root from your own entry. The contract hashes your entry, combines it with each sibling in turn, and checks that the result equals the published root. If it does, your entry was in the original list and nothing about it has been altered.

Can the creator change the list after publishing it?

Not on HoodLock. The root is set when the airdrop is created and no admin or creator function alters it or moves the funded tokens. Changing who gets what would mean creating a different airdrop.

What happens to tokens nobody claims?

It depends on whether a deadline was set. With no deadline the airdrop is claimable forever and the tokens can never be swept. With a deadline, the creator can reclaim the unclaimed remainder, but only after the deadline has passed, so the claim window and the sweep window can never overlap.

Does claiming cost anything?

Gas only. The protocol fee is charged once, to the creator, when the airdrop is created. Claiming is always free of protocol fees.

Keep reading

• Check an airdrop with the airdrop checker
• How to airdrop tokens on Robinhood Chain
• Airdrops — the product reference
• What is a token unlock schedule?
• Circulating vs total supply