Snowman Merkle Airdrop

Description

SnowmanAirdrop.claimSnowman() (src/SnowmanAirdrop.sol L69–L99) never reads s_hasClaimedSnowman, so the "one claim per address" invariant that this variable's name advertises is not enforced anywhere in the contract.

The state variable exists and is maintained:
// src/SnowmanAirdrop.sol L47 mapping(address => bool) private s_hasClaimedSnowman; // mapping to verify if an address has claimed Snowman

// L94, inside claimSnowman s_hasClaimedSnowman[receiver] = true;

// L137-L139 function getClaimStatus(address claimant) public view returns (bool) { return s_hasClaimedSnowman[claimant]; }

But the only three places where it appears are its declaration, its write and its getter. Searching s_hasClaimedSnowman in the source returns exactly those three hits — there is no require(!s_hasClaimedSnowman[receiver]), no custom error guarded by it, and no early return before the mint at L98. The claim path therefore accepts the same redemption any number of times.

Two further details turn this from a bookkeeping gap into an immediately exploitable bug:

1. The signed message does not contain a fixed entitlement. getMessageHash(receiver) (L112–L122) computes the amount from the live token balance at signing time:
   uint256 amount = i_snow.balanceOf(receiver); // L117 return _hashTypedDataV4(keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount}))));

   claimSnowman then rebuilds the leaf with the same live read:
   uint256 amount = i_snow.balanceOf(receiver); // L84 bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount)))); // L86 if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) revert SA__InvalidProof(); // L87

   So a signature is only as durable as the balance that produced it. The moment the receiver's Snow balance returns to the amount committed in its own leaf, the byte-identical (v, r, s) and the unchanged merkleProof verify again — the digest is reproducible and the leaf hash is reproducible. There is no nonce, no deadline, no claimed-amount accounting and no read of s_hasClaimedSnowman to stop a second use.

2. Anyone can trigger it. claimSnowman does not require msg.sender == receiver; _isValidSignature (L102–L109) only checks that the recovered signer equals receiver. In my tests every replay is submitted by satoshi, a third party who is not the beneficiary and who simply pays the gas. Exploiting this finding does not require the victim to cooperate.

In this deployment the tree assigns exactly 1 per whitelisted address (script/flakes/input.json, root 0xc0b6787abae0a5066bc2d09eaec944c58119dc18be796e93de5b2bf9f80ea79a), and Snow.earnSnow() mints exactly 1 free Snow (src/Snow.sol L96), so restoring the matching balance is trivial and repeatable — the loop can be run indefinitely.

Risk

The Merkle root encodes a fixed allocation per address, yet the number of Snowman NFTs minted through the claim path has no upper bound:

• Airdrop supply is uncapped. Each replay mints one more NFT (i_snowman.mintSnowman(receiver, amount), L98) and pulls one more Snow into the contract (L92). getTokenCounter() no longer corresponds to the distribution table the sponsor committed, so total issuance becomes whatever a claimer's balance happened to be times how often it was replayed.

• Individual allocations are exceeded. A user registered for 1 receives 4, 5, or any number they can fund — direct dilution of every other holder's share and of the collection's scarcity.

• On-chain state lies to integrations. getClaimStatus() returns true while nothing blocks another claim, so a front-end, an index or a downstream contract that gates on it will report "already claimed" for an address that can still claim again.

• No cooperation from the victim is needed. Because msg.sender may differ from receiver, any third party can pay gas and re-trigger a beneficiary's mint; the attack is available to whoever watches the mempool, not only to beneficiaries.

The affected value is the airdrop allocation itself (Snow + Snowman NFTs), and the trigger is a single repeated external call with unchanged calldata — high impact, high likelihood.