Closed c4-bot-4 closed 3 months ago
This comment is confusing (so this can be a QA issue). It actually is defined as total(Removed)liquidity/netLiquidity, and you can see that is consistent with the maximum limit (9x removed/1x net = 90% max).
Picodes changed the severity to QA (Quality Assurance)
Downgrading to QA under "function incorrect as to spec, issues with comments"
Lines of code
https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticPool.sol#L1481-L1494
Vulnerability details
Impact
Incorrect validation of
effectiveLiquidityLimitX32
in_checkLiquiditySpread()
, this will allow minting to succeed even wheneffectiveLiquidityLimitX32
is exceeded.Proof of Concept
In SFPM,
net = totalLiquidity - removedLiquidity
, sototalLiquidity = removedLiquidity + netLiquidity
. As seen in the comment belowAlso,
s_accountLiquidity
holdsnetLiquidty
in the right slot, whileremovedLiquidty
is held in the left slot.When minting a long position, _addUserOption() makes a call to PP._checkLiquiditySpread(), to put a limit on how much new liquidity in one transaction can be deployed into this leg(comment).
The core problem lies in the fact that the formula to calculate effectiveLiquidityFactorX32 is
totalLiquidity/netLiquidity
, but uses the the value from the left slot of s_accountLiquidity[positionKey] as totalLiquidity.Even in the same PP, totalLiquidity was said to be removed + net inside
_getTotalLiquidity()
function.The implication is that the calculation for
effectiveLiquidityFactorX32
Tools Used
Manual review.
Recommended Mitigation Steps
totalLiquidity should include left and right chunk of accountLiquidities
Assessed type
Invalid Validation