When a contest is created, the per-player rewards should correspond one-to-one with players, and their sum should equal totalRewards (the amount the pot is funded with), so that every player can be paid exactly what they are owed.
ContestManager.createContest forwards its arrays straight into new Pot(...), and the Pot constructor sets state with no invariant checks. A configuration where sum(rewards) > totalRewards is accepted silently: the pot is funded with only totalRewards, so once cumulative claims exceed it, remainingRewards -= reward underflows (Solidity 0.8 Panic 0x11) and/or the token transfer reverts on insufficient balance, permanently bricking later claimants.
Likelihood:
When the owner creates a contest whose per-player rewards do not sum to totalRewards (or whose array lengths differ) — an unvalidated, easily-made setup mistake, since the contract enforces no relationship between the two.
When the mismatched pot is sum(rewards) > totalRewards, later claimants encounter the underflow/insolvency on claim.
Impact:
A single mis-parameterized createContest call permanently prevents affected players from claiming their promised rewards, or strands funds (sum(rewards) < totalRewards), with no on-chain warning until a claim reverts.
There is no recovery path — the affected player's reward is unrecoverable.
Validate the invariants in the Pot constructor, computing the sum in the existing loop:
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.