<!-- canonical: https://0xsimao.com/findings/yieldoor-leverager-liquidateable-leverage-smaller -->

# Base calculation in `Leverager::isLiquidateable()` is incorrect as the max leverage may be smaller

Crit/High · Sherlock · CLMM · 24th February 2025

Finding H-4 of the Yieldoor competition.

- Protocol: https://audits.sherlock.xyz/contests/791
- Report: /reports/yieldoor
- Codebase: https://github.com/0xsimao/2025-02-yieldoor/tree/b5a0f779dce4236b02665606adb610099451a51a
- Source: https://github.com/sherlock-audit/2025-02-yieldoor-judging/issues/158

---

### Summary

Base calculation in `Leverager::isLiquidateable()` is:
`uint256 base = owedAmount * 1e18 / (vp.maxTimesLeverage - 1e18);`.
However, the max leverage may not actually be `vp.maxTimesLeverage`, but [be](https://github.com/sherlock-audit/2025-02-yieldoor/blob/main/yieldoor/src/Leverager.sol#L467) `maxLevTimes` from the lending pool. In this case, the base amount would be incorrectly underestimated, leading to users not being liquidated when they should for the protocol's loss (loss of profit and higher bad debt risk).

### Root Cause

In `Leverager:408`, the max leverage from the lending pool is not taken into account.

### Internal Pre-conditions

`maxLevTimes` from the lending pool < `vp.maxTimesLeverage`.

### External Pre-conditions

None.

### Attack Path

1. User has a position that should be liquidated but isn't due to the rhs of the is liquidatable check.

### Impact

Protocols takes losses and risks bad debt creation.

### PoC

If `maxLevTimes` < `vp.maxTimesLeverage`, it means the base calculation would have in the divisor a bigger number than it should, so base will be smaller. As base is smaller, the collateral of the user can decrease more without the user being liquidated.

### Mitigation

Compare the 2 max leverage values and use the smallest, which is the actual maximum leverage allowed in the `Leverager`.

---

Related findings:

- [OstiumPairsStorage::getAllPairsMaxLeverage() reverts if enough pairs are created](https://0xsimao.com/findings/ostium-pairs-storage-reverts-created): Ostium
- [`ManagedLeveragedVault::getAvailableDebt()` used in `ManagedLeveragedVault::increaseLeverage()` is incorrect](https://0xsimao.com/findings/beraborrow-i-available-debt-increase-leverage): Beraborrow Managed Dens
- [Error in OstiumPairsStorage::groupMaxCollateral() calculation](https://0xsimao.com/findings/ostium-pairs-storage-group-collateral): Ostium
- [Taker fee is underestimated due to incorrect fee calculation](https://0xsimao.com/findings/1inch-taker-fee-underestimated-calculation): 1inch Fee Extension
