Incorrect validation during checking liquidity spread

[c4-bot-10]

Lines of code

https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticPool.sol#L1483

Vulnerability details

Impact

Because of incorrect validation, it allows option buyers not to pay premium.

Proof of Concept

When long leg is minted or short leg is burnt, the protocol checks liquidity spread by calculating TotalLiquidity / NetLiquidity and allows it not exceed 9.
However in the check function, the validation is ignored when NetLiquidity is zero.

This means when a user mints long leg that buys whole selling amount, the liquidity spread is not checked.
This issue allows the option buyer not to pay premium, and here is why:

1. When options are minted, last accumulated premium is stored to s_grossPremiumLast. Refer to _updateSettlementPostMint function of PanopticPool contract.
2. When options are burned, new accumulated premium is fetched and calculates the premium by multiplying liquidity with difference in accumulated premium. Refer to _updateSettlementPostBurn function of PanopticPool contract.
3. However, when a long leg of T(total liquidity) amount is minted, N becomes zero.
4. Later, when the minted long leg is burnt, premium values are not updated in SFPM, because N is zero. Refer to SFPM:L1085

Since there is no difference in owed premium value, the option buyer will not pay the premium when burning the option.

Tools Used

Manual Review

Recommended Mitigation Steps

When checking liquidity spread, it should revert when N is zero and T is positive:

+   if(netLiquidity == 0 && totalLiquidity > 0) revert;
    if(netLiquidity == 0) return;

Assessed type

Context

[c4-judge]

Picodes marked the issue as satisfactory

[c4-judge]

Picodes marked the issue as selected for report