s_hasClaimedSnowman is written but never read, so the same Merkle proof and signature can be replayed to mint NFTs repeatedly
Root + Impact
Description
SnowmanAirdrop records that a receiver has claimed by writing s_hasClaimedSnowman[receiver] = true, but no code path ever reads that mapping. claimSnowman() never checks it, and the only reader in the whole contract is the external getClaimStatus() view, which exists for display purposes only.
Duplicate protection therefore rests entirely on the receiver's SNOW balance being zero after the transfer. That holds only until the balance is restored, and every value used to validate the claim is a pure function of the balance or of immutable data:
getMessageHash(receiver)derives the digest fromi_snow.balanceOf(receiver), so restoring the balance restores the exact same digest and the old signature becomes valid again.The leaf is
keccak256(bytes.concat(keccak256(abi.encode(receiver, amount)))), a pure function of(receiver, amount), so the same proof verifies again.There is no nonce, no deadline, and no claim-state check anywhere in the path.
Restoring the balance is free: earnSnow() mints 1 wei of SNOW per week, and every leaf in this tree commits to amount = 1 wei. A claimer can therefore loop claim -> earnSnow() -> claim once a week indefinitely, minting a new batch of NFTs from a single entitlement.
Risk
Likelihood: High. The only requirement is re-acquiring the exact SNOW amount already committed in the proof. For every eligible claimer that amount is 1 wei, which earnSnow() distributes for free once per week, so the loop needs no capital and no special conditions. The same signature and proof are reused unchanged.
Impact: High. One airdrop entitlement yields an unbounded number of NFTs, so the collection supply is not the fixed distribution the protocol intends. The claim flag the protocol relies on records the repeat claims but has no effect on them.
Proof of Concept
The test claims for Alice through a relayer, restores her balance with a free earnSnow() call one week later, and claims a second time with the identical proof and signature. The getClaimStatus assertion in between demonstrates that the protocol knows the address already claimed and still processes the second claim.
Recommended Mitigation
Enforce the flag that the contract already maintains. Add the check at the top of claimSnowman() so that a receiver can only ever be processed once, regardless of how their balance changes afterwards.
Lead Judging Commences
[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; } ```
Rewards breakdown
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.