PUSH0 - If both makers make a loss, closing positions may be impossible, discouraging liquidations

[sherlock-admin4]

PUSH0

high

If both makers make a loss, closing positions may be impossible, discouraging liquidations

Summary

In the case that both makers are in a loss position, the _checkMinMarginRatio() will trigger most of the time, preventing position closes, which will discourage liquidations.

Vulnerability Detail

Consider the following scenario:

• Both Makers are in a short position.
  • It follows that the majority of the market are in a long position.
• There are some users who are still bearish, and takes the short position.
• Price goes up, creating profits for long, and losses for short.
• Both Makers incur a loss due to being in a short. Most trades against them will fail due to the minMarginRatio safety check.
• Short users' position becomes unhealthy and liquidatable.
• However, no liquidation bots are willing to liquidate, as it is impossible to close out the position due to lack of available makers. Holding a recently liquidated position is a highly risky move, discouraging for liquidators.

Then the short positions (especially high-leverage ones) will likely go underwater before liquidators start to act. Note that the same can be said for the other trading direction as well.

Now, there is no problem yet if no traders can realize their profits or losses due to the lack of makers. However, we present several scenarios where an already-underwater short trader can close their position and realize their loss:

• Additional liquidity is added to either makers, which opens up more trading opportunities against them. Then liquidator bots will be the first to act against such movement, liquidating those underwater short positions and force a bad debt realization.
• Long traders can technically close their position and realize profits by liquidating the short positions manually. However this cannot reliably prevent bad debt (and in fact may force-realize bad debt) because:
  • Regular traders normally don't run bots that monitor other users' positions. By the time those traders realize the Maker DoS and are able to find liquidatable positions, those positions might have been already underwater.
  • Traders can choose when to close out their position. They are not obliged and have no incentives to force-close positions for the good of the protocol, and can choose when to realize their profits without any regards to how insolvent the other position is, especially when they are already holding a highly profitable position.

The end result is that, since liquidators are not able to profitably operate, unhealthy positions cannot be liquidated, and bad debt is accrued.

Impact

If both makers are in a losing position (or any other situation that results in being unable to add positions against them), closing other positions may be impossible, discouraging liquidations.

Code Snippet

https://github.com/sherlock-audit/2024-02-perpetual/blob/main/perp-contract-v3/src/maker/OracleMaker.sol#L377-L382

https://github.com/sherlock-audit/2024-02-perpetual/blob/main/perp-contract-v3/src/maker/SpotHedgeBaseMaker.sol#L685-L689

Tool used

Manual review

Recommendation

Introduce a maker specifically for closing liquidated positions and not for any other positions, to account for the case when both makers are out of commission. They can take the exact design as one of the current makers, preferrably Oracle Maker (two Spot Hedge Makers on the same market would share the same UniV3 liquidity, which defeats the purpose).

• An implementation detail could be that, in ClearingHouse.liquidate(), the liquidator can choose to force the position to the liquidation maker with a premium (part of liquidation fee, and/or the same base price spread as with an Oracle Maker), instead of having to carry the position themselves.

This is known as a "backstop" pool in other protocols, notably some lending protocols.

[sherlock-admin2]

1 comment(s) were left on this issue during the judging contest.

santipu_ commented:

High - Root cause in the inability to liquidate whitelisted makers

[rc56]

@lnxrp:

• Invalid
• minMarginRatio preventing position reduction is a known issue
• Unliquidatable whitelisted maker is also a known issue
• Note the two makers (OracleMaker & SpotHedgeMaker) are not expected to be the only makers in the market, there will also be ad hoc orders from off-chain market makers

[nevillehuang]

request poc

[sherlock-admin2]

PoC requested from @PUSH0

Requests remaining: 6

[Oot2k]

minMarginRatio preventing position reduction is a known issue

We agree. However, this issue points out a temporary DoS scenario where both makers are out of commission due to price movements. The root cause of this issue is the lack of guaranteed liquidity avenue in the case of both makers on a loss.

Unliquidatable whitelisted maker is also a known issue

We agree, however this issue does not rely on whether a whitelisted maker is liquidatable or not.

Note the two makers (OracleMaker & SpotHedgeMaker) are not expected to be the only makers in the market, there will also be ad hoc orders from off-chain market makers

This is a dangerous assumption because:

• The two dedicated makers (Oracle and SHBM) are the only ones guaranteed to provide liquidity.
• In low cap markets there might be no other makers when liquidation accrues

All in all we still believe this to be a high severity issue.

[midori-fuse]

Indeed that what we're pointing here is not an issue with whitelisted makers, but rather a temporary DoS scenario, where, if both makers are losing, then there may be no liquidity avenue to close out the liquidated positions (or any positions at all). There are only three ways for the maker's DoS to resolve from there:

• A whale opens a massive maker de-risk trade. This is equivalent to the whale taking a large chunk of the maker's position.
• Someone deposits massive amount of liquidity there.
• Price goes back to the maker's healthy range.

None of these scenario can be considered likely, or even guaranteed, in the near future, given the history of cryptocurrency price. Generally a liquidator only wants to operate when they can guarantee a profit for themselves. Ad-hoc makers are not guaranteed liquidity (i.e. there is no guarantee that there are enough pending orders in the correct price range to close the liquidated positions on).

[lnxrp]

• The two dedicated makers (Oracle and SHBM) are the only ones guaranteed to provide liquidity.
• In low cap markets there might be no other makers when liquidation accrues

Ad-hoc makers are not guaranteed liquidity (i.e. there is no guarantee that there are enough pending orders in the correct price range to close the liquidated positions on).

I agree that guaranteed liquidity would greatly help stabilize the market in volatile times, but I'd like to dispute on the concept of using the two on-chain makers as guaranteed liquidity (or backstop-LP in CEX): there are more efficient options.

• The two on-chain makers are meant to provide automated & structural strategies to attract passive LP. They are supposed to control their risks and make steady profit to the LP. On the other hand, backstop-LP is a risky business and almost never works without proper external hedging (look at FTX), if we force them to guarantee liquidity during volatile periods, without other incentives, the strategies may no longer be attractive and we would still likely end up having no LP and no liquidity

• If illiquidity is the concern, we could either (1) de-risk the launch parameter so bad debt is less likely to happen, or (2) find willing partners to be the backstop-liquidator, which could mean providing emergency off-chain limit orders, or simply taking over and holding the liquidated position while hedging externally until market stabilized

[IllIllI000]

@nevillehuang The root cause of this issue is the lack of guaranteed liquidity avenue in the case of both makers on a loss nowhere does it say that there is any guarantee of liquidity, so this sounds like a feature request to make the two primary makers take on risk even when they're designed not to, when their risk parameters say they shouldn't. The sponsor and the docs say that there should be other non-automated makers, and they should handle the task of liquidation in such events.

[Oot2k]

escalate

I want to bring this issue up for discussion again. I strongly disagree with senior comment, this is not a feature request in any way. And the statement of maker taking addition risk is wrong.

Shortly in regards to comment from senior: In case the market moves up, maker is short and short position would get liquidated, the liquidator would have to open a long position to close his transferred short position. (In perpetual on liquidations the underwater position is transferred to the liquidator, and not closed directly) Opening this long position would actually derisk the maker because the underwater position of maker would get reduced.

But this should not be part of the discussion if this issue is valid or not, but rather if the proposed fix is good. This does not change the severity or deny the existents of this issue, rather opens a discussion on how to fix it.

Referring to sponsors and seniors comment this issue is a major problem, but the fix is non trivial.

For this reason I request a rejudgement of this issue.

[sherlock-admin2]

escalate

I want to bring this issue up for discussion again. I strongly disagree with senior comment, this is not a feature request in any way. And the statement of maker taking addition risk is wrong.

Shortly in regards to comment from senior: In case the market moves up, maker is short and short position would get liquidated, the liquidator would have to open a long position to close his transferred short position. (In perpetual on liquidations the underwater position is transferred to the liquidator, and not closed directly) Opening this long position would actually derisk the maker because the underwater position of maker would get reduced.

But this should not be part of the discussion if this issue is valid or not, but rather if the proposed fix is good. This does not change the severity or deny the existents of this issue, rather opens a discussion on how to fix it.

Referring to sponsors and seniors comment this issue is a major problem, but the fix is non trivial.

For this reason I request a rejudgement of this issue.

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[nevillehuang]

@Oot2k @midori-fuse I think given the constraint highlighted by the sponsor here, it would be good to see a coded/numerical PoC on how this issue can cause issues that also bypasses the constraints mentioned.

[WangSecurity]

@Oot2k @midori-fuse want to loop you in here. Firstly, can you give any numerical PoC (if coded, would be ideal). Secondly, I see you say that the root cause is indeed not in whitelisted makers cannot be liquidated, but if both of them are in a losing position then the liquidations are impossible, correct? If it was possible to liquidate them, would it fix the issue? Thirdly, this sentence is quite confusing to me:

closing other positions may be impossible, discouraging liquidations.

Is it completely impossible and liquidations will revert or the liquidation will go through, but liquidators won't receive they reward now, and will receive it later?

[Oot2k]

Hi @WangSecurity I dont think a numerical POC will show much different then just explaining like the issue does. Liquidating makers will not fix this issue because they dont have to be in a liquidatable state.

The issue summarized:

• perp does not close positions on liquidation, but just transfers them to liquidator, who needs to close them them self
• closing positions only works in case there is a maker who can take the opposite position
• in case both makers drop below min margin requirement they cant open positions anymore. (but cant be liquidated)
• now liquidators are forced to keep open positions which might lose value / they are subject to loss

• because they cant instantly close these positions liquidations are discouraged

  There are several other points to this which I have mentioned above, (why external markets should be out of scope etc.)

[WangSecurity]

Firstly, although this situation may occur, the protocol doesn't guarantee liquidity. Moreover, according to docs, there should be other non-automated makers. Hence, I believe this report is not an issue, but a design decision.

Planning to reject the escalation and leave the issue as it is.

[Evert0x]

Result: Invalid Unique

[sherlock-admin4]

Escalations have been resolved successfully!

Escalation status:

• Oot2k: rejected