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

M-02 Dual Amount Validation in claimSnowman()

mnusurov

Root + Impact

Description

  • Normal behavior: The claimSnowman() function should validate claims using the merkle proof and ECDSA signature generated at the time of merkle snapshot, when user balances were fixed.

  • Issue: The function validates using the user's current Snow token balance at claim time, but the merkle proof and signature were generated based on the balance at snapshot time. Any balance change between snapshot and claim causes signature validation to fail.

// src/SnowmanAirdrop.sol:76-86
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external nonReentrant
{
if (i_snow.balanceOf(receiver) == 0) { // @> Checks CURRENT balance
revert SA__ZeroAmount();
}
@> if (!_isValidSignature(receiver, getMessageHash(receiver), v, r, s)) {
revert SA__InvalidSignature();
}
@> uint256 amount = i_snow.balanceOf(receiver); // Reads CURRENT balance
@> bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));
// Creates leaf with CURRENT balance, not snapshot balance!
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) {
revert SA__InvalidProof();
}
// ...
}
​
// src/SnowmanAirdrop.sol:112-122 - getMessageHash uses CURRENT balance
@> function getMessageHash(address receiver) public view returns (bytes32) {
if (i_snow.balanceOf(receiver) == 0) { // @> CURRENT balance
revert SA__ZeroAmount();
}
@> uint256 amount = i_snow.balanceOf(receiver); // CURRENT balance
return _hashTypedDataV4(
keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount})))
);
}

Risk

Likelihood:

  • User transfers tokens between snapshot and claim for legitimate reasons (paying gas, trading)

  • Balance changes from 100 to 99 make the signature invalid since it was created for balance=100

Impact:

  • Valid airdrop recipients cannot claim their rightful NFT rewards

  • The airdrop mechanism becomes non-deterministic - success depends on external balance changes

  • Users who followed the correct flow (receive merkle, sign, approve, claim) are blocked

Proof of Concept

This POC demonstrates that legitimate balance changes between snapshot and claim time cause signature validation to fail, preventing valid users from claiming their airdrop.

// From test/audit/M-02-logic-amount-validation.t.sol
function testClaimFailsAfterBalanceDecrease() public {
// Setup: Alice has 100 Snow at snapshot time
// Merkle proof and signature created for amount=100
uint256 snapshotBalance = 100e18;
assertEq(snow.balanceOf(alice), snapshotBalance);
// Alice transfers 1 token (legitimate reason)
vm.prank(alice);
snow.transfer(bob, 1e18);
assertEq(snow.balanceOf(alice), 99e18); // Balance changed!
// Alice tries to claim with proof/sig for 100
vm.prank(alice);
vm.expectRevert(SnowmanAirdrop.SA__InvalidSignature.selector);
snowmanAirdrop.claimSnowman(
alice,
merkleProof,
v, r, s
);
// Claim fails even though Alice is valid participant
}
​
function testValidUserBlockedByBalanceChange() public {
// Multiple users affected by same issue
// Bob claims successfully (balance unchanged)
vm.prank(bob);
snowmanAirdrop.claimSnowman(bob, bobProof, bobV, bobR, bobS);
// Charlie transferred tokens, now blocked
vm.prank(charlie);
snow.transfer(bob, 10e18);
vm.prank(charlie);
vm.expectRevert(SnowmanAirdrop.SA__InvalidSignature.selector);
snowmanAirdrop.claimSnowman(charlie, charlieProof, charlieV, charlieR, charlieS);
}

Recommended Mitigation

Adding a claimAmount parameter decouples the snapshot amount from the current balance, ensuring signature, merkle leaf, and validation all use the same fixed amount from snapshot time.

// src/SnowmanAirdrop.sol:69-99 - Add claimAmount parameter
- function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
+ function claimSnowman(
+ address receiver,
+ uint256 claimAmount,
+ 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();
+ if (claimAmount == 0) revert SA__ZeroAmount();
// Use claimed amount, not current balance
- if (!_isValidSignature(receiver, getMessageHash(receiver), v, r, s)) {
+ bytes32 messageHash = _computeMessageHash(receiver, claimAmount);
+ if (!_isValidSignature(receiver, messageHash, v, r, s)) {
revert SA__InvalidSignature();
}
- uint256 amount = i_snow.balanceOf(receiver);
- bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));
+ bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, claimAmount))));
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) {
revert SA__InvalidProof();
}
// Check user has enough balance
+ if (i_snow.balanceOf(receiver) < claimAmount) revert SA__InsufficientBalance();
+ i_snow.safeTransferFrom(receiver, address(this), claimAmount);
s_hasClaimedSnowman[receiver] = true;
emit SnowmanClaimedSuccessfully(receiver, claimAmount);
i_snowman.mintSnowman(receiver, claimAmount);
}
​
// Helper function using explicit amount
+ function _computeMessageHash(address receiver, uint256 amount) internal view returns (bytes32) {
+ return _hashTypedDataV4(
+ keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount})))
+ );
+ }
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 8 days 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!