Liquidity Management
Gamma
DeFiFoundry
50,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Unhandled Decimals

nave765

Summary

Improper handling of decimals can lead to the minting of false shares, negatively impacting the protocol.

Vulnerability Details

The PerpetualVault::_mint function is used in various operations such as deposit, afterOrderExecution, and runSwap to calculate the number of shares received based on the given amount. However, an issue arises when totalAmountBefore == 0, as the value is then set to 1.

function _mint( uint256 depositId, uint256 amount, bool refundFee, MarketPrices memory prices) internal {
uint256 _shares;
if (totalShares == 0) {
_shares = depositInfo[depositId].amount * 1e8;
} else {
uint256 totalAmountBefore;
if (positionIsClosed == false && _isLongOneLeverage(beenLong)) {
totalAmountBefore =
IERC20(indexToken).balanceOf(address(this)) -
amount;
} else {
totalAmountBefore = _totalAmount(prices) - amount;
}
@> if (totalAmountBefore == 0) totalAmountBefore = 1;
_shares = (amount * totalShares) / totalAmountBefore;
}
​
depositInfo[depositId].shares = _shares;
totalShares = totalShares + _shares;
​
_;
}

When totalAmountBefore = 0 due to various conditions, it is automatically updated to 1. However, this does not account for decimals properly, leading to incorrect _shares calculations, especially with high decimal values from amount * totalShares. Ideally, totalAmountBefore should be used to reduce the decimals generated from amount * totalShares.

Impact

  • This scenario enables malicious actors to inflate their shares, effectively taking funds from others by increasing their own share allocation.

  • It also creates an imbalance in share distribution, which can negatively impact the overall protocol.

Tools Used

Manual Review

Recommendations

Change totalAmountBefore = 1 to totalAmountBefore = 1e(decimals)

Updates

Lead Judging Commences

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

invalid_totalAmountBefore_is_1_incorrect_calculation_supposition

No proof when this can happen: Most of the time totalAmountBefore equals 0 (balance minus amount sent), it means totalShares equals 0. If it could happen with very specific conditions, report with that tag didn't add the needed details to be validated.

Support

FAQs

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

Give us feedback!