DeFiFoundry
60,000 USDC
View results
Submission Details
Severity: medium
Invalid

Protocol Can Become Insolvent Due to No PnL Consideration

Summary

When the traders' profit exceeds what is possible to be paid out, the protocol is in an insolvent state (debt exceeds assets). The hope is that this would not be possible because as one side (longs) is winning, the other side (shorts) would be losing. But this assumption only holds true when the two sides are perfectly balanced. However, if you look at almost any perpetual market, the long/short split is not 50/50.

What this results in is that whenever the side that is greater than 50% is winning, the traders are at a net loss (loss from the winning traders exceeds the winnings from the losing traders). This is natural and part of the risk that LPs take.

The issue here is that there is no validation of the unrealized PnL. This means that when one side has a large enough profit or some LPs remove liquidity, there is no prevention from additional traders opening positions on the insolvent side.

What this does is create a situation where there are not enough winnings for all the traders (insolvent). This leads to some traders closing their position and getting what they are owed, while others will not get their PnL when closing, and would have to wait until their unrealized PnL decreases, leading to a loss of yield.

This situation is not as far-fetched as one would initially believe it to be. The losing traders' losses are all unrealized until the position is closed, liquidated, or updated. This means that the only liquidity available to payout the winners is what the LPs have provided. So there does not need to be a huge net win for one side compared to the other. All that needs to happen is for one side to have more profit than what is available.

The open interest check is not sufficient for this as it has nothing to do with unrealized PnL. What is needed is a validateMaxPnl function similar to what GMX has:
https://github.com/gmx-io/gmx-synthetics/blob/5173cbeb196ed5596373acd71c75a5c7a60a98f5/contracts/market/MarketUtils.sol#L2731

If this were to be used in the createMarketOrder function, it would prevent new orders from making the market more insolvent.

In addition to this, I would say some type of automated deleveraging is needed. Once certain unrealized PnL thresholds are exceeded, the most profitable positions should be automatically closed. This would further aid in keeping markets solvent. You can refer to GMX V2 on how to best implement this. But at a minimum, a validateMaxPnl should be incorporated.

Vulnerability Details

Example:

  • Alice represents all longs

  • Bob represents all LPs

  • Carl represents all shorts

  • Dave represents late entry long

Bob provides $1,000,000 in liquidity for the Doge market.
Alice opens a$550,000 size in long positions for the Doge market.
Carl also opens a $400,000 size in shorts for the Doge market with sufficient collateral.
Doge increases in price by 100%.
Long positions are now worth$1,100,000.
Short positions are worth $250,000 but with no liquidations as they were not overly leveraged.
Dave sees Doge increase and opens a long position as well.
Doge increases 5% more.
Dave takes his small profit.
Alice closes her position but can't because not only is there not enough liquidity, but Dave came in and made profit that should not have been made available as that profit was already accounted for in the other users' unrealized PnL.

Alice now must wait until her position loses profit.

I would put the likelihood at low and the impact at high, making this overall a medium.

This situation is unlikely to happen often but very likely to happen in general, which is why protocols like GMX have these checks and the ADL functionality.

The impact is high because the protocol is insolvent, and the outcome would be for traders to lose some of their profit.

Impact

Loss of yield and insolvency.

Tools Used

Manual analysis.

Recommendations

Implement a validateMaxPnl type of function as well as consider some form of automated deleveraging (ADL).

Updates

Lead Judging Commences

inallhonesty Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.