[H-02] Wrong decimals precision when using RdpxEthOracle as oracle returns price in 18 decimals

[code423n4]

Lines of code

https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/core/RdpxV2Core.sol#L605
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/core/RdpxV2Core.sol#L669
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/core/RdpxV2Core.sol#L673
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/perp-vault/PerpetualAtlanticVault.sol#L27
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/reLP/ReLPContract.sol#L253
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/reLP/ReLPContract.sol#L274
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/reLP/ReLPContract.sol#L255
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/reLP/ReLPContract.sol#L275
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/core/RdpxV2Core.sol#L1172
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/core/RdpxV2Core.sol#L1181
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/perp-vault/PerpetualAtlanticVaultLP.sol#L281

Vulnerability details

Impact

All prices are assume to return 8 decimal precision, but the oracle clearly return all prices in 18 decimals as seen in RdpxEthOracle.sol. The two price functions used are getLpPriceInETH() and getRdpxPriceInEth().

getRdpxPriceInEth():

RdpxEthOracle.sol#L250

/// @notice Returns the price of rDPX in ETH
/// @return price price of rDPX in ETH in 1e18 decimals
function getRdpxPriceInEth() external view override returns (uint price) {
    require(
        blockTimestampLast + timePeriod + nonUpdateTolerance >
            block.timestamp,
        "RdpxEthOracle: UPDATE_TOLERANCE_EXCEEDED"
    );

    // @audit returns prices in 1e18 decimals as seen by using `amountIn` of 1e18
->  price = consult(token0, 1e18);

    require(price > 0, "RdpxEthOracle: PRICE_ZERO");
}

• This will cause a heavy overestimation of rdpx amount when converting amount of rDPX to equivalent wETH amount.
• This will cause a heavy underestimation of rDPX amount when converting wETH to rDPX

getLpPriceInETH():

RdpxEthOracle.sol#L217

/// @dev Returns the price of LP in ETH in 1e18 decimals
function getLpPriceInEth() external view override returns (uint) {
    uint totalSupply = pair.totalSupply();
    (uint r0, uint r1, ) = pair.getReserves();
    uint sqrtK = HomoraMath.sqrt(r0.mul(r1)).fdiv(totalSupply); // in 2**112
    uint px0 = getETHPx(token0); // in 2**112
    uint px1 = 2 ** 112; // in 2**112
    // fair token0 amt: sqrtK * sqrt(px1/px0)
    // fair token1 amt: sqrtK * sqrt(px0/px1)
    // fair lp price = 2 * sqrtK * sqrt(px0 * px1)
    // split into 2 sqrts multiplication to prevent uint overflow (note the 2**112)
    uint lpPriceIn112x112 = sqrtK
        .mul(2)
        .mul(HomoraMath.sqrt(px0))
        .div(2 ** 56)
        .mul(HomoraMath.sqrt(px1))
        .div(2 ** 56);

    //@audit returns price in 18 decimals as noticed by the multiplication of 1e18
->  return (lpPriceIn112x112 * 1e18) >> 112;
}

• Not used in the codebase other than in view function getLpPrice(), which is in turn used in getLpTokenBalanceInWeth()
• But if used, will heavily overestimate Lp token balance in terms of wETH

In the RdpxV2Core.sol core contract, it can cause the following:

• DoS of bonding mechanism (regardless of type) due to _transfer() reverting from underflow here (assuming APP puts are not allowed to be purchased)
• DoS of upperDepeg() decollaterization, if slippage not specified, since slippage (minOut) will be overestimated here
• Dos of lowerDepeg recollaterization, as price check here will always revert here

In the PerpetualAtlanticVault.sol contract, it can cause the following:

• Strike price is calculated with a decimal of 18 precision, leading to required collateral being overestimated here and than the subsequent check fails. This can DoS the purchase of APP options and bonding mechanism as well since initial purchase of APP options is done through bonding.

In the ReLPContract.sol contract, it can cause the following:

• Assuming _transfer() and purchase() did not revert, the reLP process will revert due to overestimated amount of rDPX by a factor of 10 to be swapped out using half of wETH here. This reverts the whole reLP process and consequently, the bonding process.

In the PerpetualAtlanticVaultLP.sol contract, it can cause the following:

• Hugely overestimated total collateral value in PerpetualAtlanticVaultLP.convertToShares() here, leading to rounding down of shares to 0 and DoSing option writers from depositing collateral into LP vault due to a check reverting here and affecting APP option process.

Tools Used

Manual Analysis

Recommendation

In the following LOC, change precision of operators, division or multiplication from 1e8 to 1e18

• RdpxV2Core.sol#L546
• RdpxV2Core.sol#L548
• RdpxV2Core.sol#L605
• RdpxV2Core.sol#L669
• RdpxV2Core.sol#L673
• RdpxV2Core.sol#L1087
• PerpetualAtlanticVault.sol#L276
• PerpetualAtlanticVaultLP.sol#L281
• ReLPContract.sol#L253
• ReLPContract.sol#L274

In the function ReLPContract.reLP(), change precision dividing from 1e16 to 1e26

• RdpxV2Core.sol#L547
• RdpxV2Core.sol#L549
• ReLPContract.sol#L255
• ReLPContract.sol#L275

In the function RdpxV2Core.calculateBondCost(), multiply by 1e18 Instead of DEFAULT_PRECISION in the following LOC:

• RdpxV2Core.sol#L1172
• RdpxV2Core.sol#L1181

Assessed type

Context

[c4-pre-sort]

bytes032 marked the issue as duplicate of #549

[c4-pre-sort]

bytes032 marked the issue as sufficient quality report

[c4-judge]

GalloDaSballo marked the issue as satisfactory

[c4-judge]

GalloDaSballo changed the severity to 2 (Med Risk)

[c4-judge]

GalloDaSballo changed the severity to 3 (High Risk)