# Liquidation reward wrong base accounting

Liquidation or debt math using principal or part where interest-inclusive elastic value is required

_Area: DeFi accounting and math bugs. Seen in 2 disclosed reports; latest 2025-02-17. Updated 2026-10-24._

## How it works
Liquidation and debt math must use one value base everywhere: the full amount owed or repaid, including accrued interest and realized PnL. The bug appears when one step uses principal (or a "part" amount) while another uses the interest-inclusive (elastic) value. The two numbers disagree, and the difference is stranded, miscredited, or used to size the liquidation. The broken assumption is that principal equals total debt, or that a part amount can stand in for an elastic amount.

## Where it shows up
- A bad-debt liquidation that computes `loss = totalDebt - repayAmount` but passes a hardcoded `profit = 0` to the pool, even though the liquidator's repay covers interest beyond principal [E1](https://bugbountylibrary.com/r/c4%3A2024-07-loopfi%3AH-12.md).
- A closing-factor formula using `borrowPart` in the numerator where the elastic amount belongs, and scaling by part decimals that can differ or underflow [E2](https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-24.md).
- A debt view function that drops a term the counterparty protocol includes, e.g. discarding `owedRealizedPnl` from `getPnlAndPendingFee` [E3](https://bugbountylibrary.com/r/sherlock%3A2023-01-uxd%3AM-6.md).
- Any reward or penalty formula mixing part and elastic amounts, or mixing their decimals.

## How to review
Write the post-liquidation solvency equation symbolically and solve for the closing factor, reward and profit; then check the code term by term. The property to confirm: the reward base equals the value actually repaid, and every term of the debt formula matches the source protocol's own settlement-value formula. For E1, trace whether the interest delta is credited as profit when `profit > 0` gates the credit. For E2, confirm part-vs-elastic conversion and decimal scaling are consistent on both sides. For E3, confirm every returned tuple element is consumed.

## Variants seen
- Bad-debt liquidation passes `profit=0`, stranding the interest portion the liquidator paid [E1](https://bugbountylibrary.com/r/c4%3A2024-07-loopfi%3AH-12.md).
- Closing-factor formula uses `borrowPart` instead of elastic amount with mismatched decimals [E2](https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-24.md).
- Debt view omits `owedRealizedPnl`, diverging from the perp venue's settlement value [E3](https://bugbountylibrary.com/r/sherlock%3A2023-01-uxd%3AM-6.md).

## Impact and severity
Medium to high. Liquidators are under-rewarded or the protocol mis-sizes liquidations, leaving bad debt or stranded funds [E1](https://bugbountylibrary.com/r/c4%3A2024-07-loopfi%3AH-12.md)[E2](https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-24.md). Severity rises when the wrong base also drives the closing factor, since that changes how much can be liquidated and can push positions into insolvency [E2](https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-24.md). E3 is a view-only debt misreport, not a liquidation reward, so its impact is limited to misstated debt [E3](https://bugbountylibrary.com/r/sherlock%3A2023-01-uxd%3AM-6.md).

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2024-07-loopfi%3AH-12.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-24.md
- E3: https://bugbountylibrary.com/r/sherlock%3A2023-01-uxd%3AM-6.md