The Pot constructor zips players and rewards by iterating up to i_players.length. When rewards.length > players.length, the surplus entries are silently dropped with no event and no revert. When rewards.length < players.length, the loop reverts with a generic out-of-bounds read — but only at the moment of deployment, providing no clear failure signal.
The result is that a misconfigured input (off-by-one in a deployment script, an extra trailing entry, etc.) creates a Pot whose effective rewards differ from what the admin intended, with no on-chain trace of the discrepancy.
Likelihood:
Requires an admin (Trusted) misconfiguration. Realistic scenarios: a CSV with an extra row, a script that builds two arrays from different sources, or copy-paste artifacts.
The misconfiguration is silent at deploy time — there is no event, no return value, no warning — so it propagates to production unless the admin manually inspects each playersToRewards mapping after deployment.
Impact:
The effective rewards configuration differs from the intended one. With rewards = [1000, 1000, 9999, 9999] and players = [alice, bob], the 9999 entries are simply dropped.
Combined with finding #4 (no sum(rewards) <= totalRewards check), the silent discard also opens the door to a Pot that appears over-funded but is in fact under-allocated, or vice versa, with no on-chain way to tell.
Run with forge test --match-test test_excessRewardsArrayElementsIgnored -vvv. Test passes.
Require strict length equality in the constructor (and ideally also in ContestManager.createContest).
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.