MyCut

First Flight #23
Beginner FriendlyFoundry
100 EXP
View results
Submission Details
Severity: high
Invalid

Precision Loss in Manager Cut Calculation Leads to Variable Payouts

Summary:

The calculation of the manager's cut in the closePot function suffers from precision loss due to integer division. This results in the manager not always receiving a consistent cut, with payouts varying based on the size of the remaining pool. The reward amount is highly dependent on the exact size of the remaining pool, causing potential inconsistencies in the expected manager's reward.

Vulnerability Details:

In the closePot function, the manager's cut is calculated using integer division:

uint256 managerCut = remainingRewards / managerCutPercent;

Due to Solidity's use of integer division, any fractional component is truncated, leading to precision loss. This can cause situations where small changes in the remaining pool size result in significant differences in the manager's cut. For instance, if the remaining pool is 89 tokens, the manager's cut might be calculated as 8 (if the manager cut percent is 10). However, if the pool increases to 90 tokens, the manager cut could suddenly become 9. This inconsistency makes the manager's cut highly variable and dependent on the exact remaining pool size rather than being a predictable, fixed percentage.

Impact:

The impact of this vulnerability includes:

  • Inconsistent Manager Rewards: The manager might receive different amounts for nearly identical pool sizes, leading to unpredictable payouts.

  • Reduced Trust: This inconsistency in the reward mechanism could reduce trust in the fairness and reliability of the protocol, as the manager's compensation is not always proportional to the pool size.

  • Financial Discrepancies: Over multiple distributions, these discrepancies can accumulate, causing potential financial disagreements or a perceived lack of transparency in reward distribution.

Tools Used:

  • Manual Review

Recommendations:

To ensure the manager receives a predictable, fixed percentage cut, consider implementing a mechanism to handle precision loss and distribute the remainder fairly. One approach is to use a more precise calculation method, such as a fixed-point arithmetic library, or to accumulate remainders and distribute them over multiple distributions.

Alternatively, you could adjust the reward calculation to ensure the manager's cut is as close as possible to the intended percentage:

Updated Function Example to Handle Precision Loss:

function closePot() external onlyOwner {
if (block.timestamp - i_deployedAt < 90 days) {
revert Pot__StillOpenForClaim();
}
if (remainingRewards > 0) {
uint256 managerCut = (remainingRewards * managerCutPercent) / 100; // Use multiplication first to reduce precision loss
uint256 remainingAfterManagerCut = remainingRewards - managerCut;
i_token.transfer(msg.sender, managerCut);
uint256 baseCutPerClaimant = remainingAfterManagerCut / claimants.length;
uint256 remainder = remainingAfterManagerCut % claimants.length;
for (uint256 i = 0; i < claimants.length; i++) {
_transferReward(claimants[i], baseCutPerClaimant);
}
// Optionally, handle remainder to prevent dead funds
if (remainder > 0) {
i_token.transfer(msg.sender, remainder);
}
}
}

Although it still depends on the team how they choose to manage the reward distribution, this approach offers one way to handle precision loss and ensure a more predictable payout for the manager.

By adopting such strategies, the contract can provide more consistent rewards for the manager, ensuring fairness and maintaining trust in the protocol's financial operations.

Updates

Lead Judging Commences

equious Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

Erroneous ManagerCut calculation

Appeal created

equious Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Other

Support

FAQs

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