Raisebox Faucet
First Flight #50
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Severity: medium
Valid

Daily Claim Counter Reset Uses Incorrect Logic

aramis

Scope:

  • RaiseBoxFaucet.sol (Lines 220-223)

  • Function: claimFaucetTokens()

Description:

Root cause + Impact: The daily claim counter reset mechanism uses timestamp comparison instead of day-based comparison and sets lastFaucetDripDay to the current timestamp rather than tracking day numbers. The condition block.timestamp > lastFaucetDripDay + 1 days creates unpredictable reset intervals. On first deployment, lastFaucetDripDay is 0, so the reset condition becomes "block.timestamp > 86400 seconds". After the first reset, lastFaucetDripDay becomes the current timestamp (e.g., 259200 at day 3), making subsequent resets require "block.timestamp > 345600" (day 4 total). This creates inconsistent day boundaries where users claiming at day 3.5 cannot claim because the limit was reached, even though a new calendar day hasn't technically started.

Risk:

Likelihood: This occurs predictably after the first reset and affects all subsequent claims. Users attempting to claim near day boundaries will encounter unexpected failures.

Impact: Users are unfairly blocked from claiming even when the day has changed from their perspective. This creates confusion, poor user experience, and potential loss of trust in the faucet. Some users get preferential treatment by claiming immediately after resets while others face arbitrary lockouts.

Proof of Concept

// Current buggy implementation
if (block.timestamp > lastFaucetDripDay + 1 days) {
lastFaucetDripDay = block.timestamp; // BUG: Should track day number
dailyClaimCount = 0;
}
​
// Timeline example:
// Deployment at timestamp 0: lastFaucetDripDay = 0
// Day 3 (259200s): User claims, 259200 > 86400 ✓, reset occurs
// lastFaucetDripDay = 259200
// Day 3.5 (302400s): 302400 > 345600? ✗ (still day 3 in contract's view)
// User blocked even though 12 hours passed!
// Day 4 (345600s): Finally resets, but should have reset at day 3→4 boundary

Recommended Mitigation

-if (block.timestamp > lastFaucetDripDay + 1 days) {
- lastFaucetDripDay = block.timestamp;
- remove this code
+ add this code
+uint256 currentClaimDay = block.timestamp / 1 days;
+if (currentClaimDay > lastFaucetDripDay) {
+ lastFaucetDripDay = currentClaimDay;
Updates

Lead Judging Commences

inallhonesty Lead Judge 14 days ago
Submission Judgement Published
Validated
Assigned finding tags:

Inconsistent day calculation methods cause desynchronization between ETH and token daily resets.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.