Snowman Merkle Airdrop

Description

The SnowmanAirdrop contract is meant to let each eligible address claim their Snowman NFT exactly once. It declares an s_hasClaimedSnowman mapping specifically to track whether an address has already claimed, implying a one-claim-per-address invariant is intended. However, claimSnowman writes to this mapping but never reads it as a guard. It sets s_hasClaimedSnowman[receiver] = true at the end, yet never checks it at the start to block repeat claims. The flag is written but never enforced, so the intended one-claim-per-address rule does not hold. Since the only balance gate is i_snow.balanceOf(receiver) == 0, a user who already claimed only needs a non-zero Snow balance again to re-enter, which is trivial because the protocol lets users farm free Snow weekly.

Risk

Likelihood: HIGH

A user who already claimed earns new Snow tokens via the normal weekly farming mechanism, restoring a non-zero balance so the balanceOf(receiver) == 0 check passes again.
Any eligible address can trigger this repeatedly, with no special privileges or timing required.

Impact: HIGH

A single eligible address can mint unlimited Snowman NFTs instead of exactly one.
This drains the entire NFT airdrop supply and breaks the fairness of the distribution.
Legitimate claimants may be left unable to receive their NFTs because supply is exhausted by repeat claimers.
Proof of Concept

The root cause is that the s_hasClaimedSnowman flag is set but never checked in claimSnowman:

solidity
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();
// @> No check on s_hasClaimedSnowman[receiver], so a repeat claim is not blocked

if (!_isValidSignature(receiver, getMessageHash(receiver), v, r, s)) revert SA__InvalidSignature();

uint256 amount = i_snow.balanceOf(receiver);
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) revert SA__InvalidProof();

i_snow.safeTransferFrom(receiver, address(this), amount);
s_hasClaimedSnowman[receiver] = true; // @> flag written but never read as a guard
emit SnowmanClaimedSuccessfully(receiver, amount);
i_snowman.mintSnowman(receiver, amount);

}

Attack sequence:

An eligible receiver with a non-zero Snow balance calls claimSnowman. All checks pass, tokens are transferred, s_hasClaimedSnowman[receiver] is set to true, and NFTs are minted.
The same receiver earns new Snow tokens through weekly farming, so balanceOf(receiver) is non-zero again.
The receiver calls claimSnowman again. The balanceOf == 0 check passes, the signature and Merkle proof still validate, and because s_hasClaimedSnowman is never checked, the claim succeeds again and mints more NFTs.
Steps 2 and 3 can be repeated indefinitely, minting unlimited NFTs from one address.
Recommended Mitigation

Add a guard at the start of claimSnowman and define a matching error:

solidity 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(); // @> enforce one claim per address
if (i_snow.balanceOf(receiver) == 0) revert SA__ZeroAmount();

// ... rest unchanged

}

This makes the s_hasClaimedSnowman mapping actually enforce the one-claim-per-address invariant, so repeat claims revert regardless of the caller's current Snow balance.