Merkle Airdrop Explained in Detail
A Merkle airdrop stores one Merkle root on-chain instead of storing every eligible user. Each user submits a claim and a Merkle proof showing their data is included in the tree.
The leaf usually includes the recipient, amount, and sometimes an index or drop ID.
Smart contract example
bytes32 leaf = keccak256(abi.encode(index, account, amount));
The exact leaf format must match the off-chain tree generation.
Merkle Airdrop in Auditing
Merkle airdrop bugs can allow double claims, wrong-recipient claims, wrong amounts, or invalid proof acceptance.
Auditors review leaf encoding, proof verification, root updates, and claim tracking.
Red flags in code
-
The leaf omits recipient or amount.
-
Claims are not marked as used.
-
abi.encodePackedcreates collision risk with variable-length fields. -
Root can be changed without controls.
-
Duplicate leaves or indexes behave unexpectedly.
How to test or review it
-
Claim the same leaf twice and expect failure.
-
Try claiming another user's amount.
-
Mutate index, account, amount, and proof order.
-
Test root updates and old proof behavior.
-
Verify off-chain tree generation matches on-chain leaf encoding.
Keep learning this topic
Merkle Proof
A Merkle proof is a list of sibling hashes used to prove that a leaf belongs to a Merkle tree with a known root.
abi.encodePacked
abi.encodePacked is a Solidity encoding function that tightly packs values without the padding, offsets, and dynamic-length delimiters used by abi.encode.
Replay Attack
A replay attack reuses a valid transaction, signature, message, or proof in a context where it should only be valid once.
Practice this in real audit scenarios
Definitions help, but auditors need reps. SCH turns concepts like Merkle Airdrop into exploit labs, code review habits, and report-writing practice.
Start the free trial or see the full smart contract auditing course.