MyCut

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

Incorrect divisor in Pot::closePot permanently locks funds and underpays claimants

# [H-1] Incorrect divisor in `Pot::closePot` permanently locks funds and underpays claimants
## Summary
When a `Pot` is closed, the leftover rewards (after the manager's cut) are meant to be split **equally among the players who claimed in time** (the `claimants`). However, `closePot` divides the leftover by `i_players.length` (the total number of players) instead of `claimants.length` (the number of players who actually claimed). When some players do not claim, this under-distributes the remainder and leaves the difference permanently locked in the contract.
## Vulnerability Details
In `Pot::closePot`, the per-claimant share is computed with the wrong divisor:
```solidity
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);
// @audit divides by i_players.length (ALL players) instead of
// claimants.length (players who claimed in time)
uint256 claimantCut = (remainingRewards - managerCut) / i_players.length;
for (uint256 i = 0; i < claimants.length; i++) {
_transferReward(claimants[i], claimantCut);
}
}
}
```
The project README states the intended behavior explicitly:
> "...the manager takes a cut of the remaining pool and the remainder is distributed equally to **those who claimed in time**!"
`claimants` is the set of "those who claimed in time", so the divisor must be `claimants.length`. Using `i_players.length` means that whenever `claimants.length < i_players.length` (i.e. at least one player did not claim), the loop distributes strictly less than `remainingRewards - managerCut`, and the undistributed remainder stays stuck in the `Pot` forever — there is no other code path that can ever move it out.
## Impact
- **Permanent loss of funds**: tokens that should have been distributed to legitimate claimants remain locked in the `Pot` contract with no recovery mechanism.
- **Claimants are underpaid**: players who correctly claimed in time receive less than the protocol promises.
- The shortfall grows as the ratio of non-claiming players increases. With N total players and K claimants (K < N), each claimant receives a factor of `K/N` of what they are owed from the remainder.
Direct, unrecoverable loss of user funds → **High**.
## Proof of Concept
Scenario: 2 players each owed 50 (total pool 100). Only `player1` claims in time. After 90 days the owner closes the pot.
- Expected: `managerCut = 5`, remainder `45` goes entirely to the single claimant `player1`. Pot ends at 0; `player1` total = 50 + 45 = 95.
- Actual: `claimantCut = (50 - 5) / 2 = 22`. Pot distributes only 5 + 22 = 27. **23 tokens are locked forever**; `player1` total = 50 + 22 = 72.
Add the following test (uses a minimal mock ERC20) and run `forge test --match-path test/PoC_LockedFunds.t.sol -vv`:
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import {Test, console} from "forge-std/Test.sol";
import {ContestManager} from "../src/ContestManager.sol";
import {Pot} from "../src/Pot.sol";
import {ERC20} from "lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol";
contract MockERC20 is ERC20 {
constructor() ERC20("Mock", "MCK") {}
function mint(address to, uint256 amount) external { _mint(to, amount); }
}
contract PoC_LockedFunds is Test {
ContestManager manager;
MockERC20 token;
address player1 = makeAddr("player1");
address player2 = makeAddr("player2");
function setUp() public {
token = new MockERC20();
manager = new ContestManager(); // owner = address(this)
token.mint(address(this), 100);
}
function test_FundsLockedDueToWrongDivisor() public {
address[] memory players = new address[](2);
players[0] = player1; players[1] = player2;
uint256[] memory rewards = new uint256[](2);
rewards[0] = 50; rewards[1] = 50;
address potAddr = manager.createContest(players, rewards, token, 100);
Pot pot = Pot(potAddr);
token.approve(address(manager), 100);
manager.fundContest(0);
vm.prank(player1);
pot.claimCut(); // only player1 claims in time
vm.warp(block.timestamp + 90 days + 1);
manager.closeContest(potAddr);
// 23 tokens are stuck in the Pot with no way out
assertEq(token.balanceOf(potAddr), 23);
// player1 got 72 instead of the deserved 95
assertEq(token.balanceOf(player1), 72);
}
}
```
The test passes, confirming 23 tokens are permanently locked and `player1` is underpaid by 23.
## Recommended Mitigation
Divide the remainder by the number of actual claimants. Guard against the empty-claimants case to avoid a division-by-zero revert that would block closing the pot.
```diff
- uint256 claimantCut = (remainingRewards - managerCut) / i_players.length;
- for (uint256 i = 0; i < claimants.length; i++) {
- _transferReward(claimants[i], claimantCut);
- }
+ if (claimants.length > 0) {
+ uint256 claimantCut = (remainingRewards - managerCut) / claimants.length;
+ for (uint256 i = 0; i < claimants.length; i++) {
+ _transferReward(claimants[i], claimantCut);
+ }
+ }
```
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 5 hours 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!