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

`SnowmanAirdrop::claimSnowman` binds eligibility to the live `balanceOf`, any balance change bricks the claim

furkanumut

Root + Impact

Description

A whitelisted user claims their Snowman NFTs by presenting a Merkle proof and an EIP-712 signature for their allocation. However, both the Merkle leaf and the signed digest are recomputed from Snow::balanceOf(receiver) at execution time instead of from an amount committed in the tree, so any balance movement after the snapshot — including the protocol's own earnSnow/buySnow, or 1 wei of dust sent by anyone — makes the claim revert until the user manually rebalances.

// File: src/SnowmanAirdrop.sol — Lines 76–90
if (i_snow.balanceOf(receiver) == 0) { revert SA__ZeroAmount(); }
// ...
@> uint256 amount = i_snow.balanceOf(receiver); // execution-time state, not the committed allocation
@> bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) { revert SA__InvalidProof(); }

The tree commits to (receiver, amount) pairs fixed at snapshot time. Because the contract re-derives amount from the live balance, the leaf only matches when the current balance equals the snapshot balance exactly. A user who follows the intended flow — earning 1 free Snow per week — silently loses claimability the moment their balance moves, and there is no on-chain alternate settlement path: the only recovery is for each affected user to figure out they must transfer the exact excess Snow away themselves. The same mechanism is a griefing vector: anyone can send 1 wei of Snow to a victim to force their pending claim to revert, at a cost of 1 wei of a freely earnable token.

Risk

Likelihood:

  • Any whitelisted user who earns or buys Snow between the snapshot and their claim is desynced — this is the protocol's own encouraged usage.

  • Any third party can desync any victim at will by transferring them 1 wei of Snow (mempool-front-running a pending claim works too).

Impact:

  • Claim (the airdrop's core function) reverts for every desynced user until each user individually performs a manual token transfer to restore the exact snapshot balance — non-obvious and undocumented.

  • Dust-cost griefing: an attacker can repeatedly block victims' claims for 1 wei per disruption.

Proof of Concept

function test_PoC_LiveBalanceDesync() public {
vm.warp(block.timestamp + 1 weeks);
​
// (a) dan follows the intended flow but earns once more after the snapshot
vm.prank(dan);
snow.earnSnow(); // balance now 2, leaf in tree is (dan, 1)
vm.prank(dan);
snow.approve(address(airdrop), 2);
bytes32 danDigest = airdrop.getMessageHash(dan);
(uint8 dV, bytes32 dR, bytes32 dS) = vm.sign(danKey, danDigest);
vm.expectRevert(SnowmanAirdrop.SA__InvalidProof.selector);
airdrop.claimSnowman(dan, DAN_PROOF, dV, dR, dS); // cannot claim his own airdrop
​
// manual rescue: transfer the excess away, then the original leaf matches again
vm.prank(dan);
snow.transfer(bob, 1);
bytes32 danDigest2 = airdrop.getMessageHash(dan);
(uint8 dV2, bytes32 dR2, bytes32 dS2) = vm.sign(danKey, danDigest2);
airdrop.claimSnowman(dan, DAN_PROOF, dV2, dR2, dS2);
assertEq(nft.balanceOf(dan), 1);
​
// (b) dust griefing: anyone can desync a victim by transferring them 1 wei
vm.prank(eli);
snow.transfer(clara, 1); // clara 1 -> 2
vm.prank(clara);
snow.approve(address(airdrop), 2);
bytes32 clDigest = airdrop.getMessageHash(clara);
(uint8 cV, bytes32 cR, bytes32 cS) = vm.sign(clKey, clDigest);
vm.expectRevert(SnowmanAirdrop.SA__InvalidProof.selector);
airdrop.claimSnowman(clara, CL_PROOF, cV, cR, cS);
}

Run: add the test to test/TestSnowmanAirdrop.t.sol (setup provides dan/clara/eli, their keys, and DAN_PROOF/CL_PROOF), then forge test --match-test test_PoC_LiveBalanceDesync -vv

Output (actual run):

[PASS] test_PoC_LiveBalanceDesync() (gas: 429202)
Logs:
FC-0007a: earning after snapshot broke the claim until manual token surgery
FC-0007b: 1 wei of dust from a third party blocked clara's claim

Recommended Mitigation

Commit the amount in the leaf and accept it as a parameter instead of sampling the live balance (this also enables partial claims).

- function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
+ function claimSnowman(address receiver, uint256 amount, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external nonReentrant
{
// ...
- uint256 amount = i_snow.balanceOf(receiver);
+ if (i_snow.balanceOf(receiver) < amount) { revert SA__InsufficientBalance(); }
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));

(Apply the same amount parameter inside getMessageHash so the signed struct matches the committed allocation.)

Updates

Lead Judging Commences

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

[M-01] DoS to a user trying to claim a Snowman

# Root + Impact ## Description * Users will approve a specific amount of Snow to the SnowmanAirdrop and also sign a message with their address and that same amount, in order to be able to claim the NFT * Because the current amount of Snow owned by the user is used in the verification, an attacker could forcefully send Snow to the receiver in a front-running attack, to prevent the receiver from claiming the NFT.&#x20; ```Solidity function getMessageHash(address receiver) public view returns (bytes32) { ... // @audit HIGH An attacker could send 1 wei of Snow token to the receiver and invalidate the signature, causing the receiver to never be able to claim their Snowman uint256 amount = i_snow.balanceOf(receiver); return _hashTypedDataV4( keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount}))) ); ``` ## Risk **Likelihood**: * The attacker must purchase Snow and forcefully send it to the receiver in a front-running attack, so the likelihood is Medium **Impact**: * The impact is High as it could lock out the receiver from claiming forever ## Proof of Concept The attack consists on Bob sending an extra Snow token to Alice before Satoshi claims the NFT on behalf of Alice. To showcase the risk, the extra Snow is earned for free by Bob. ```Solidity function testDoSClaimSnowman() public { assert(snow.balanceOf(alice) == 1); // Get alice's digest while the amount is still 1 bytes32 alDigest = airdrop.getMessageHash(alice); // alice signs a message (uint8 alV, bytes32 alR, bytes32 alS) = vm.sign(alKey, alDigest); vm.startPrank(bob); vm.warp(block.timestamp + 1 weeks); snow.earnSnow(); assert(snow.balanceOf(bob) == 2); snow.transfer(alice, 1); // Alice claim test assert(snow.balanceOf(alice) == 2); vm.startPrank(alice); snow.approve(address(airdrop), 1); // satoshi calls claims on behalf of alice using her signed message vm.startPrank(satoshi); vm.expectRevert(); airdrop.claimSnowman(alice, AL_PROOF, alV, alR, alS); } ``` ## Recommended Mitigation Include the amount to be claimed in both `getMessageHash` and `claimSnowman` instead of reading it from the Snow contract. Showing only the new code in the section below ```Python function claimSnowman(address receiver, uint256 amount, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s) external nonReentrant { ... bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount)))); if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) { revert SA__InvalidProof(); } // @audit LOW Seems like using the ERC20 permit here would allow for both the delegation of the claim and the transfer of the Snow tokens in one transaction i_snow.safeTransferFrom(receiver, address(this), amount); // send ... } ```

Support

FAQs

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

Give us feedback!