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

Depositors who provide a large amount can receive a higher share rate, even compared to the first depositor.

typical_human

Summary

The protocol implements a Vault architecture that allows users to deposit and withdraw funds. The vulnerability lies in the _mint function and how shares for deposits are calculated. Depending on the deposit amount, users can receive disproportionately profitable rates.

Vulnerability Details

Let's take a look at the _mint function:

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 && _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 += _shares;
​
if (refundFee) {
uint256 usedFee = callbackGasLimit * tx.gasprice;
if (depositInfo[counter].executionFee > usedFee) {
try IGmxProxy(gmxProxy).refundExecutionFee(depositInfo[counter].owner, depositInfo[counter].executionFee - usedFee) {} catch {}
}
}
​
emit Minted(depositId, depositInfo[depositId].owner, _shares, amount);
}

As we can see, after the first deposit is made, shares are calculated based on the amount deposited relative to the current balance. The problem with this approach is that if a user deposits an amount close to the current Vault balance, they will receive a significantly higher share allocation.

For example:

  1. The first depositor deposits 1e10 tokens and receives 10e18 shares.

  2. The second depositor also deposits 1e10 tokens, but their share calculation is as follows:

totalAmountBefore = 1e10 - 1e10 = 0
totalAmountBefore = 1;
_shares = amount * totalShares / totalAmountBefore = 1e10 * 1e18 = 1e28

As we can see, the second depositor receives significantly more shares than the first depositor, despite depositing the same amount of tokens.

Impact

Users can receive far more shares than intended by the protocol, leading to unfair distribution and potential exploitation.

Tools Used

Manual review.

Recommendations

Fix the formula to align with the ERC-4626 shares/tokens calculation method.

Updates

Lead Judging Commences

n0kto Lead Judge 7 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.