The Pot constructor accepts rewards and totalRewards independently and never checks that the sum of rewards is less than or equal to totalRewards. ContestManager.createContest likewise forwards the values without validation.
claimCut subtracts each claim from remainingRewards (initialized to totalRewards). When the cumulative claimed amount exceeds totalRewards, the next remainingRewards -= reward underflows and reverts under Solidity 0.8 arithmetic checks, permanently locking out the last claimant despite their valid configured reward.
Likelihood:
Requires the admin (Trusted) to misconfigure the Pot at creation time, supplying rewards whose sum exceeds totalRewards. The protocol provides no on-chain guard against this fat-finger.
A typo, a stale spreadsheet, or copy-paste error in the deployment script triggers it.
Impact:
Whichever player's claim is the one to push cumulative claims past totalRewards is DoS'd — their valid claim reverts.
This breaks the protocol's core guarantee ("authorized claimants have 90 days to claim"). The user cannot recover even by retrying after the window closes.
Funding inconsistency: fundContest only deposits totalRewards, so even without the underflow, the Pot would not have enough tokens to pay everyone. The bug surfaces as a revert rather than a graceful refusal.
Run with forge test --match-test test_sumRewardsExceedsTotalRewardsBreaksLastClaimer -vvv. Test passes (revert confirmed).
Validate the invariant in the constructor and reject misconfigured Pots up front.
Optionally, add the same check (or a higher-level wrapper) in ContestManager.createContest so the failure happens at the entry point rather than deep in the deployed Pot.
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.