Aave liquidations are triggered below 1: Health Factor Monitoring and Prevention

Published 5 Aug 2026

Aave liquidations are permissionless Aave V3 transactions that repay an unhealthy account's debt after its health factor drops below 1. The liquidator supplies the debt asset and receives the borrower's collateral, including the configured liquidation bonus, while any protocol share comes from that bonus. Prevention is therefore a health-factor problem: track oracle-priced collateral, debt, liquidation thresholds, accrued interest, and the exact market deployment, then repay debt or add collateral before the onchain value crosses the trigger.

They are permissionless debt-repayment events triggered when a borrower's health factor falls below 1, allowing liquidators to claim collateral.

The liquidation boundary leaves no grace period

The health-factor boundary is a hard eligibility check in Aave V3. A liquidation call succeeds only when the health factor computed during execution is below 1; a value of 1 or higher fails that check. No countdown starts at the boundary. Once the account falls below it, a valid permissionless transaction competes for inclusion immediately.

Display rounding creates a quiet monitoring failure. A dashboard rounded to two decimal places could show 1.00 while an onchain value such as 0.999 is already below the trigger. Read the unrounded value when the buffer becomes narrow. The relevant state is the state seen by the Pool contract, not an earlier notification or cached portfolio view.

Three movements press the account toward that line. Collateral loses oracle value, borrowed assets gain oracle value, or variable debt grows through accrued interest. Several can arrive together. A pending repayment does not protect the account until the transaction executes and raises the onchain health factor.

Close factors, bonuses, and the borrower's cost

Aave V3 close-factor logic controls how much debt one liquidation repays. For a position above 0.95 but below 1, with both the selected collateral and selected debt values at least $2,000, the default maximum is 50% of total debt. At 0.95 or lower, or when either selected value is below $2,000, the maximum rises to 100%, still limited by available collateral and the chosen debt reserve.

Partial settlement also follows a dust rule. If a transaction clears neither the selected debt nor the selected collateral, at least $1,000 of each must remain in base-currency value. Otherwise, the transaction must clear one side. The $2,000 and $1,000 constants assume an 8-decimal USD base unit in USD-denominated pools.

The liquidation bonus is configured for the collateral reserve or the applicable eMode category. It is not one protocol-wide percentage. The borrower gives up oracle-equivalent collateral for the repaid debt plus that bonus. A configured protocol fee applies only to the bonus portion, while the liquidator separately pays network gas. The exact collateral removed therefore follows the debt amount, both oracle prices, token decimals, bonus, and protocol-fee setting. For the closely linked subject, see Aave notes.

Which inputs move the Aave health factor?

The Aave health factor equals total collateral value multiplied by its weighted average liquidation threshold, divided by total borrow value. Collateral weights reflect each asset's share of total collateral value. Debt sits entirely in the denominator. An oracle move in either direction changes the ratio even when token balances remain untouched.

Liquidation threshold and loan-to-value ratio serve different jobs. The loan-to-value ratio limits borrowing capacity, while the liquidation threshold enters the health-factor calculation. Aave percentage parameters use 10,000 units for 100.00%, giving two decimal places of percentage precision. The Pool returns health factor in 18-decimal wad precision, where 10^18 represents 1.

By contrast, Aave Governance sets reserve and eMode parameters. The configured Aave oracle supplies the common valuation base through sources such as Chainlink. Assets including WETH, wstETH, USDC, and GHO therefore affect one account through balances, prices, and their applicable thresholds. Isolation Mode changes permitted debt and caps, but it does not replace the health-factor boundary.

From oracle price to LiquidationCall

The Aave Pool executes LiquidationCall as one atomic transaction. Its function takes five arguments: collateral asset, debt asset, borrower, debt amount to cover, and a boolean selecting aTokens or underlying collateral. Every check and transfer either completes together or reverts together.

1. The Pool updates the debt and collateral reserve indexes, calculates account data, and validates a health factor below 1.
2. The liquidation logic reads the applicable bonus and both oracle prices, then applies close-factor and dust constraints.
3. The borrower's variable debt tokens are burned for the settled amount, and collateral aTokens are transferred or burned.
4. The debt asset moves from the liquidator to the reserve's aToken contract; any configured protocol share moves to the treasury.
5. The Pool emits LiquidationCall after settlement, recording the actual debt covered and collateral removed.

The event contains seven fields, including three indexed addresses: collateral asset, debt asset, and borrower. It also records the liquidator and the receiveAToken boolean. That boolean creates two settlement forms. True delivers aTokens; false delivers the underlying collateral. Event data confirms what settled, while a fresh account read shows the remaining position.

A worked health-factor stress test

A health-factor stress test converts a price scenario into an action amount. Every changing input here is hypothetical: collateral value is $10,000, the weighted liquidation threshold is 80%, debt is $7,500, the collateral price shock is an 8% decline, and the desired post-action health factor is 1.20. Assume the debt balance and threshold stay unchanged during the calculation.

The initial health factor is ($10,000 × 0.80) ÷ $7,500, or 1.0667. After the hypothetical 8% fall, collateral is worth $9,200. The health factor becomes ($9,200 × 0.80) ÷ $7,500, or 0.9813, which is below the liquidation boundary. To reach the hypothetical 1.20 target by repayment, debt must fall to $7,360 ÷ 1.20, or $6,133.33. The concrete repayment result is $1,366.67, before gas and any later state change.

Monitoring the position across contracts and chains

Monitoring Aave liquidations starts with the Pool's getUserAccountData read. It returns six values: total collateral, total debt, available borrowing capacity, current liquidation threshold, loan-to-value ratio, and health factor. Pair that account snapshot with reserve configuration and oracle reads. A health factor alone explains proximity, but the underlying values explain the movement.

Raw token units matter in custom alerts and repayment preparation. Native USDC uses 6 decimals, while GHO, WETH, and wstETH use 18. Converting every balance with one assumed precision produces false values. A monitor should key each account by a 20-byte EVM address, chain ID, and the correct Pool address.

Ethereum, Arbitrum, and Base hold separate Aave market state. One wallet address therefore has separate health factors across deployments. The Aave Labs interface offers a visual account view, and DeFi Saver adds monitoring and automation features. Contract reads remain the execution-level check. Track configuration changes, oracle-priced balances, interest growth, submitted prevention transactions, and confirmed LiquidationCall events without merging chains into one ratio.

Choosing a prevention buffer before volatility arrives

A liquidation-prevention buffer is the distance between the account's health factor and 1. Aave Governance does not define one universal safe value above that boundary. The required distance follows collateral volatility, collateral-to-debt correlation, interest growth, transaction inclusion time, and the speed at which the borrower can act.

Two direct actions improve the formula. Repaying debt reduces the denominator; adding eligible collateral raises the threshold-adjusted numerator. An asset contributes only when it is enabled as collateral and has a positive liquidation threshold. Borrowing more or withdrawing collateral moves the ratio the other way, so re-read account data after either action.

Set an alert above the level at which action must begin, then size the buffer with a price stress rather than a favorite round number. Automation through DeFi Saver adds dependencies on configured triggers, transaction execution, and swap liquidity. A wider onchain buffer reduces reliance on those dependencies. The account remains outside liquidation only while its computed health factor stays at 1 or higher.