buySnow(0) with msg.value = 0 is free and unconditionally resets the global s_earnTimer, blocking earnSnow for all addresses during the farming window

Impact: Medium (proposed only — no final severity assigned; see Risk)
Likelihood: High (permissionless, no role and no payment required; see Risk)
Scope: src/Snow.sol, src/SnowmanAirdrop.sol (the latter only as the cross-contract effect of the same defect, src/SnowmanAirdrop.sol:76-78)

Commit: 6efcb0f816ea6ffc5fcb1a66ea5af66d0022e80e. Evidence state recorded by the Finding: reproduced; PoC test/w3aas/F-0001.t.sol::test_F_0001 recorded as passing with exit code 0.

Description

Snow.buySnow accepts amount == 0 together with msg.value == 0. The payment equality check passes because s_buyFee * 0 == 0, so the call takes the _mint(msg.sender, 0) branch and needs no ETH, no WETH, no allowance and no privileged role. Independent of amount and of which payment branch is taken, buySnow then writes the protocol-wide cooldown s_earnTimer unconditionally. Because earnSnow reads that single global value as its cooldown, any address can push the cooldown forward for every other address, repeatedly, for the entire 12-week farming window, at the cost of gas only.

Two code properties combine:

1. No positive-amount / positive-value guard in buySnow. src/Snow.sol:79-90 has no amount > 0 or msg.value > 0 check. The constructor does validate the fee (if (_buyFee == 0) revert S__ZeroValue();, src/Snow.sol:65-67, applied at src/Snow.sol:73), but buySnow has no equivalent guard, so amount = 0 is a valid, free state-changing call. With s_buyFee >= 1e18 (src/Snow.sol:73), amount = 0 is the only value for which s_buyFee * amount == msg.value == 0 holds without payment.

2. The cooldown timer is a single global variable and is written outside the amount/payment branches. s_earnTimer is one private uint256 (src/Snow.sol:30). s_earnTimer = block.timestamp sits at function-body level after the if/else (src/Snow.sol:87), so it executes for amount = 0, for the no-payment path, and for any caller. earnSnow then gates on s_earnTimer != 0 && block.timestamp < s_earnTimer + 1 weeks (src/Snow.sol:93-95).

Reachability premise verified in this session: a zero-value _mint does not revert in the vendored OpenZeppelin copy, so src/Snow.sol:87 is reachable. lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol:214-219 only rejects account == address(0) (ERC20InvalidReceiver), and _update at lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol:176-204 has no zero-value revert. (The Finding's counterevidence entry recorded this dependency as unverified because the submodule appeared unexpanded; the file was readable here and confirms the premise.)

Risk

Likelihood: Low barrier, no special role or state required. Any address can call buySnow(0) with msg.value = 0 (src/Snow.sol:79-80) and the call needs no ETH balance, no WETH, no allowance, no signature and no allowlist. The only conditions are canFarmSnow (src/Snow.sol:53-58, i.e. the call happens before i_farmingOver = deployTime + 12 weeks, src/Snow.sol:75) and gas. The griefing is repeatable by construction: spacing attacker calls just under 1 week keeps s_earnTimer + 1 weeks permanently in the future, and the PoC's loop (test/w3aas/F-0001.t.sol:113-132) does exactly that with 6-day spacing over the whole window.

Impact: As evidenced by the recorded PoC, and stated no more broadly than that:

• earnSnow becomes unavailable to everyone while the attacker keeps re-arming. Any successful buySnow — including the zero-cost buySnow(0) — rewrites the single global s_earnTimer (src/Snow.sol:87), and earnSnow reverts with S__Timer for every caller, including the attacker, because there is no msg.sender exemption at src/Snow.sol:93. Result within the window: a griefer can hold all addresses out of the weekly earnSnow mint.

• Addresses that end the window with balanceOf == 0 cannot claim at all. SnowmanAirdrop.claimSnowman reverts with SA__ZeroAmount when i_snow.balanceOf(receiver) == 0 (src/SnowmanAirdrop.sol:76-78), so an address that never obtained Snow during the window cannot claim a Snowman. This is the specific impact the PoC demonstrates (case E).

• Cost asymmetry. The attacker spends gas only and gains nothing, and is blocked from earnSnow by the same global timer; the harm is denial of a free weekly mint to third parties, not theft or direct loss of held assets.

• Hard time bound, self-limiting. i_farmingOver = block.timestamp + 12 weeks at deployment (src/Snow.sol:75) and canFarmSnow (src/Snow.sol:53-58) disables both buySnow and earnSnow afterwards, so the griefing cannot extend past the window (asserted in the PoC at test/w3aas/F-0001.t.sol:136-146).

Explicitly not claimed: that a user who already holds Snow is prevented from claiming. claimSnowman recomputes the leaf amount from the current balance (src/SnowmanAirdrop.sol:84-90) and the off-chain tree amounts are built from the one-per-week earnSnow quantity (script/GenerateInput.s.sol:52-56, script/Helper.s.sol:35-61), so the relationship between extra earnSnow mints and claimability is not a straight-line loss and is not used as a claim here.

Open points that keep the severity provisional: the platform's known-issues and trusted-roles fields were not provided (已知问题：未填写, 可信角色：未填写), so it cannot be excluded that the global-cooldown behaviour is an accepted design choice; the scope of the root cause is a judgement call, since src/Snow.sol:87 writes the global timer for every buySnow (including a legitimate self-funded purchase) and the delta specific to the zero-cost path is the missing amount > 0 / msg.value > 0 validation. If the protocol-global single cooldown is judged intended, the reportable defect narrows to that missing check.

Proof of Concept

The single test test_F_0001 is structured so that a harness error is distinguishable from a wrong hypothesis. Key excerpts from test/w3aas/F-0001.t.sol:

Test path: test/w3aas/F-0001.t.sol. Command: forge test --match-path test/w3aas/F-0001.t.sol --match-test test_F_0001 -vvv. Recorded result: 1 passed; 0 failed (exit code 0; an earlier run in logs/F-0001-1.log failed and was superseded). Note on evidence handling: in the revision session the log files were not readable (read_file on logs/F-0001-2.log returned "file not found", and a search for F-0001 under logs/ returned no match), so the pass/exit-code status is carried over from the prior run record rather than re-verified; the test source itself was re-read and its assertions match the conclusions below.

What each assertion establishes:

• (A) Control on the same timeline without an attacker: the first earnSnow mints 1, and after +1 weeks a second earnSnow succeeds and the balance reaches 2 — the cooldown mechanism itself works, so any failure in the main case is not a broken harness.

• (B) With s_earnTimer == 0 the first earnSnow succeeds because src/Snow.sol:93 short-circuits; this fixes the starting state the attacker exploits.

• (C) Main case: the attacker holds 0 ETH and 0 WETH and snow.buySnow(0) succeeds. Post-conditions: attacker ETH unchanged, WETH unchanged, Snow balance 0, totalSupply unchanged, victim balance unchanged — nothing was paid and nothing was minted — yet the very next earnSnow from both victim and attacker reverts S__Timer, one full week after the victim's own successful earnSnow. This isolates the write at src/Snow.sol:87 as the only state change (the global timer), and shows the effect is protocol-wide rather than caller-scoped.

• (D) Sustained blocking: the attacker re-arms every 6 days while block.timestamp + 6 days < farmingOver; the loop asserts each re-arm costs 0 ETH, the recorded console output reports 12 free re-arms (assertGt(resets, 10) guards it), the victim never reaches a second Snow, and a fresh address (latecomer) is blocked on every iteration. After farmingOver, buySnow(0) and earnSnow both revert S__SnowFarmingOver, confirming the window bound.

• (E) Claim precondition: (E1) a control address holding 1 Snow with a matching leaf (keccak256(bytes.concat(keccak256(abi.encode(receiver, amount)))), same construction as src/SnowmanAirdrop.sol:86) signs, approves and claims successfully (claim status true, one Snowman minted); (E2) the blocked latecomer, whose balance is 0 after the window, calls claimSnowman and reverts with SA__ZeroAmount at src/SnowmanAirdrop.sol:76-78. (E2) deliberately uses a placeholder signature (27, 0, 0) because the balance check precedes the signature check, which pins the revert to the zero-balance guard.

Existing coverage gap: test/TestSnow.t.sol:36-52 (testCanEarnSnow) exercises only a single-actor cooldown path and does not cover third-party interference; no repo test asserted that buySnow(0) with msg.value == 0 reverts.

Recommended Mitigation

Why this removes the root cause: the amount == 0 guard closes the free path, because with amount = 0 the equality at src/Snow.sol:80 is trivially satisfied and no value moves; rejecting zero amounts means every surviving buySnow call mints a positive amount and either sends ETH or pulls s_buyFee * amount WETH. Removing the s_earnTimer write from buySnow then decouples purchasing from the earn cooldown entirely, so even a paid purchase can no longer extend another address's earnSnow availability — which is the second half of the defect as described. Both edits are needed for the zero-cost griefing to disappear; the guard alone would still leave the paid-purchase variant (noted in Risk) in place.

Side effects to consider before adopting: (a) the guard changes the externally visible behaviour of buySnow(0) from success to revert with S__ZeroValue — any off-chain script or test that probes with a zero amount will now revert, and test/TestSnow.t.sol should be re-run; (b) dropping the timer write means a purchase no longer resets anything, which is the intent, but if the design expects buying to also reset the farming cooldown, that coupling must be re-expressed explicitly on the earnSnow side rather than silently inherited from a shared variable; (c) S__ZeroValue is already declared (src/Snow.sol:24) and already used by the constructor (:66), so no new error type is introduced.

Alternative worth evaluating alongside: make the earnSnow cooldown per-address (e.g. mapping(address => uint256) private s_earnTimerFor; keyed by msg.sender) instead of one global uint256, so that no address's action can extend another address's cooldown; if a protocol-global cooldown is intended, document it explicitly and treat the missing amount guard as the defect boundary. Whichever option is chosen, add regression tests asserting that buySnow(0) with msg.value == 0 reverts and that a third-party buySnow does not extend another address's earnSnow availability.

Residual unknowns for triage (recorded, not resolved): the deployed Merkle tree contents (script/flakes/input.json, script/flakes/output.json) were not read, so the per-address amount distribution is unknown and no claim loss is quantified beyond the zero-balance case; the fee magnitude was not numerically validated — script/DeploySnow.s.sol:13 (FEE = 5) with s_buyFee = _buyFee * PRECISION (src/Snow.sol:73) implies 5e18 wei of buy fee per whole Snow unit, and the PoC reuses FEE = 5 without validating pricing semantics, so whether the pricing is itself a separate finding remains open to avoid duplicate accounting.