No grace period applied which would then allow positions to be liquidated after sequencer goes down since now users don't have enough time to deposit funds

[c4-bot-6]

Lines of code

https://github.com/code-423n4/2024-03-revert-lend/blob/457230945a49878eefdc1001796b10638c1e7584/src/V3Vault.sol#L685-L758

Vulnerability details

Proof of Concept

Take a look at https://github.com/code-423n4/2024-03-revert-lend/blob/457230945a49878eefdc1001796b10638c1e7584/src/V3Vault.sol#L685-L758

One can see that this function is used ot liquidate a position with having a healthy check to ensure that positions being liquidated are actually the ones that are not afloat, i.e

        (state.isHealthy, state.fullValue, state.collateralValue, state.feeValue) =
            _checkLoanIsHealthy(params.tokenId, state.debt);
        if (state.isHealthy) {
            revert NotLiquidatable();
        }

Problem is that protocol have clearly stated that they would deploy to any EVM compatible chain which include differwnt L2s, but no sequencer checks are present in protocol, this leads to a scenario where if the sequencer ever goes down and comes back up users wouldn't have enough time to get their positions back afloat since all price updates would be immediately consumed after the sequencer comes back up (note that while the sequencer is down users can't deposit in more capital), this now causes their positions to be immediately unfairly liquidatable.

Impact

Users would be unfairly liquidated since they do not have enough ample time to return their positions back afloat after the sequencer goes off.

Recommended Mitigation Steps

Introduce L2 sequencer checks and provide a grace period for users if the sequencer ever goes down to keep their positions afloat.

Assessed type

Context

[c4-pre-sort]

0xEVom marked the issue as insufficient quality report

[0xEVom]

Users could deposit more funds via delayed Inbox

[jhsagd76]

There are already issues related to the L2 oracle restart. I am inclined to mark this issue as QA-N for sponsor reference only.

If the user truly requires a grace period, they should send an L2 deposit message directly on L1 to request an adjustment of their position.

[c4-judge]

jhsagd76 changed the severity to QA (Quality Assurance)

[jhsagd76]

N

[Bauchibred]

Hi @jhsagd76, thanks for judging, however we think this issue has been misunderstood, this is somewhat similar to the popular “depositing can be paused and liquidations can not be paused” or "depositing/liquidations can be paused but on an unpause a user does not necessarily have the upper hand over the liquidator so they could get unfairly liquidated" which historically have been judged as medium.



Also about the idea of directly communicating with the L2 networks via L1 contracts, not only is this inconvenient to users only a few users really use it. Now using the Arbitrum L2 as a case study, i.e the suggestion of using a delayed inbox, this suggestion even worsens the case as a liquidator can just wait till the sequencer comes back up and just call liquidate having the upper hand, this is cause if the user’s transactions are passed via the delayed inbox, the sequencer only includes the message from the inbox after a delay of 10 minutes (if not more), so within this timeframe a liquidator can just pass their transaction directly via the sequencer and get their transactions executed, now this would be profitable for juicy liquidatable positions as they (the liquidators) can just be watching it’s liquidatable state.

[jhsagd76]

This issue contradicts the precedent you mentioned in some ways.

1. L2 down. The deposit(repay)/ liquidation are all suspended
2. liquidator can't send message on L1 until the L2 oracle revives( they can send,but will revert).
3. Borrow can always repay from L1 or as soon as L2 revives, before liquidator.

Overall, we do not have a technical disagreement, but I do not agree with the risk level assessment.

[jhsagd76]

L-A
selected for report #128

[Bauchibred]

Thanks for taking the time to go through the comments and the report once again @jhsagd76.

1. L2 down. The deposit(repay)/ liquidation are all suspended

Exactly, whenever L2 comes back up, price updates are processed making some positions immediately underwater.

2. liquidator can't send message on L1 until the L2 oracle revives( they can send,but will revert).

We are all saying the same thing, if they can send the messages and it always "reverts" , this means they can't send the messages, no?

3. Borrow can always repay from L1 or as soon as L2 revives, before liquidator.

How can we assure this is always the case? This is the whole point of the report, allowing them a grace period after the L2 comes back up "ensures this", i.e they have the upperhand over the liquidator, if we can currently ensure this without a grace period, then this submission should be plain invalid and not even QA, no?