MyCut

AI First Flight #8
Beginner FriendlyFoundry
EXP
View results
Submission Details
Severity: high
Valid

closePot divides the claimant payout by i_players.length instead of claimants.length, permanently locking most of the leftover rewards

Description

Pot distributes a contest's ERC20 rewards. During the 90-day window each allocated player calls claimCut() to take their reward; the call zeroes their allocation, decrements remainingRewards, and appends them to the claimants array. After 90 days the owner calls closePot(), which takes a 10% manager cut of whatever is left and — per the protocol's own description — "the remainder is distributed equally to those who claimed in time".

closePot computes each claimant's share with the wrong denominator:

uint256 managerCut = remainingRewards / managerCutPercent;
i_token.transfer(msg.sender, managerCut);
uint256 claimantCut = (remainingRewards - managerCut) / i_players.length; // divides by ALL players
for (uint256 i = 0; i < claimants.length; i++) { // but pays only the claimants
_transferReward(claimants[i], claimantCut);
}

The leftover pool is divided by i_players.length — every address that was ever allocated a reward — but it is only paid out to claimants, the subset who actually claimed in time. Since claimants.length <= i_players.length, each in-time claimant receives only a fraction of their fair share, and the un-paid difference is never transferred to anyone. There is no other function in Pot (or ContestManager) that can move those tokens, so they are permanently locked.

The specification ("distributed equally to those who claimed in time") requires dividing by claimants.length, not i_players.length.

Concretely, with 10 players allocated 100 tokens each (1000 total) and only 2 claiming in time, remainingRewards at close is 800. managerCut = 800/10 = 80. The intended per-claimant share is (800-80)/2 = 360, emptying the pot. The actual share is (800-80)/10 = 72, so 2 * 72 = 144 is paid out and 576 tokens (80% of the claimant pool) stay stuck in the contract forever.

Risk

Impact: High. Permanent, unrecoverable loss of funds. On every pot where not everyone claims in time — the exact scenario closePot exists to handle — the majority of the leftover rewards are locked in the contract with no admin or user path to release them.

Likelihood: High. It triggers under normal, intended operation: any close where the number of in-time claimants is fewer than the total allocated players (the common case, and the only case in which closePot's redistribution is meant to do anything).

Proof of Concept

function test_closePotLocksMostOfTheLeftover() public {
// 10 players, 100 tokens each => 1000 total; fund the pot.
address[] memory players = _players(10);
uint256[] memory rewards = _rewards(10, 100e18);
address potAddr = manager.createContest(players, rewards, IERC20(token), 1000e18);
Pot pot = Pot(potAddr);
token.mint(owner, 1000e18);
vm.prank(owner); token.approve(address(manager), 1000e18);
vm.prank(owner); manager.fundContest(0);
// Only 2 of the 10 claim in time (each takes their 100).
vm.prank(players[0]); pot.claimCut();
vm.prank(players[1]); pot.claimCut();
// remainingRewards == 800 (the 8 unclaimed allocations).
// 90 days pass; owner closes.
vm.warp(block.timestamp + 90 days + 1);
vm.prank(owner); manager.closeContest(potAddr);
// managerCut = 800/10 = 80 -> owner.
// EXPECTED (spec): each in-time claimant gets (800-80)/2 = 360; pot ends ~0.
// ACTUAL: claimantCut = (800-80)/10 = 72; each gets 72; only 144 leaves the pot.
assertEq(token.balanceOf(players[0]), 100e18 + 72e18); // got 72 extra, not the fair 360
assertEq(token.balanceOf(potAddr), 576e18); // 576 locked forever, no path to recover
}

Expected: the pot empties to the two in-time claimants. Actual: 576e18 of the 1000e18 remain trapped in the contract with no way out.

Recommended Mitigation

Divide the leftover by the number of in-time claimants, and handle the empty-claimants case so the division can't revert and no funds are stranded:

uint256 managerCut = remainingRewards / managerCutPercent;
i_token.transfer(msg.sender, managerCut);
uint256 leftover = remainingRewards - managerCut;
if (claimants.length == 0) {
i_token.transfer(msg.sender, leftover); // no in-time claimants: send the rest to the manager
} else {
uint256 claimantCut = leftover / claimants.length; // was i_players.length
for (uint256 i = 0; i < claimants.length; i++) {
_transferReward(claimants[i], claimantCut);
}
}

Dividing by claimants.length gives each in-time claimant an equal share of the entire leftover, matching the specification and leaving no tokens stranded. Also consider sweeping any integer-division dust (up to claimants.length - 1 wei) to the manager so the pot always fully empties.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 1 hour ago
Submission Judgement Published
Validated
Assigned finding tags:

[H-02] Incorrect logic in `Pot::closePot` leads to unfair distribution to `claimants`, potentially locking the funds with no way to take that out

## Description in `closePot` function while calclulating the shares for claimaint cut, `i_players.length` is used, instead of `claimants.length`, causing low amount being distributed to claimants. ## Vulnerability Details [2024-08-MyCut/src/Pot.sol at main · Cyfrin/2024-08-MyCut (github.com)](https://github.com/Cyfrin/2024-08-MyCut/blob/main/src/Pot.sol#L57) `Pot::closePot` function is meant to be called once contest passed 90 days, it sends the owner cut to owner and rest is splitted among the users who claimed b/w 90 days period. However, current implementation is wrong.&#x20; It uses total users (i_players.length) instead of the users (claimants.length) who claimed during the duration. This creates an unfair distribution to the participants and some of the funds could be locked in the contract. In worst case scenerio, it could be 90% if nobody has claimed from the protocol during the 90 days duration. ## POC In existing test suite, add following test: ```solidity function testUnfairDistributionInClosePot() public mintAndApproveTokens { // Setup address[] memory testPlayers = new address[](3); testPlayers[0] = makeAddr("player1"); testPlayers[1] = makeAddr("player2"); testPlayers[2] = makeAddr("player3"); uint256[] memory testRewards = new uint256[](3); testRewards[0] = 400; testRewards[1] = 300; testRewards[2] = 300; uint256 testTotalRewards = 1000; // Create and fund the contest vm.startPrank(user); address testContest = ContestManager(conMan).createContest( testPlayers, testRewards, IERC20(ERC20Mock(weth)), testTotalRewards ); ContestManager(conMan).fundContest(0); vm.stopPrank(); // Only player1 claims their reward vm.prank(testPlayers[0]); Pot(testContest).claimCut(); // Fast forward 91 days vm.warp(block.timestamp + 91 days); // Record balances before closing the pot uint256 player1BalanceBefore = ERC20Mock(weth).balanceOf( testPlayers[0] ); // Close the contest vm.prank(user); ContestManager(conMan).closeContest(testContest); // Check balances after closing the pot uint256 player1BalanceAfter = ERC20Mock(weth).balanceOf(testPlayers[0]); // Calculate expected distributions uint256 remainingRewards = 600; // 300 + 300 unclaimed rewards uint256 ownerCut = remainingRewards / 10; // 10% of remaining rewards uint256 distributionPerPlayer = (remainingRewards - ownerCut) / 1; // as only 1 user claimed uint256 fundStucked = ERC20Mock(weth).balanceOf(address(testContest)); // actual results console.log("expected reward:", distributionPerPlayer); console.log( "actual reward:", player1BalanceAfter - player1BalanceBefore ); console.log("Fund stucked:", fundStucked); } ``` then run `forge test --mt testUnfairDistributionInClosePot -vv` in the terminal and it will show following output: ```js [⠊] Compiling... [⠒] Compiling 1 files with Solc 0.8.20 [⠘] Solc 0.8.20 finished in 1.63s Compiler run successful! Ran 1 test for test/TestMyCut.t.sol:TestMyCut [PASS] testUnfairDistributionInClosePot() (gas: 905951) Logs: User Address: 0x6CA6d1e2D5347Bfab1d91e883F1915560e09129D Contest Manager Address 1: 0x7BD1119CEC127eeCDBa5DCA7d1Bd59986f6d7353 Minting tokens to: 0x6CA6d1e2D5347Bfab1d91e883F1915560e09129D Approved tokens to: 0x7BD1119CEC127eeCDBa5DCA7d1Bd59986f6d7353 expected reward: 540 actual reward: 180 Fund stucked: 360 Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 1.58ms (506.33µs CPU time) ``` ## Impact Loss of funds, Unfair distribution b/w users ## Recommendations Fix the functions as shown below: ```diff function closePot() external onlyOwner { if (block.timestamp - i_deployedAt < 90 days) { revert Pot__StillOpenForClaim(); } if (remainingRewards > 0) { uint256 managerCut = remainingRewards / managerCutPercent; i_token.transfer(msg.sender, managerCut); - uint256 claimantCut = (remainingRewards - managerCut) / i_players.length; + uint256 totalClaimants = claimants.length; + if(totalClaimant == 0){ + _transferReward(msg.sender, remainingRewards - managerCut); + } else { + uint256 claimantCut = (remainingRewards - managerCut) / claimants.length; for (uint256 i = 0; i < claimants.length; i++) { _transferReward(claimants[i], claimantCut); } } + } } ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!