Submission Details
Severity:
MerkleAirdrop (First Flight #14: Airdropper) — Security Audit Report
# MerkleAirdrop (First Flight #14: Airdropper) — Security Audit Report
**Auditor:** Buffy (AI-assisted security review)
**Date:** September 8, 2026
**Repository:** `2024-04-airdropper` (`cyfrin/2024-04-airdropper`), commit `d0d44ae`
**Methodology:** Manual review, merkle-tree mathematics re-derived with `keccak256` primitives, and Foundry proof-of-concept tests.
> ⚠️ Disclaimer: This report was prepared on the **as-is** codebase, which the sponsor states *"was made with bugs and flaws on purpose"* and should not be used without review. Findings are ranked by the CodeHawks severity rubric (High / Medium / Low / Informational).
---
## About
The project airdrops **100 USDC** on the zkSync Era chain to **4 lucky addresses** (25 USDC each), based on their Ethereum L1 activity. Eligibility is encoded in a Merkle tree: the owner deploys `MerkleAirdrop` with a root, funds it with USDC, and each eligible address calls `claim(account, amount, merkleProof)` — paying a `1e9` wei (`FEE`) ETH fee — to receive their tokens. The owner can later sweep accumulated ETH fees with `claimFees()`.
The contract claims to be based on the [Uniswap Merkle-Distributor](https://github.com/Uniswap/merkle-distributor).
### Audit scope
| File | Purpose |
| --- | --- |
| `src/MerkleAirdrop.sol` | The airdrop contract (63 nSLOC) |
| `script/Deploy.s.sol` | Deployment + funding script (25 lines) |
- Solc: `0.8.24` — Target chain: zkSync Era — nSLOC (scope): 62
- Out of scope (used as context only): `test/`, `makeMerkle.js`, `tree.json`, mocks.
### Roles
- **Owner** — the deployer; the only role that may withdraw the ETH claim fees (`claimFees`).
- **Eligible users** — the 4 addresses whose leaves are in the Merkle tree; the only addresses that may receive airdrop tokens.
- **Anyone** — may call `claim` (the contract is open; claims pay the fee).
---
## Summary of findings
| ID | Severity | Title |
| --- | --- | --- |
| [H-1]() | **High** | Users can claim multiple times — missing “already claimed” tracking lets one address drain the entire airdrop |
| [H-2]() | **High** | Deployed Merkle root encodes 18-decimal amounts while the USDC airdrop is 6-decimal — as deployed, no one can claim and funds are locked |
| [L-1]() | **Low** | Unclaimed or leftover airdrop tokens are unrecoverable (no ERC-20 rescue path) |
| [I-1]() | **Informational** | `claim` is not bound to `msg.sender` |
| [I-2]() | **Informational** | `MerkleRootUpdated` event is dead code; the root can never be updated |
| [I-3]() | **Informational** | Missing zero-address / zero-value validation in `constructor` and `claim` |
---
# Findings
## [H-1] — Users can claim multiple times / drain the entire airdrop (no one-time-claim check)
**Severity:** High
**Affected:** `src/MerkleAirdrop.sol::claim` (lines 30–40)
### Summary
`claim` verifies that a caller can produce a valid Merkle proof, pays out the tokens, and **records nothing**. The same proof can be replayed an unlimited number of times, so a single eligible address can claim its own 25 USDC allocation over and over until the whole 100 USDC pool is drained into that one address. The remaining eligible users receive nothing.
### Explainer
Think of the Merkle tree as a stack of physical gift coupons: one per address, each worth 25 USDC. The contract checks “is this a genuine coupon?” (the Merkle proof) — but it never tears the coupon up after use. It has no list of “already redeemed” coupons. So the same genuine coupon can be redeemed again and again. One person can keep walking up to the counter and redeeming everyone else’s coupons until the till is empty.
The sponsor even says the contract is based on Uniswap’s `MerkleDistributor`, which keeps a `claimedBitMap` (`isClaimed` / `_setClaimed`) precisely to prevent this. That state was left out here.
### Vulnerability details
```solidity
function claim(address account, uint256 amount, bytes32[] calldata merkleProof) external payable {
if (msg.value != FEE) {
revert MerkleAirdrop__InvalidFeeAmount();
}
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(account, amount))));
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) {
revert MerkleAirdrop__InvalidProof();
}
emit Claimed(account, amount);
i_airdropToken.safeTransfer(account, amount); // no state is written anywhere
}
```
The Uniswap reference keeps a bit-per-leaf `_claimedBitMap`, marks the leaf claimed (`_setClaimed`) **before** transferring, and reverts if it was already claimed. This contract has:
- no `isClaimed` mapping / bitmap,
- no `_setClaimed` before the transfer,
- no nonce / index bound to the leaf.
Because `claim` never writes state, the “checks-effects-interactions” order is vacuous: nothing prevents an identical, already-executed call from executing again. Since the payout goes to the leaf’s `account`, the effective attack is:
1. **An eligible address (e.g. one of the 4 recipients) calls `claim` for its own leaf** — valid proof → receives 25 USDC.
2. It repeats the exact same call 3 more times (paying only 1 gwei fee each) → receives the entire 100 USDC pool.
3. The other 3 recipients can no longer claim (pool is empty; their `safeTransfer` reverts).
A non-eligible bystander cannot *steal* (tokens always go to the leaf’s `account`), but can trigger the same drain on behalf of any tree member, exhausting the pool before the intended users can claim and choosing which recipient gets everything.
### Impact
- Loss of funds: the entire airdrop pool can be captured by a single eligible participant (or funneled to any chosen tree member by a third party); the rest of the recipients get nothing.
- If the pool is ever topped up (or was over-funded), repeated claims keep withdrawing until it is empty.
### Proof of concept
PoC test (Foundry, run against the project’s own test-tree root where each leaf is `25e6`, pool = 100 USDC):
```solidity
// collectorOne is entitled to ONE claim of 25 USDC. They claim 4x instead.
vm.startPrank(collectorOne);
for (uint256 i = 0; i < 4; i++) {
airdrop.claim{ value: fee }(collectorOne, 25 * 1e6, testProof());
}
vm.stopPrank();
assertEq(token.balanceOf(collectorOne), 100 * 1e6); // entire pool taken by ONE user
assertEq(token.balanceOf(address(airdrop)), 0);
// collectorTwo — also in the tree, entitled to 25 USDC — can no longer claim:
vm.prank(collectorTwo);
vm.expectRevert();
airdrop.claim{ value: fee }(collectorTwo, 25 * 1e6, testProof());
```
```
forge test --match-test testPoC_DoubleClaimDrainsWholeAirdrop -vv
[PASS] testPoC_DoubleClaimDrainsWholeAirdrop()
```
### Recommended mitigation
Mirror the Uniswap implementation the project claims to follow:
- Store a claimed record per leaf — e.g. `mapping(bytes32 => bool) private s_claimed;` or Uniswap’s `mapping(uint256 => uint256) private _claimedBitMap` (keyed by leaf index).
- In `claim`, revert with a dedicated error (e.g. `MerkleAirdrop__AlreadyClaimed()`) if the leaf was already claimed.
- Mark the leaf claimed **before** the external token transfer (checks-effects-interactions).
---
## [H-2] — Deployed Merkle root uses 18-decimal amounts against a 6-decimal USDC airdrop — airdrop unclaimable / funds locked
**Severity:** High
**Affected:** `script/Deploy.s.sol` (`s_merkleRoot` line 9, `s_amountToAirdrop` line 11, funding line 18), interacting with `src/MerkleAirdrop.sol::claim`
### Summary
The Merkle root hard-coded in `Deploy.s.sol` (`0xf69aaa25bd4dd10deb2ccd8235266f7cc815f6e9d539e9f4d47cae16e0c36a05`) was generated with leaf amounts of **`25 * 1e18`** per user, while the deployed airdrop is **USDC (6 decimals)**, funded with only **`4 × 25e6 = 100e6`** units, and each user is supposed to receive **25 USDC = `25e6`**. The numbers disagree by a factor of `1e12`.
Concretely, as deployed:
- A claim of the *intended* amount (25 USDC = `25e6`) **fails the Merkle proof** — no leaf in the deployed tree matches.
- A claim that *would* pass the proof requires `25e18` units (~25 billion USDC) per user — but the entire contract holds `100e6`. The token transfer reverts.
Every possible claim reverts, nobody receives anything, and the **100 USDC is locked in the contract permanently** (there is no ERC-20 withdrawal function; see [L-1]()).
### Explainer
The project did its money math and its “guest-list” math in two different units.
- **Money math (funding & intent):** 25 USDC each × 4 users = 100 USDC. USDC has 6 decimal places, so 25 USDC = `25 × 10⁶` smallest units (`Deploy.s.sol` funds `4 * (25 * 1e6)`, and the repo’s own tests claim `25 * 1e6` per user).
- **Guest-list math (Merkle tree):** `makeMerkle.js` builds each leaf with amount `(25 * 1e18)`, as if the token had 18 decimal places. That root (`0xf69aaa…`, also dumped in `tree.json`) is the root hard-coded in `Deploy.s.sol`.
The Merkle proof only proves membership of a leaf *with the exact amount used at tree-build time*. So a valid claim must name `25e18` — but the wallet being emptied only ever holds `100e6`. Either the proof fails (claiming `25e6`) or the bank transfer fails (claiming `25e18`). The airdrop cannot happen, and because there is no mechanism to withdraw the token, the deposit is stranded.
### Evidence (independently re-derived)
The leaf scheme is `leaf = keccak256(keccak256(abi.encode(address, uint256)))`, which is exactly the OpenZeppelin `standard-v1` leaf hash, and internal nodes hash the two children in ascending byte order. Re-computing the trees from the four addresses with `cast keccak`:
| Leaf amounts used | Resulting root | Matches |
| --- | --- | --- |
| `25e18` per user (what `makeMerkle.js` + `Deploy.s.sol` use) | `0xf69aaa25bd4dd10deb2ccd8235266f7cc815f6e9d539e9f4d47cae16e0c36a05` | `tree.json` + `Deploy.s.sol::s_merkleRoot` ✅ |
| `25e6` per user (correct 6-decimal amounts) | `0x3b2e22da63ae414086bec9c9da6b685f790c6fab200c7918f2879f08793d77bd` | `test/MerkleAirdropTest.t.sol` ✅ |
So the **unit tests** were generated with correct `25e6` amounts, but the **deployment** constants embed a tree built with `25e18` amounts. The two halves of the codebase contradict each other, and the deploy script is the one that will run on mainnet.
### Proof of concept
Replicating `Deploy.s.sol` exactly (root `0xf69aaa…`, 6-decimal token, funded `100e6`):
```solidity
// sanity: the stored proof DOES verify for leaf (collectorOne, 25e18)
bytes32 leaf18 = keccak256(bytes.concat(keccak256(abi.encode(collectorOne, 25 * 1e18))));
assertTrue(MerkleProof.verify(deployProof(), deployRoot, leaf18));
// A "correct" claim of 25 USDC (25e6) fails the proof:
vm.expectRevert();
airdrop.claim{ value: fee }(collectorOne, 25 * 1e6, deployProof()); // InvalidProof
// A claim that WOULD pass the proof needs 25e18 (~25 billion USDC), while the
// whole pool holds 100e6 -> transfer reverts:
vm.expectRevert();
airdrop.claim{ value: fee }(collectorOne, 25 * 1e18, deployProof()); // revert (insufficient balance)
// Consequence: the entire 100 USDC is stuck in the contract forever.
assertEq(token.balanceOf(address(airdrop)), 100 * 1e6);
```
```
forge test --match-test testPoC_DeployedRootMakesAirdropImpossible -vv
[PASS] testPoC_DeployedRootMakesAirdropImpossible()
```
### Impact
- The airdrop — the entire purpose of the protocol — cannot be executed on mainnet with the shipped `Deploy.s.sol`.
- The 100 USDC deposited by the deployer is **permanently locked**: `claim` is the only function that moves the airdrop token, and every claim path reverts. `claimFees` only moves ETH.
### Recommended mitigation
- Regenerate the Merkle tree using the token’s actual decimals: in `makeMerkle.js` set `const amount = (25 * 1e6).toString()` (25 USDC @ 6 decimals), regenerate `tree.json`, and update `s_merkleRoot` in `Deploy.s.sol` to the new root.
- Have `makeMerkle.js` write the root + proofs from the same constants the deploy/funding math uses, so the two cannot drift.
- Add a deploy-consistency test asserting that the funding amount equals `numberOfLeaves × leafAmount`, and that a sample proof verifies against `s_merkleRoot` with the funded token’s decimals.
---
## [L-1] — Unclaimed or leftover airdrop tokens are unrecoverable
**Severity:** Low
**Affected:** `src/MerkleAirdrop.sol` (whole contract surface)
### Summary
`MerkleAirdrop` exposes exactly one way to move the airdrop token: `claim`, which pays out only to leaves in the fixed tree. There is no deadline, no owner sweep for the ERC-20 token, and no refund function. Any allocation that is never claimed (lost keys, abandoned address, blacklisted recipient, etc.) — or any leftover balance — remains locked in the contract forever. `claimFees()` only withdraws **ETH**.
### Explainer
Imagine handing a cashier a stack of coupons and telling them “redeem these four.” If one coupon is never brought in, the cashier has no instruction for what to do with that money at the end of the day, and no button to give it back to you. Any unspent deposit just sits in the register forever. For a one-shot, fixed-list airdrop this is a real operational risk (and it is what makes H-2’s stranded deposit permanent).
### Impact
- Permanently locked user/protocol funds if any recipient never claims (or, per H-2, if the deployed root is wrong).
- No mechanism to recover an accidental over-funding of the contract.
### Recommended mitigation
- Add an owner-only `withdrawTokens(token, to, amount)` (or a time-locked refund after a claim deadline) restricted to **unclaimed/leftover** balances — e.g. track the total claimed amount and only allow sweeping `balance − Σclaims`, or sweep per-unclaimed-leaf after an expiry timestamp.
---
## [I-1] — `claim` is not bound to `msg.sender` (Informational)
**Severity:** Informational
**Affected:** `src/MerkleAirdrop.sol::claim` (line 30)
### Summary
`claim` never checks `msg.sender == account`. Any address can submit a claim for any tree member. Because the payout goes to the leaf’s `account`, this alone does not let an outsider steal — it lets anyone force payouts on behalf of the four recipients and pick who is paid first (an amplification factor of [H-1]).
### Explainer
The coupon can be handed to the cashier by anyone — the cashier doesn’t check who is holding it, only that the coupon is genuine and names a real recipient. If the coupon is single-use (after fixing H-1) this is mostly harmless: the recipient still gets exactly their 25 USDC, someone else just paid the 1 gwei fee and front-ran them. Combined with the missing single-use check (H-1), it lets a stranger drain the pool into whichever recipient they choose. Worth tightening while fixing H-1.
### Recommended mitigation
Require `msg.sender == account` in `claim` (or bind the caller into the leaf at tree-generation time). If claiming on behalf of others is a wanted feature, keep it, but fix H-1 first.
---
## [I-2] — `MerkleRootUpdated` event declared but never emitted (Informational)
**Severity:** Informational
**Affected:** `src/MerkleAirdrop.sol` (line 20)
### Summary
`event MerkleRootUpdated(bytes32 newMerkleRoot);` is declared (line 20) but never emitted, and `i_merkleRoot` is `immutable` (line 17) with no setter. The event is dead code and signals an intended root-rotation feature that does not exist. If the recipient list ever needs to change (typo, blacklisted recipient, re-issued amounts), the only option is a full re-deploy — and the previous contract’s funding is stranded (see L-1/H-2).
### Recommended mitigation
Either remove the unused event, or — if root rotation is intended — add an owner-only `updateMerkleRoot(bytes32)` that emits it, together with an explicit token-recovery path for the old tree’s unclaimed balance.
---
## [I-3] — Missing input validation (Informational)
**Severity:** Informational
**Affected:** `src/MerkleAirdrop.sol` (constructor line 25, `claim` line 30)
### Summary
The constructor does not validate `merkleRoot != bytes32(0)` or `airdropToken != address(0)`, and `claim` does not validate `account != address(0)` / `amount != 0`. A typo’d constructor argument (zero token address) silently deploys a bricked contract; in `claim` these degenerate inputs simply never verify against a well-formed tree, so the practical risk is low.
### Recommended mitigation
Add `require`s/errors in the constructor (`airdropToken != address(0)`, `merkleRoot != bytes32(0)`) and cheap sanity checks in `claim` (`account != address(0)`, `amount != 0`).
---
# Appendix A — Verification notes (what was checked and is fine)
To avoid false positives, the following were explicitly verified during the review:
1. **Leaf encoding is consistent.** `leaf = keccak256(keccak256(abi.encode(account, amount)))` exactly matches OpenZeppelin `@openzeppelin/merkle-tree`’s `standard-v1` leaf hash (`keccak256(keccak256(abi.encode(value)))`), including the sorted-hash pairing of internal nodes. Both `tree.json`’s root and the test suite’s root were **reproduced exactly** from the four addresses (`0x20F4…`, `0x277D…`, `0x0c8C…`, `0xf6dB…`), so this is not a bug.
2. **Fee handling.** `msg.value != FEE` reverts, so an over-payment is returned to the caller via revert rather than stuck.
3. **Reentrancy.** `claim` performs a single external token transfer at the end and mutates no state; `claimFees` is owner-only and sends ETH to `owner()`. No viable reentrancy path was identified.
4. **No additional zkSync-specific flaw** was identified in the two in-scope files within the limits of this review (logic validated on EVM-equivalent semantics via Foundry).
# Appendix B — Reproduction
The PoC tests were executed in a sandbox copy of the repo (dependencies pinned to `forge-std@v1.8.1` and `openzeppelin-contracts@v5.0.2`, as in the Makefile):
```bash
forge test --match-contract AuditPoC -vv
```
```
Ran 2 tests for test/AuditPoC.t.sol:AuditPoC
[PASS] testPoC_DeployedRootMakesAirdropImpossible() (gas: 1744968)
[PASS] testPoC_DoubleClaimDrainsWholeAirdrop() (gas: 1809120)
Suite result: ok. 2 passed
```
(The project’s own tests — `testUsersCanClaim`, `testPwned` — also pass unchanged.)
Updates
Lead Judging Commences
ai-first-flight-judge about 2 hours ago
Submission Judgement Published Assigned finding tags:
[H-02] Eligible users can claim their airdrop amounts over and over again, draining the contract
## Description A user eligible for the airdrop can verify themselves as being part of the merkle tree and claim their airdrop amount. However, there is no mechanism enabled to track the users who have already claimed their airdrop, and the merkle tree is still composed of the same user. This allows users to drain the `MerkleAirdrop` contract by calling the `MerkleAirdrop::claim()` function over and over again. ## Impact **Severity: High**<br/>**Likelihood: High** A malicious user can call the `MerkleAirdrop::claim()` function over and over again until the contract is drained of all its funds. This also means that other users won't be able to claim their airdrop amounts. ## Proof of Code Add the following test to `./test/MerkleAirdrop.t.sol`, ```javascript function testClaimAirdropOverAndOverAgain() public { vm.deal(collectorOne, airdrop.getFee() * 4); for (uint8 i = 0; i < 4; i++) { vm.prank(collectorOne); airdrop.claim{ value: airdrop.getFee() }(collectorOne, amountToCollect, proof); } assertEq(token.balanceOf(collectorOne), 100e6); } ``` The test passes, and the malicious user has drained the contract of all its funds. ## Recommended Mitigation Use a mapping to store the addresses that have claimed their airdrop amounts. Check and update this mapping each time a user tries to claim their airdrop amount. ```diff contract MerkleAirdrop is Ownable { using SafeERC20 for IERC20; error MerkleAirdrop__InvalidFeeAmount(); error MerkleAirdrop__InvalidProof(); error MerkleAirdrop__TransferFailed(); + error MerkleAirdrop__AlreadyClaimed(); uint256 private constant FEE = 1e9; IERC20 private immutable i_airdropToken; bytes32 private immutable i_merkleRoot; + mapping(address user => bool claimed) private s_hasClaimed; ... function claim(address account, uint256 amount, bytes32[] calldata merkleProof) external payable { + if (s_hasClaimed[account]) revert MerkleAirdrop__AlreadyClaimed(); if (msg.value != FEE) { revert MerkleAirdrop__InvalidFeeAmount(); } bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(account, amount)))); if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) { revert MerkleAirdrop__InvalidProof(); } + s_hasClaimed[account] = true; emit Claimed(account, amount); i_airdropToken.safeTransfer(account, amount); } ``` Now, let's unit test the changes, ```javascript function testCannotClaimAirdropMoreThanOnceAnymore() public { vm.deal(collectorOne, airdrop.getFee() * 2); vm.prank(collectorOne); airdrop.claim{ value: airdrop.getFee() }(collectorOne, amountToCollect, proof); vm.prank(collectorOne); airdrop.claim{ value: airdrop.getFee() }(collectorOne, amountToCollect, proof); } ``` The test correctly fails, with the following logs, ```shell Failing tests: Encountered 1 failing test in test/MerkleAirdropTest.t.sol:MerkleAirdropTest [FAIL. Reason: MerkleAirdrop__AlreadyClaimed()] testCannotClaimAirdropMoreThanOnceAnymore() (gas: 96751) ```
Rewards breakdown
This contest has a flat reward structure with the following payouts:
Live
The contest is live. Earn rewards by submitting a finding.
Judging
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsRewards Distribution
The contest is complete and the rewards are being distributed.