Normally, dailyClaimCount should reset on a calendar-aligned day boundary (or a consistent 24-hour window) so that daily limits are enforced consistently.
The issue is that lastFaucetDripDay is assigned the raw block.timestamp when the reset runs, causing the “daily” period to start at the exact timestamp of the first reset rather than a day-aligned boundary.
Likelihood:
When the reset condition (more than 24 hours since lastFaucetDrip) is met, the code assigns lastFaucetDripDay to the current block.timestamp.
When the first claim that triggers the reset occurs at an arbitrary time during a calendar day, subsequent 24-hour windows align to that arbitrary time rather than calendar days.
Impact:
The faucet’s daily claim enforcement may be inconsistent across calendar days.
Users may be able to claim more than the intended per-calendar-day limit depending on when the first reset occurs.
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.