# Liquidation threshold metric mismatch

Liquidation math using the wrong rate, divisor, or share-vs-amount basis, so thresholds disagree

_Area: DeFi oracles, liquidations and flash loans. Seen in 4 disclosed reports; latest 2025-02-21. Updated 2026-10-23._

## How it works
Liquidation logic depends on one number: the threshold that says when a position is unsafe and how much must be closed. The bug is that the code computes that number from a different metric than the one the rest of the protocol enforces. A cached config value, a non-liquidation rate, or a share count gets substituted for the true liquidation threshold. The result is a threshold that is too lenient or too strict, so positions that should be liquidated are skipped, or closing amounts are computed too small to restore solvency.

## Where it shows up
- Two similar parameters (e.g. `collateralizationRate` vs `liquidationCollateralizationRate`) used in sibling formulas [E3](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-5.md).
- A cached max-leverage value used as a divisor while a downstream pool enforces a smaller cap [E1](https://bugbountylibrary.com/r/sherlock%3A2025-02-yieldoor%3AH-4.md).
- A rate or precision constant applied to a share count before conversion to amount [E4](https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-04.md).
- Separate health checks for withdraw and liquidate that value collateral differently (bare vs weighted) [E2](https://bugbountylibrary.com/r/c4%3A2024-02-wise-lending%3AM-04.md).
- Early returns or flags that switch a check to a weaker valuation path [E2](https://bugbountylibrary.com/r/c4%3A2024-02-wise-lending%3AM-04.md).

## How to review
Identify the single authoritative liquidation threshold and confirm every formula that decides solvency or closing size uses it. Check the invariant: the metric in the denominator of the closing-factor and in the solvency check must be the same rate the protocol enforces, and rates must be applied to converted amounts, not shares. Diff sibling functions (`_isSolvent` vs `_computeClosingFactor`, withdraw vs liquidate) and recompute the algebra with default parameters. Where a value is cached, confirm it is the binding constraint, not a looser upstream cap [E1](https://bugbountylibrary.com/r/sherlock%3A2025-02-yieldoor%3AH-4.md).

## Variants seen
- Wrong rate in denominator: closing factor uses collateralization rate instead of liquidation rate, under-computing the close amount [E3](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-5.md).
- Wrong divisor: base uses cached max leverage instead of the pool's smaller effective cap, skipping valid liquidations [E1](https://bugbountylibrary.com/r/sherlock%3A2025-02-yieldoor%3AH-4.md).
- Wrong basis: rate multiplied by share before amount conversion, favoring the borrower [E4](https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-04.md).
- Divergent health checks: withdraw path uses bare collateral while liquidation uses weighted, allowing withdrawal from a liquidatable position [E2](https://bugbountylibrary.com/r/c4%3A2024-02-wise-lending%3AM-04.md).

## Impact and severity
In the evidence this led to valid liquidations being skipped [E1](https://bugbountylibrary.com/r/sherlock%3A2025-02-yieldoor%3AH-4.md), positions remaining liquidatable after partial close [E3](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-5.md), inaccurate thresholds favoring borrowers [E4](https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-04.md), and uncollateralized withdrawals from liquidatable positions [E2](https://bugbountylibrary.com/r/c4%3A2024-02-wise-lending%3AM-04.md). Severity is high where bad debt can accrue; worse when the mismatch is silent and only surfaces under stress.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2025-02-yieldoor%3AH-4.md
- E2: https://bugbountylibrary.com/r/c4%3A2024-02-wise-lending%3AM-04.md
- E3: https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-5.md
- E4: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-04.md