PUSH0 - If the pool's total borrow is too high, during harsh market movements, external markets may not have enough liquidity for the resulting mass liquidations.

[sherlock-admin2]

PUSH0

medium

If the pool's total borrow is too high, during harsh market movements, external markets may not have enough liquidity for the resulting mass liquidations.

Summary

There is no upper limit defined for the total deposit/borrow on either the Lending pool or the Tranches.

Liquidations rely on external markets for collateral selling. If a mass liquidation event were to happen, external markets may not be able to handle the sell pressure on time.

Vulnerability Detail

A liquidation involves repaying an underwater account's debt using the process of seizing its collateral, selling the collateral for the debt token, then repay the debt amount, keeping the surplus as a profit. Therefore liquidations are not only dependent on MEVs on standby, but also dependent on external liquidity.

For example, if an account has a position with $1,000,000 in value and, say, $800,000 of debt that is currently underwater. Theoretically the account should be profitably liquidatable.

• However, selling $800,000 at once in any exchange (or even an aggregator) will cause immense price impact, preventing the resulting amount to be enough to cover the debt. A liquidator will also likely liquidate all $1,000,000 to maximize profit.
  • Partial liquidations, while technically possible, may not be enough to bring an account down to healthy limits.
• This effect stacks up if there are multiple accounts liquidatable. 1000 accounts with $10,000 of debt each will generate the same market pressure as one account with $10,000,000. Considering that a typical lending protocol's total deposit/borrow reaches tens or hundreds of millions, the effects of such a market movement scales immensely.

The end result is that, if a lending pool's total borrows/deposits is too high relative to external markets' TVL, then there may not be enough liquidity to handle the immense selling pressure generated by mass liquidation events, preventing effective liquidation.

This is also what happened during the UST crash, liquidations could not happen due to external markets not being able to handle the liquidation pressure.

• During said event, some of the biggest lending protocols also experienced bad debt for this exact reason. It was estimated that Compound incurred $65,710 worth of bad debts, Aave's amount being 2 million. These two protocols took the damage despite never having supported UST in the first place.
• In response to said event, Compound governance created a proposal for capping total borrow amount. Multiple high-quality assets were placed with a borrow cap that was not present before.

We also argue that due to its current design, Arcadia is even more susceptible to this kind of risk, as any liquidations start with an auction, which starting price may be higher than the market price.

• Users may also choose to borrow more in response to the market condition, in the hopes of the external market not recovering enough liquidity on time for their liquidation.
• External liquidity withdraws are also common and to be expected during such a market, further highlighting the impact of this issue.

This may even turn into an arbitrage-based attack where an adversary, with large enough capital, notices the market movement, as well as the market liquidity, and realizes that the market will not be able to handle the liquidation.

• Bob has large ready capital available.
• Bob notices the market movement causing mass liquidations. The liquidations' market pressure has been skewing the AMM liquidity, pushing its pool price away from the market price faster than it can recover.
• Bob determines that, since the lending pool has no cap, he can simply overpower the pool by collateralizing his funds and max borrowing. The market is already in turmoil, and it won't handle his liquidations on time.
  • Note that because of AMM liquidity already being skewed in step (3), borrowing from the pool is now a more profitable option than swapping through AMM.
• Since the market can't handle Bob's liquidation on time before his account becomes insolvent, the lending pool accrues bad debt.

The end result is that Bob has arbitraged from the lending pool, making profits and causing it bad debt.

Note that this supposed "attack" scenario is highly dependent on the market condition, and making the attack itself is a risky decision from Bob (the more capital Bob has, the more likely this attack becomes a success).

However, we have shown that from historical evidences, even immediately-liquidatable-when-unhealthy lending protocols like Compound and Aave have became insolvent due to this exact issue. We also reiterate that if there are many Bobs who make the given attack, then their effect stacks up, and we get a scenario similar to one Bob with large capital.

• This may also cause a domino effect, where if the protocol is already not able to handle liquidations, then anyone can join the arbitrage by borrowing, and thereby worsening the effect. All in all, this may cascade into a complete pool-draining scenario.

For these reasons, we believe this risk justifies a medium severity, due to its high impact, but being dependent on external market conditions.

Impact

If the protocol's total deposit/total borrows becomes too high compared to external markets and readily-available external liquidity, then during harsh market crashes and its resulting mass liquidations, external markets may not be able to handle the immense selling pressure, preventing liquidations and causing bad debt for the protocol.

Code Snippet

The following code lists all storage variables of Lending Pool and Tranche, none of them implements a borrow/deposit upper cap.

https://github.com/sherlock-audit/2023-12-arcadia/blob/main/lending-v2/src/LendingPool.sol#L49-L121

https://github.com/sherlock-audit/2023-12-arcadia/blob/main/lending-v2/src/Tranche.sol#L43-L51

Tool used

Manual Review

Recommendation

Introduce an admin-supplied maximum deposit/borrow for each lending pool, and adjust it accordingly to the external market's conditions and available external liquidity or the chain's TVL. This is also an important risk management parameter for the lending pool.

The protocol has mentioned partnering with Llama risk for risk modelling and simulations. The deposit/borrow values can then be set according to the simulation results during historical market conditions.

[sherlock-admin2]

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

takarez commented:

invalid

[Thomas-Smets]

There is no upper limit defined for the total deposit/borrow on either the Lending pool or the Tranches.

There actually is an implicit maximum that can be borrowed via the combination maxExposure * collateralFactor of all assets allowed by that Creditor. → Creditors can perfectly shield against low liquidity of certain collateralised assets.

Take as example a Creditor that only allows USDC as collateral and it has a collateral factor of 0.9 -> in total maximally 900 worth of assets can be borrowed from the Creditor.

Liquidations rely on external markets for collateral selling. If a mass liquidation event were to happen, external markets may not be able to handle the sell pressure on time.

• Again, the maxExposures should be properly set and are defined per collateral asset per Creditor
• With Partial liquidations liquidations can be done in batches -> total liquidity of the market (and not only the liquidity available on the particular chain) can be used to sell the asset, since arbitrageurs (CEX-DEX and cross-chain) will abritage price differences in between different batches of the partial liquidation.

This may even turn into an arbitrage-based attack where an adversary, with large enough capital, notices the market movement, as well as the market liquidity, and realizes that the market will not be able to handle the liquidation.

Again, the maxExposures are used exactly for this purpose!

[nevillehuang]

Request PoC to facilitate discussion between watson and sponsor.

I agree with sponsors comments, given risk managers are trusted to maintain and adjust exposure values appropriately

[sherlock-admin]

PoC requested from @PUSH0

Requests remaining: 10

[midori-fuse]

Hello. Sorry for the late reply.

We agree with the sponsor and with the decision to close this issue. It was an oversight on our end to have overlooked maxExposure. It is indeed sufficient to effectively manage risk for this protocol.

With this, we would invalidate this issue as well.