createContest does not validate that sum of individual rewards equals totalRewards
In ContestManager.sol, the createContest function (lines 16-26) accepts a totalRewards parameter and a rewards array, but never validates that the sum of all values in rewards equals totalRewards.
function createContest(address[] memory players, uint256[] memory rewards, IERC20 token, uint256 totalRewards)
public
onlyOwner
returns (address)
{
Pot pot = new Pot(players, rewards, token, totalRewards);
// No validation: sum(rewards) == totalRewards
}
When fundContest is called, it transfers totalRewards amount of tokens to the Pot. But the Pot allows each player to claim their individual reward from the rewards array.
Risk
If totalRewards is less than the sum of individual rewards, the Pot will be underfunded. Early claimants will successfully claim their rewards, but later claimants will have their transactions revert because the Pot doesn't hold enough tokens.
Example:
rewards = [100, 100, 100] → sum = 300
totalRewards = 200 (set incorrectly)
Pot is funded with 200 tokens
Player 1 claims 100 → success (100 remaining)
Player 2 claims 100 → success (0 remaining)
Player 3 claims 100 → REVERTS (insufficient balance)
This creates an unfair first-come-first-served situation where the last players to claim lose their rewards entirely.
If totalRewards exceeds the sum of rewards, excess tokens are stuck in the contract.
Proof of Concept
function testUnderfundedPot() public {
address[] memory players = new address;
uint256[] memory rewards = new uint256;
players[0] = alice; rewards[0] = 100;
players[1] = bob; rewards[1] = 100;
players[2] = charlie; rewards[2] = 100;
}
Mitigation
Add validation in createContest:
uint256 rewardSum = 0;
for (uint256 i = 0; i < rewards.length; i++) {
rewardSum += rewards[i];
}
require(rewardSum == totalRewards, "Rewards sum mismatch");
require(players.length == rewards.length, "Array length mismatch");
Lead Judging Commences
[L-01] The logic for ContestManager::createContest is NOT efficient
## Description there are two major problems that comes with the way contests are created using the `ContestManager::createContest`. - using dynamic arrays for `players` and `rewards` leads to potential DoS for the `Pot::constructor`, this is possible if the arrays are too large therefore requiring too much gas - it is not safe to trust that `totalRewards` value supplied by the `manager` is accurate and that could lead to some players not being able to `claimCut` ## Vulnerability Details - If the array of `players` is very large, the `Pot::constructor` will revert because of too much `gas` required to run the for loop in the constructor. ```Solidity constructor(address[] memory players, uint256[] memory rewards, IERC20 token, uint256 totalRewards) { i_players = players; i_rewards = rewards; i_token = token; i_totalRewards = totalRewards; remainingRewards = totalRewards; i_deployedAt = block.timestamp; // i_token.transfer(address(this), i_totalRewards); @> for (uint256 i = 0; i < i_players.length; i++) { @> playersToRewards[i_players[i]] = i_rewards[i]; @> } } ``` - Another issue is that, if a `Pot` is created with a wrong `totalRewards` that for instance is less than the sum of the reward in the `rewards` array, then some players may never get to `claim` their rewards because the `Pot` will be underfunded by the `ContestManager::fundContest` function. ## PoC Here is a test for wrong `totalRewards` ```solidity function testSomePlayersCannotClaimCut() public mintAndApproveTokens { vm.startPrank(user); // manager creates pot with a wrong(smaller) totalRewards value- contest = ContestManager(conMan).createContest(players, rewards, IERC20(ERC20Mock(weth)), 6); ContestManager(conMan).fundContest(0); vm.stopPrank(); vm.startPrank(player1); Pot(contest).claimCut(); vm.stopPrank(); vm.startPrank(player2); // player 2 cannot claim cut because the pot is underfunded due to the wrong totalScore vm.expectRevert(); Pot(contest).claimCut(); vm.stopPrank(); } ``` ## Impact - Pot not created if large dynamic array of players and rewards is used - wrong totlRewards value leads to players inability to claim their cut ## Recommendations review the pot-creation design by, either using merkle tree to store the players and their rewards OR another solution is to use mapping to clearly map players to their reward and a special function to calculate the `totalRewards` each time a player is mapped to her reward. this `totalRewards` will be used later when claiming of rewards starts.
Rewards breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Judging
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsRewards Distribution
The contest is complete and the rewards are being distributed.