Root + Impact

Description

The Snow contract uses block.timestamp to control access to critical time-based functionality, including when users are permitted to mint tokens via buySnow() and earnSnow() functions. Specifically, the canFarmSnow modifier relies on comparing the current block timestamp to the immutable i_farmingOver value. Additionally, the earnSnow function enforces a one-week cooldown based on s_earnTimer and block.timestamp.

Using block.timestamp for time-sensitive logic introduces a level of miner influence. While block timestamps are generally reliable, they can be manipulated within a range of approximately ±15 seconds by the miner of the block. In scenarios where time precision is critical or when small windows of opportunities exist, such manipulation can allow miners or privileged participants to gain an unfair advantage.

This pattern aligns with OWASP's SC03: Timestamp Dependence vulnerability category.

Risk

Likelihood: Medium
Impact: Medium

While the farming window and cooldown in this contract span several days - making timestamp manipulation less practically exploitable in this context - the use of block.timestamp still introduces a non-zero trust assumption on miners. Future extensions or protocol changes relying on more fine-grained timing could render this vulnerability exploitable.

Additionally, reliance on block.timestamp may reduce composability with other contracts or protocols expecting deterministic, manipulation-resistance logic.

Proof of Concept

Usage in farming duration check:

Usage in weekly cooldown logic:

In both cases, block timestamp manipulation could premature access or prolong access beyond intended constraints under certain missing conditions.

Recommended Mitigation:

While block.timestamp is acceptable for coarse-grained time controls, consider the following practices:

• If tighter precision is required in future versions, use a trusted source of time or enforce additional bounds.

• Avoid making critical state changes solely dependent on block timestamps if the range of manipulation can be exploited.

• Document the intended time sensitivity and miner influence tolerance to guide future audits and development.

In this case, no immediate code change is strictly required, but developers should be aware of the inherent trust model and avoid relying on block.timestamp for precision-critical mechanisms.