this is can affect liquidity providers by misrepresenting the value of provided liquidity, and impact traders by calculating incorrect token amounts during swaps, and influence margin calculations for leveraged positions.
Root of the bug and summary
there is a logical flaw exists within the token conversion functions, convert0to1 and convert1to0, due to the handling of reduced precision at high sqrtPriceX96 values. The functions employ two different formulas to convert amounts between token0 and token1, the issue is arises in the convert0to1 and convert1to0 functions when handling conversions involving very high sqrtPriceX96 values.
// above that tick, we are forced to reduce the amount of decimals in the final price by 2**64 to 2**128
if (sqrtPriceX96 < type(uint128).max) {
return Math.mulDiv192(amount, uint256(sqrtPriceX96) ** 2);
} else {
return Math.mulDiv128(amount, Math.mulDiv64(sqrtPriceX96, sqrtPriceX96));
}
}
the bug is cause is the conditional that use of different mathematical precision levels based on the sqrtPriceX96 value, and the reduced precision formula drastically alters the output for high sqrtPriceX96 values, resulting in conversions that diverge substantially from those calculated with normal precision.
Proof of Concept
let's say a scenario that we have
token Amount: 1,000 tokens of token0
Square Root Price (sqrtPriceX96) => the square root of the price ratio between token0 and token1 scaled by 296296.
For this scenario, let's consider a very high value, such as 270270, to test the system at extreme conditions.
Using two different methods for the conversion, where:
Full Precision method uses the formula:
$Converted Amount=Amount×(sqrt(PriceX96))2×2^{-192} $
Reduced Precision method for high sqrtPriceX96 values:
$Converted Amount=Amount×(sqrt(PriceX96×2^{64}))2×2^{-128} $
in full Precision Calculation the result is extremely small non-zero value close to zero but not zero
and in Reduced Precision Calculation the result in a value that rounds down to zero due to the large negative exponent.
Tools Used
manual review
Recommended Mitigation Steps
need to ensures that the precision is only reduced when absolutely necessary and does so in a manner that lessens the impact on the final conversion outcome
Lines of code
https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/libraries/PanopticMath.sol#L493-L498
Vulnerability details
Impact
this is can affect liquidity providers by misrepresenting the value of provided liquidity, and impact traders by calculating incorrect token amounts during swaps, and influence margin calculations for leveraged positions.
Root of the bug and summary
there is a logical flaw exists within the token conversion functions, convert0to1 and convert1to0, due to the handling of reduced precision at high sqrtPriceX96 values. The functions employ two different formulas to convert amounts between token0 and token1, the issue is arises in the convert0to1 and convert1to0 functions when handling conversions involving very high sqrtPriceX96 values.
the bug is cause is the conditional that use of different mathematical precision levels based on the sqrtPriceX96 value, and the reduced precision formula drastically alters the output for high sqrtPriceX96 values, resulting in conversions that diverge substantially from those calculated with normal precision.
Proof of Concept
let's say a scenario that we have
in full Precision Calculation the result is extremely small non-zero value close to zero but not zero and in Reduced Precision Calculation the result in a value that rounds down to zero due to the large negative exponent.
Tools Used
manual review
Recommended Mitigation Steps
need to ensures that the precision is only reduced when absolutely necessary and does so in a manner that lessens the impact on the final conversion outcome
Assessed type
Other