The constructor loops over players without checking that both arrays have the same length. If rewards is longer, its extra entries are ignored. Meanwhile, remainingRewards is set to the separately supplied totalRewards, which can exceed the rewards assigned to players.
The constructor assigns rewards using this loop:
There is no check that players.length == rewards.length.
For example, the owner supplies two players, rewards [1, 2, 3], and totalRewards = 6. Only rewards 1 and 2 are assigned. The third reward is ignored, while remainingRewards is set to 6.
Checking that sum(rewards) == totalRewards would not catch this example: both values are 6.
If rewards is shorter than players, deployment reverts with an array out-of-bounds error. The silent omission occurs when rewards is longer.
Likelihood: Low
The trusted owner must accidentally supply arrays of different lengths. An ordinary player cannot create this configuration.
Impact: Low
Some of the funded tokens are not assigned to any player. The constructor does not report this, so the owner does not notice the mistake.
At closing, part of these tokens may be paid to the players who claimed, but the player the owner forgot to add still gets nothing.
The closing payments are also affected by the separate division issue (reported separately).
Add the following inside the existing TestMyCut contract in test/TestMyCut.t.sol. It uses the existing setup, imports and the mintAndApproveTokens modifier.
Run from the repository root:
Output:
Check the lengths when the Pot is created, so a wrong input fails immediately:
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.