The blockTime variable is set to block.timestamp at deployment (e.g., 08:25 AM +06 on October 14, 2025) and remains static thereafter. While block.timestamp is used in claimFaucetTokens for daily resets and cooldown checks, blockTime is not referenced in any function, event, or logic within the contract. This suggests it may have been a remnant of a planned feature (e.g., contract age validation) that was abandoned or replaced with direct block.timestamp usage.
The unused variable bloats the contract's bytecode, increasing deployment costs and complicating code reviews as auditors must verify its irrelevance. This is a common issue in iterative development where code cleanup is neglected.
Likelihood:
High: Unused variables are a frequent byproduct of evolving codebases where planned features are dropped without removal.
Easily overlooked in contracts with multiple state variables.
Impact:
Low: Negligible runtime effect, with a minor gas overhead (~2000 gas at deployment).
Maintenance burden: Clutter may obscure critical logic or lead to accidental misuse in future updates.
The following Foundry test confirms that blockTime is unused and remains static, with no impact on contract behavior.
Add to RaiseBoxFaucetTest.t.sol:
Setup: Deploys the contract, capturing the deployment timestamp (e.g., 08:25 AM +06, Oct 14, 2025).
Issue Demonstration: The test verifies blockTime holds the static deploy time and is not updated or referenced during a claim, confirming its unused status.
Result: The test passes, showing blockTime adds no value, with logs highlighting its static nature.
The assertion and logs prove the variable's redundancy, supporting the need for removal.
Remove the unused blockTime variable to reduce bytecode size and gas costs.
It's current unused state, removal is the simplest and most effective solution.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.