No grace time for traders when L2 sequencers come online after being down, making them prone to liquidations

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-05-predy/blob/a9246db5f874a91fb71c296aac6a66902289306a/src/PriceFeed.sol#L45-L58
https://github.com/code-423n4/2024-05-predy/blob/a9246db5f874a91fb71c296aac6a66902289306a/src/libraries/logic/LiquidationLogic.sol#L39

Vulnerability details

Impact

Traders are prone to liquidation when an L2 sequencer becomes online as there is no grace period for traders to adjust their positions.

Proof of Concept

Please read this section of the blog -

However one more issue remains; if repayments are paused, during that pause market fluctuations can cause a Borrower to become subject to liquidation as the Borrower is unable to repay(). As soon as repayments are resumed, such a Borrower will be immediately liquidated by liquidation bots, with the only possibility to save their position being if the Borrower themselves runs a repayment bot & can successfully front-run the liquidation bots.

This situation unfairly disadvantages Borrowers as such Borrowers became subject to liquidation through no fault of their own. Upon repayments resuming a Borrower will be immediately liquidated, unfairly disadvantaging the Borrower and giving a huge advantage to the Liquidator.

To fix the game theory such that neither Borrowers nor Liquidators are unfairly favored, after repayments are resumed there should be a grace period during which Borrowers can't be liquidated.

Although the protocol has not directly implemented a pausing functionality. Think of L2 sequencer downtime scenarios.

When an L2 sequencer comes online again after it went offline, and if the market conditions continue to remain unfavourable for traders, they can get immediately liquidated by bots, as they don't have enough time to adjust their positions.

The protocol should give grace time to traders to avoid liquidations. Put another way, liquidations should only be executed after the grace time has passed.

AAVE has implemented a grace time for its users to avoid liquidations -
https://docs.aave.com/developers#price-oracle-sentinel

Since the impact of the issue is high and the likelihood can be low, this issue is of medium severity.

Tools Used

Manual review

Recommended Mitigation Steps

Add a grace time after the L2 sequencer comes back online, such that liquidations can only be executed after the grace time has passed, giving enough time for traders to adjust their margins.

Assessed type

Other

[alex-ppg]

The submission and its duplicates describe how the oracles in the Predy system do not validate that the sequencer is live via an on-chain call.

This is generally considered a best practice recommendation and has historically been graded as a QA-level flaw which I would consider as a fair evaluation (specifically, QA (L)). As such, I do not believe this submission and its duplicates are eligible for an HM reward.

[c4-judge]

alex-ppg changed the severity to QA (Quality Assurance)

[c4-judge]

alex-ppg marked the issue as grade-c

[NishithPat]

@alex-ppg The issue is not just about checking whether the sequencer is online. It is not like the Chainlink issue about stale prices due to sequencer downtime (which has been historically judged as QA).

The issue is about providing grace time for users to adjust their positions to avoid liquidation after sequencer downtime. The impact is quite high because users are prone to liquidations in this case. As the likelihood is low, the issue is of medium severity. Also, note that the sponsor has acknowledged this issue. They recognise the seriousness of the issue.

[c4-judge]

This previously downgraded issue has been upgraded by alex-ppg

[c4-judge]

alex-ppg changed the severity to QA (Quality Assurance)

[alex-ppg]

Hey @NishithPat, thank you for the additional feedback! I understand what the submission entails, and did not mention Chainlink in my response.

It is impossible to reliably detect if there was any sequencer downtime recently, meaning the issue could still manifest if the sequencer went down at timestamp A, liquidations became eligible at timestamp B, and the sequencer came up at timestamp C. There is no way to reliably check if a loan became liquidatable in between sequencer downtimes rendering the recommendation to remain a best practice and thus QA.