Snowman Merkle Airdrop

AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Submission Details
Severity: low
Valid

`s_hasClaimedSnowman` is set but never enforced — recipients can claim repeatedly and one signature stays valid forever

Root + Impact

Description

  • Normal behavior: The airdrop is merkle-based: each whitelisted recipient is entitled to claim once, converting their staked Snow balance into Snowman NFTs. After a successful claim the contract should make the same recipient and the same merkle leaf permanently unclaimable, and a recipient's EIP-712 signature should authorize exactly one claim.

  • claimSnowman records s_hasClaimedSnowman[receiver] = true after a successful claim but never checks the flag anywhere in the claim path — the mapping is only read by the getClaimStatus view. Whenever a recipient's Snow balance returns to the merkle-encoded amount, the identical leaf and proof are valid again and the claim succeeds a second, third, ... time. On top of that, the EIP-712 digest bound into the signature is a pure function of live state (receiver + current balanceOf(receiver)) with no nonce, no deadline, no claim index, so the same signature produces the same digest on every future cycle and can be replayed forever by anyone holding it.

in `src/SnowmanAirdrop.sol`:
```solidity
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
...
i_snow.safeTransferFrom(receiver, address(this), amount); // balance -> 0
@> s_hasClaimedSnowman[receiver] = true; // recorded — but never read in this function
@> // missing: if (s_hasClaimedSnowman[receiver]) revert SA__AlreadyClaimed();
emit SnowmanClaimedSuccessfully(receiver, amount);
i_snowman.mintSnowman(receiver, amount);
}
```
And the signature payload, which binds only current balance — no nonce/deadline:
```solidity
function getMessageHash(address receiver) public view returns (bytes32) {
...
uint256 amount = i_snow.balanceOf(receiver);
@> // digest = hash(receiver, balanceOf(receiver)) — identical whenever balance == amount again
return _hashTypedDataV4(
keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount})))
);
}
```

Risk

Likelihood:

  • Reason 1 — A whitelisted recipient's balance returns to the merkle amount on every weekly free earnSnow() (which mints exactly 1, matching the amount = 1 leaves in the shipped tree), so the same leaf/proof become valid again each week.

  • Reason 2 — The "claim on your behalf" flow publishes receiver's v, r, s on-chain; once observed, any third party can replay that signature whenever the signer's balance equals the signed amount — no fresh consent needed.

Impact:

  • Impact 1 — The one-claim-per-recipient guarantee of the merkle tree is defeated: a recipient (or a signature-holder) claims unbounded times across weekly cycles, minting unlimited NFTs per user and making the allocation meaningless for supply control.

  • Impact 2 — Signature replay: an authorization given once is never invalidated, so a third-party executor can silently convert the signer's future Snow into NFTs (burning their tokens) without fresh approval, including front-running the signer.

Proof of Concept

Test: `forge test --match-contract TestSnowmanPoCs --match-test testPoc1_RepeatClaimStaleSignature -vv` (see `poc/TestSnowmanPoCs.t.sol`).
```solidity
// Week 1: alice earns 1 Snow, signs once, satoshi claims for her.
// => getClaimStatus(alice) == true, nft.balanceOf(alice) == 1
// Week 2: alice earns 1 Snow again (weekly earnSnow mints exactly 1).
// satoshi replays the SAME v, r, s and the SAME merkleProof:
airdrop.claimSnowman(alice, proof, v, r, s); // succeeds!
// => getClaimStatus(alice) == true (still), nft.balanceOf(alice) == 2
```
The test passes: two successful claims from the same recipient with the same proof and the same stale signature, even though the claimed flag is set.

Recommended Mitigation

Enforce the flag at the top of `claimSnowman`, and make the signed payload single-use and time-boxed:
```diff
+ error SA__AlreadyClaimed(); // add to the errors block
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
+ if (s_hasClaimedSnowman[receiver]) revert SA__AlreadyClaimed();
...
}
```
```diff
struct SnowmanClaim {
address receiver;
uint256 amount;
+ uint256 nonce; // per-claim counter, monotonically increasing
+ uint256 deadline; // expiry so old signatures die
}
```
Note: `MESSAGE_TYPEHASH` must be recomputed to match the extended struct
(`keccak256("SnowmanClaim(address receiver,uint256 amount,uint256 nonce,uint256 deadline)")`),
and the signer-side digest in `getMessageHash` must include the new fields, otherwise
signatures will not validate.
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 2 hours ago
Submission Judgement Published
Validated
Assigned finding tags:

[L-01] Missing Claim Status Check Allows Multiple Claims in SnowmanAirdrop.sol::claimSnowman

# Root + Impact   **Root:** The [`claimSnowman`](https://github.com/CodeHawks-Contests/2025-06-snowman-merkle-airdrop/blob/b63f391444e69240f176a14a577c78cb85e4cf71/src/SnowmanAirdrop.sol#L44) function updates `s_hasClaimedSnowman[receiver] = true` but never checks if the user has already claimed before processing the claim, allowing users to claim multiple times if they acquire more Snow tokens. **Impact:** Users can bypass the intended one-time airdrop limit by claiming, acquiring more Snow tokens, and claiming again, breaking the airdrop distribution model and allowing unlimited NFT minting for eligible users. ## Description * **Normal Behavior:** Airdrop mechanisms should enforce one claim per eligible user to ensure fair distribution and prevent abuse of the reward system. * **Specific Issue:** The function sets the claim status to true after processing but never validates if `s_hasClaimedSnowman[receiver]` is already true at the beginning, allowing users to claim multiple times as long as they have Snow tokens and valid proofs. ## Risk **Likelihood**: Medium * Users need to acquire additional Snow tokens between claims, which requires time and effort * Users must maintain their merkle proof validity across multiple claims * Attack requires understanding of the missing validation check **Impact**: High * **Airdrop Abuse**: Users can claim far more NFTs than intended by the distribution mechanism * **Unfair Distribution**: Some users receive multiple rewards while others may receive none * **Economic Manipulation**: Breaks the intended scarcity and distribution model of the NFT collection ## Proof of Concept Add the following test to TestSnowMan.t.sol  ```Solidity function testMultipleClaimsAllowed() public { // Alice claims her first NFT vm.prank(alice); snow.approve(address(airdrop), 1); bytes32 aliceDigest = airdrop.getMessageHash(alice); (uint8 v, bytes32 r, bytes32 s) = vm.sign(alKey, aliceDigest); vm.prank(alice); airdrop.claimSnowman(alice, AL_PROOF, v, r, s); assert(nft.balanceOf(alice) == 1); assert(airdrop.getClaimStatus(alice) == true); // Alice acquires more Snow tokens (wait for timer and earn again) vm.warp(block.timestamp + 1 weeks); vm.prank(alice); snow.earnSnow(); // Alice can claim AGAIN with new Snow tokens! vm.prank(alice); snow.approve(address(airdrop), 1); bytes32 aliceDigest2 = airdrop.getMessageHash(alice); (uint8 v2, bytes32 r2, bytes32 s2) = vm.sign(alKey, aliceDigest2); vm.prank(alice); airdrop.claimSnowman(alice, AL_PROOF, v2, r2, s2); // Second claim succeeds! assert(nft.balanceOf(alice) == 2); // Alice now has 2 NFTs } ``` ## Recommended Mitigation **Add a claim status check at the beginning of the function** to prevent users from claiming multiple times. ```diff // Add new error + error SA__AlreadyClaimed(); function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s) external nonReentrant { + if (s_hasClaimedSnowman[receiver]) { + revert SA__AlreadyClaimed(); + } + if (receiver == address(0)) { revert SA__ZeroAddress(); } // Rest of function logic... s_hasClaimedSnowman[receiver] = true; } ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!