MyCut

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

Wrong managerCut Calculation

The manager cut calculation is wrong, manager get less cut than he should

Description

  • since the manager cut is 10 if it is 10% the calculation should be (reward * managercut) / 100 to get the correct 10% that the manager should get

  • In teh code their is just (reward / manager cut ) if the manager cut go up he will get less + rounding issues because their is no perecision

if (remainingRewards > 0) {
uint256 managerCut = remainingRewards / managerCutPercent;
//@audit-issues: the manager has 10 but their is no precision so this 10 don't represent real value
//@audit-issue: This can lead to rounding issues and the calculation not corrcet if teh percent chaneg the cut will be wrong
i_token.transfer(msg.sender, managerCut);

Risk

Likelihood:

  • Everytime a contest end this will happens

Impact:

  • Manger get less cut if teh persentage go up

  • Because of teh rounding issue manager get less thna they should

Proof of Concept

This is teh full step by step sinario to prove the bug

1- start a contest
2- after 91 days teh contest end and the rewards will destrbuite
3- rewrds = 867 and manager cut 10
3- managercut= (867 / 10) = 86.7 manager get just 86 loss 0.7
4- if the manager cut go up the rewards will be lesss
4- manegrcut = (867 / 20) = 43.35 so the peresnet here didn't work

Recommended Mitigation

Adding precision to avoide the roundign issues and multiply before devide to get correct persente

- uint256 managerCut = remainingRewards / managerCutPercent;
+ Uint256 managerCut = (remainungRewards * managerCutPersent) / 100
Updates

Lead Judging Commences

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

[L-03] [H-03] Precision loss can lead to rewards getting stuck in the pot forever

### \[H-03] Precision loss can lead to rewards getting stuck in the pot forever **Description:** When contest manager closes the pot by calling `Pot::closePot`, 10 percent of the remaining rewards are transferred to the contest manager and the rest are distributed equally among the claimants. It does this by dividing the rewards by the manager's cut percentage which is 10. Then the remaining rewards are divided by the number of players to distribute equally among claimants. Since solidity allows only integer division this will lead to precision loss which will cause a portion of funds to be left in the pot forever. Each pot follows the same method, so as number of pots grow, the loss of funds is very significant. **Impact:** Reward tokens get stuck in the pot forever which causes loss of funds. **Proof of code:** Add the below test to `test/TestMyCut.t.sol` ```javascript function testPrecisionLoss() public mintAndApproveTokens { ContestManager cm = ContestManager(conMan); uint playersLength = 3; address[] memory p = new address[](playersLength); uint256[] memory r = new uint256[](playersLength); uint tr = 86; p[0] = makeAddr("_player1"); p[1] = makeAddr("_player2"); p[2] = makeAddr("_player3"); r[0] = 20; r[1] = 23; r[2] = 43; vm.startPrank(user); address pot = cm.createContest(p, r, weth, tr); cm.fundContest(0); vm.stopPrank(); console.log("\n\ntoken balance in pot before: ", weth.balanceOf(pot)); vm.prank(p[1]); // player 2 Pot(pot).claimCut(); vm.prank(p[0]); // player 1 Pot(pot).claimCut(); vm.prank(user); vm.warp(block.timestamp + 90 days + 1); cm.closeContest(pot); console.log( "\n\ntoken balance in pot after closing pot: ", weth.balanceOf(pot) ); assert(weth.balanceOf(pot) != 0); } ``` Run the below test command in terminal ```Solidity forge test --mt testPrecisionLoss -vv ``` Which results in the below output ```Solidity [⠒] Compiling... [⠆] Compiling 1 files with 0.8.20 [⠰] Solc 0.8.20 finished in 2.57s Compiler run successful! Ran 1 test for test/TestMyCut.t.sol:TestMyCut [PASS] testPrecisionLoss() (gas: 936926) Logs: token balance in pot before: 86 token balance in pot after closing pot: 1 Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 1.75ms (654.60µs CPU time) Ran 1 test suite in 261.16ms (1.75ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests) ``` If you observe the output you can see the pot still has rewards despite distributing them to claimants. **Recommended Mitigations:** Fixed-Point Arithmetic: Utilize a fixed-point arithmetic library or implement a custom solution to handle fee calculations with greater precision.

Support

FAQs

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

Give us feedback!