Skip to content

Research notes

Aave V3 Close Factor vs Liquidation Bonus

A pinned Aave V3 example repays two thirds of one debt under a 50% account-wide ceiling, then checks the bonus split and a separate dust rejection.

Ivory ceramic scoop lifts rounded blocks from a matching tray, with a lime wedge on its rim against black.
Illustration for research notes; examples in this article are educational.

In Aave V3, the close factor limits debt repayable in one liquidation, while the liquidation bonus sets the extra collateral exchanged for that repayment. They use different bases: the close factor constrains debt; the bonus applies to its collateral equivalent. Actual repayment also depends on the selected debt, available collateral and leftover-balance rules.

A “50% close factor and 8% bonus” therefore does not mean taking 58% of the collateral. Work through the repayment ceiling first, translate the accepted repayment into collateral, then check the fee split and what remains.

This article follows the EVM implementation of Aave V3 Origin 3.7 at commit cff15de, inspected on 28 October 2026. Applying it to a real account requires checking that pool's deployed implementation and parameters at the relevant block.

Give each control its own job

Aave's V3 overview describes liquidation eligibility when health factor falls below 1. Eligibility alone does not establish how much a particular transaction will repay.

ControlQuestion it answersRelevant base
Liquidation thresholdIs collateral support sufficient?Eligible collateral value
Close factorHow much debt may this call cover?Debt value under the applicable branch
Liquidation bonusHow much extra collateral accompanies repayment?Collateral equivalent of debt repaid
Liquidation protocol feeHow is the bonus divided?Bonus collateral

The distinction between LTV and liquidation threshold belongs before this calculation. Once eligibility is established, the close factor and bonus determine different parts of the settlement.

The selected revision uses an account-wide denominator for the default debt ceiling. That redesign dates to V3.3: it replaced the earlier per-reserve application of the default fraction. The V3.3 feature specification explains the change. “Half the debt” needs an explicit answer to “which debt?”

Select the branch before calculating collateral

In the pinned V3 liquidation logic, the initial ceiling is the entire selected debt balance. The default cap applies only when both selected reserve values are at least $2,000 and health factor is strictly greater than 0.95.

The $2,000 size boundary and $1,000 leftover minimum come from constants that assume an eight-decimal USD oracle base. For a pool using another base, check its implementation's adjusted constants before interpreting these amounts.

Account and selected reservesInitial repayment ceiling
Health factor at or below 0.95Entire selected debt
Selected collateral or selected debt below $2,000Entire selected debt
Otherwise, with health factor below 1Smaller of selected debt and 50% of total account debt value, converted into the selected debt token

The caller may request less. Available collateral can reduce repayment further, and the dust check can reject a candidate. A 100% ceiling permits coverage of the selected debt; it does not require repayment of every asset in the account.

Equality matters: health factor exactly 0.95 bypasses the default cap; selected reserve values exactly $2,000 satisfy the size conditions. Use full precision rather than a rounded dashboard label.

An illustrative call that repays two thirds of one debt

Consider a constructed account with invented tokens C, D and E. Every price, balance, threshold and fee below is a teaching assumption, not a live reserve configuration.

The borrower has 145.5 C at $100 each, 9,000 D of debt at $1 each, and 3,000 E of debt at $1 each. C is the only collateral, with an 80% liquidation threshold. Ordinary mode applies. Set the gross liquidation bonus to 8% and the protocol's share of that bonus to 15%. The bonus multiplier is 1.08: in the code's percentage units, 10,800 represents 108% of base collateral.

Assume current accrued balances, sufficient D spending allowance and no other restriction. The liquidator requests underlying C rather than aTokens; assume enough C is available for that delivery. Let C have 18 decimals, D and E six decimals, and relevant supply and debt indices equal one at this illustrative snapshot. The scaled-balance explanation shows why real indexed balances need another conversion.

The starting health factor is ($14,550 × 80%) ÷ $12,000 = 0.97. Liquidation is eligible. Both selected reserve values exceed $2,000, so the default branch applies.

The liquidator selects D debt and C collateral, requesting repayment of 7,000 D. Half the total $12,000 debt is $6,000. With D at $1, the cap reduces the requested repayment to 6,000 D. That is two thirds of D's 9,000-token balance. Applying 50% only to D would incorrectly produce 4,500 D.

The collateral equivalent is 60 C. Adding 8% gives 64.8 C removed from the borrower's supply claim. The bonus portion is 4.8 C, and its 15% protocol allocation is 0.72 C. The liquidator receives 64.08 C of underlying. The protocol receives aTokens representing 0.72 C at the assumed index, through the pinned treasury-transfer path.

ComponentQuantityValue at assumed prices
Requested debt coverage7,000 D$7,000
Actual debt repaid6,000 D$6,000
Collateral equivalent of repayment60 C$6,000
Gross extra collateral4.8 C$480
Total borrower collateral reduction64.8 C$6,480
Treasury aToken allocation0.72 C equivalent$72
Liquidator allocation64.08 C$6,408

The transfer identity in C-equivalent units is 64.8 C = 64.08 C + 0.72 C. The $72 allocation is already inside the $480 gross bonus; adding it again would overstate the borrower's penalty. The liquidator's $408 valuation uplift is 6.8% of repayment before gas, financing and disposal costs. The bonus-versus-penalty ledger explains why that uplift does not establish profit.

The account retains 80.7 C worth $8,070, 3,000 D debt and 3,000 E debt. The selected collateral and selected D debt both remain above $1,000, so this candidate passes the leftover check. At unchanged inputs, health factor becomes ($8,070 × 80%) ÷ $6,000 = 1.076.

That outcome is calculated, not promised by the default close factor. Another collateral threshold, bonus or price snapshot can produce a different remaining health factor.

A repayment below the ceiling can still fail

The V3.3 cleanup specification explains the separate leftover rule. In the pinned revision, when neither selected debt nor selected collateral is fully cleared, both remaining values must be at least $1,000. A failed check reverts the call; it does not automatically enlarge the requested repayment.

Use a second, independent illustrative account: 23.0375 C worth $2,303.75, a single 1,900 D debt, and the same prices, 80% threshold and 8% bonus. Its health factor is also 0.97. Since selected debt is below $2,000, the initial ceiling permits all 1,900 D.

Each row starts from that account afresh. Collateral reduction includes the protocol allocation; splitting it between recipients does not change the amount left for the borrower.

Requested repaymentGross C reductionDebt leftCollateral value leftLeftover check
900 D9.72 C$1,000$1,331.75Passes: both meet minimum
1,000 D10.8 C$900$1,223.75Reverts: debt below minimum
1,900 D20.52 C$0$251.75Passes: selected debt cleared

Repaying more can therefore turn a permissible partial candidate into a rejected one before full repayment becomes permissible. The middle row describes rejected candidate balances. After its revert, the liquidation has not changed the starting balances.

In the last row, $251.75 of collateral may remain because the selected debt is fully cleared. The minimum is conditional, rather than a universal ban on every balance below $1,000.

Resolve amounts that diverge from an estimate

The selected collateral is insufficient. A debt ceiling does not prove enough collateral exists to deliver the corresponding bonus. The implementation can consume the available collateral and recalculate the debt needed. Reconcile the executed amount rather than copying the request into the repayment ledger.

The fee base is wrong. With an 8% gross bonus and 15% protocol share, the protocol allocation in the main example is 1.2% of repayment value. It is not 15% of the $6,480 collateral reduction.

Small-unit rounding differs. V3.7's rounding specification documents floor rounding for gross collateral multiplication and the base portion used to derive bonus collateral, plus ceiling rounding for the protocol fee. Real indices introduce further conversions. The constructed examples divide exactly under the stated units; a real account may not.

Delivery is mistaken for redemption. The liquidator can receive aTokens or underlying collateral. Identify which asset actually arrived. The withdrawal-liquidity and headroom guide separates an account's collateral permission from available underlying liquidity.

V4 guidance is applied to V3. Current V4 liquidation documentation describes bonuses that rise as health factor falls. Aave Labs' V4 engine explanation also describes a target health factor. Those mechanisms are separate from the pinned V3 branches used here.

Reconstruct one call with a compact worksheet

For a real transaction, preserve the chain, pool, implementation, borrower, block and transaction hash. Read prices and configuration from the relevant execution state, including the effective bonus when a special mode applies.

FieldWhat to preserve
EligibilityFull-precision health factor and active rules
Debt capTotal account debt, selected debt value and branch
RequestSelected assets and caller's requested amount
SettlementActual repayment and gross collateral reduction
SplitLiquidator allocation plus treasury allocation
ResidualsSelected remaining debt and collateral; pass or revert
Account resultAll remaining balances and recomputed health factor

In the pinned source, LiquidationCall reports the liquidator's collateral allocation, while the protocol allocation moves separately to the treasury as aTokens. Treating that event field as the whole borrower reduction omits the fee. Check corresponding token movements and scaled balances for exact reconciliation.

A complete record should answer three separate questions: what limited repayment, how the accepted repayment became collateral, and why the remaining position passed validation. Keep those answers separate, and the close factor and liquidation bonus become reproducible amounts instead of percentages added to the wrong base.

Keep the context with the example.

Each worked example is illustrative, with its sources and assumptions in the article. Read our editorial standards for authorship, verification and corrections.