The intended behavior appears to be:
Each user can earn Snow once every week.
But the implementation actually provides:
The entire protocol can earn Snow only once every week, and any user can reset the timer.
The s_earnTimer variable is implemented as a single global timer, even though the farming cooldown should apply independently to each user.
When one user calls earnSnow(), the contract updates the global timer:
This causes the 7-day cooldown to affect other users as well. Consequently, when one user claims their Snow farming reward, another user who has never claimed a reward may be unable to call earnSnow() for up to one week.
An attacker can exploit this behavior by repeatedly triggering the timer, thereby preventing other users from accessing their intended weekly Snow farming rewards.
The timer should instead be tracked separately for each user so that one user's farming activity cannot affect another user's cooldown.
Likelihood:
High
The vulnerability can be triggered by any unprivileged user through the publicly accessible earnSnow() function. No administrative privileges, special permissions, or unusual conditions are required.
When a user calls earnSnow(), the contract updates the single global s_earnTimer variable. This timestamp is subsequently used to determine whether all users are allowed to call earnSnow(). Consequently, a user's farming action can place every other user under the same seven-day cooldown.
For example, if User A successfully calls earnSnow(), s_earnTimer is set to the current timestamp. If User B attempts to call earnSnow() one day later, User B's transaction will revert with S__Timer(), despite User B having never previously called earnSnow().
Because the function is permissionless, any user can trigger this behavior. The attacker can also repeatedly interact with the farming mechanism to reset the global timer, allowing them to continuously interfere with other users' ability to claim their farming rewards.
The attack requires minimal effort and no special privileges, making the vulnerability highly reproducible and likely to occur in practice.
Denial of Service: A user's ability to claim their weekly Snow farming reward can be blocked by another user's claim.
Reward disruption: Users may repeatedly miss their intended farming opportunities because the cooldown is shared globally rather than tracked independently.
Griefing: An attacker can repeatedly claim their own reward to reset the global timer and continuously interfere with other users' ability to farm Snow.
Protocol-wide effect: Because s_earnTimer is a single contract-wide variable, the issue affects all users rather than only the account that triggered the timer.
## Description: The `Snow::buySnow` function contains a critical flaw where it resets a global timer `(s_earnTimer)` to the current block timestamp on every invocation. This timer controls eligibility for free token claims via `Snow::earnSnow()`, which requires 1 week to pass since the last timer reset. As a result: Any token purchase `(via buySnow)` blocks all free claims for all users for 7 days Malicious actors can permanently suppress free claims with micro-transactions Contradicts protocol documentation promising **"free weekly claims per user"** ## Impact: * **Complete Denial-of-Service:** Free claim mechanism becomes unusable * **Broken Protocol Incentives:** Undermines core user acquisition strategy * **Economic Damage:** Eliminates promised free distribution channel * **Reputation Harm:** Users perceive protocol as dishonest ```solidity function buySnow(uint256 amount) external payable canFarmSnow { if (msg.value == (s_buyFee * amount)) { _mint(msg.sender, amount); } else { i_weth.safeTransferFrom(msg.sender, address(this), (s_buyFee * amount)); _mint(msg.sender, amount); } @> s_earnTimer = block.timestamp; emit SnowBought(msg.sender, amount); } ``` ## Risk **Likelihood**: • Triggered by normal protocol usage (any purchase) • Requires only one transaction every 7 days to maintain blockage • Incentivized attack (low-cost disruption) **Impact**: • Permanent suppression of core protocol feature • Loss of user trust and adoption • Violates documented tokenomics ## Proof of Concept **Attack Scenario:** Permanent Free Claim Suppression * Attacker calls **buySnow(1)** with minimum payment * **s\_earnTimer** sets to current timestamp (T0) * All **earnSnow()** calls revert for **next 7 days** * On day 6, attacker repeats **buySnow(1)** * New timer reset (T1 = T0+6 days) * Free claims blocked until **T1+7 days (total 13 days)** * Repeat step **4 every 6 days → permanent blockage** **Test Case:** ```solidity // Day 0: Deploy contract snow = new Snow(...); // s_earnTimer = 0 // UserA claims successfully snow.earnSnow(); // Success (first claim always allowed) // Day 1: UserB buys 1 token snow.buySnow(1); // Resets global timer to day 1 // Day 2: UserA attempts claim snow.earnSnow(); // Reverts! Requires day 1+7 = day 8 // Day 7: UserC buys 1 token (day 7 < day 1+7) snow.buySnow(1); // Resets timer to day 7 // Day 8: UserA retries snow.earnSnow(); // Still reverts! Now requires day 7+7 = day 14 ``` ## Recommended Mitigation **Step 1:** Remove Global Timer Reset from `buySnow` ```diff function buySnow(uint256 amount) external payable canFarmSnow { // ... existing payment logic ... - s_earnTimer = block.timestamp; emit SnowBought(msg.sender, amount); } ``` **Step 2:** Implement Per-User Timer in `earnSnow` ```solidity // Add new state variable mapping(address => uint256) private s_lastClaimTime; function earnSnow() external canFarmSnow { // Check per-user timer instead of global if (s_lastClaimTime[msg.sender] != 0 && block.timestamp < s_lastClaimTime[msg.sender] + 1 weeks ) { revert S__Timer(); } _mint(msg.sender, 1); s_lastClaimTime[msg.sender] = block.timestamp; // Update user-specific timer emit SnowEarned(msg.sender, 1); // Add missing event } ``` **Step 3:** Initialize First Claim (Constructor) ```solidity constructor(...) { // Initialize with current timestamp to prevent immediate claims s_lastClaimTime[address(0)] = block.timestamp; } ```
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.