Root + Impact

Description

• Normal behavior: A contract may want to track the current block timestamp for timing or cooldown logic. Typically, block.timestamp should be accessed dynamically whenever needed.

• Issue: The contract stores a snapshot of the deployment timestamp in blockTime and never updates it. Any logic referencing blockTime would use an outdated value, which could lead to inconsistencies if future code mistakenly relies on it.

Risk

Likelihood:

• Developers may mistakenly use blockTime in future functions instead of block.timestamp, assuming it reflects the current block time.

• Any new feature referencing blockTime would use the frozen deployment timestamp.

Impact:

• Incorrect timing or cooldown behavior if blockTime is used.

• Potential confusion during contract maintenance or audits, increasing the chance of misimplementing time-based features.

Proof of Concept

No relevant PoC to show

Recommended Mitigation

Remove the variable