Snowman Merkle Airdrop
AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Severity: low
Valid

`SnowmanAirdrop::s_hasClaimedSnowman` is set but never checked - no double-claim prevention

cymans

Root + Impact

Description

  • The SnowmanAirdrop contract has a mapping s_hasClaimedSnowman that tracks whether an address has claimed their Snowman NFT.

  • This mapping is set to true after a successful claim, but the claimSnowman function never checks this value before processing a claim.

  • If a user acquires more Snow tokens after their first claim (via buySnow or earnSnow), and the new balance matches a valid Merkle leaf, they can claim again.

// src/SnowmanAirdrop.sol
​
mapping(address => bool) private s_hasClaimedSnowman; // @> declared
​
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
if (receiver == address(0)) {
revert SA__ZeroAddress();
}
if (i_snow.balanceOf(receiver) == 0) {
revert SA__ZeroAmount();
}
// @> s_hasClaimedSnowman[receiver] is NEVER checked here
​
...
​
s_hasClaimedSnowman[receiver] = true; // @> set but pointless since it's never read
​
emit SnowmanClaimedSuccessfully(receiver, amount);
i_snowman.mintSnowman(receiver, amount);
}

Risk

Likelihood:

  • A user needs to re-acquire Snow tokens and have a matching Merkle proof for their new balance.

  • The Merkle tree is fixed at deployment, so the new balance must match an existing leaf.

Impact:

  • Users can potentially receive more Snowman NFTs than intended.

  • The airdrop distribution fairness is compromised.

Proof of Concept

The contract writes s_hasClaimedSnowman[receiver] = true after a successful claim, suggesting the developer intended to prevent double-claiming. However, this value is never read or checked anywhere in the contract. The claimSnowman function does transfer the user's Snow tokens away (making it harder to immediately claim again), but if a user re-acquires Snow tokens matching their Merkle leaf amount, they can claim again.

Step-by-step scenario:

  1. Alice is in the Merkle tree with an allocation of 1 Snow token.

  2. Alice calls earnSnow() and receives 1 Snow token. She now has a balance of 1.

  3. Alice (or someone on her behalf) calls claimSnowman() with a valid Merkle proof and signature.

  4. Her 1 Snow token is transferred to the contract, and she receives 1 Snowman NFT. s_hasClaimedSnowman[alice] is set to true.

  5. Alice calls earnSnow() again the following week (or buySnow()) and gets 1 Snow token again.

  6. Alice calls claimSnowman() again with the same Merkle proof. The function never checks s_hasClaimedSnowman[alice], so it passes.

  7. Her Snow token is transferred again, and she receives another Snowman NFT. Alice now has 2 NFTs from a 1-NFT allocation.

function testDoubleClaimPossible() public {
// Step 1: Alice has Snow tokens matching her Merkle leaf
vm.prank(alice);
snow.earnSnow();
assertEq(snow.balanceOf(alice), 1);
​
// Step 2: Alice claims successfully — tokens transferred, NFT received
vm.prank(alice);
snowmanAirdrop.claimSnowman(alice, aliceProof, v, r, s);
assertEq(snowman.balanceOf(alice), 1);
assertEq(snow.balanceOf(alice), 0);
​
// Step 3: Alice re-acquires Snow tokens
vm.warp(block.timestamp + 1 weeks + 1);
vm.prank(alice);
snow.earnSnow();
assertEq(snow.balanceOf(alice), 1);
​
// Step 4: Alice claims again — s_hasClaimedSnowman is never checked
vm.prank(alice);
snowmanAirdrop.claimSnowman(alice, aliceProof, v2, r2, s2);
assertEq(snowman.balanceOf(alice), 2); // Double the intended allocation
}

Recommended Mitigation

Add a check at the beginning of claimSnowman that reads s_hasClaimedSnowman[receiver] and reverts if the user has already claimed. The mapping is already being written to after each claim, so the only missing piece is the read/check before processing. This ensures each eligible address can only claim their Snowman NFT allocation once, preserving the airdrop's fair distribution.

+ error SA__AlreadyClaimed();
​
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
if (receiver == address(0)) {
revert SA__ZeroAddress();
}
+ if (s_hasClaimedSnowman[receiver]) {
+ revert SA__AlreadyClaimed();
+ }
if (i_snow.balanceOf(receiver) == 0) {
revert SA__ZeroAmount();
}
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 4 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!