Aave and lending risk, explained: how loans get liquidated

At a glance

• Aave is a lending protocol where borrowers post more collateral than they borrow; this page describes Aave v3 [1][4].
• A loan's health factor compares weighted collateral with debt; below 1, the position can be liquidated [1][3].
• Each collateral asset's liquidation threshold is "set by Aave Governance," per Aave's help center [1].
• In v3's code, up to 50% of a debt can be liquidated at once, or all of it below a 0.95 health factor [2].
• Anyone can liquidate an eligible position, repaying debt in exchange for collateral plus a bonus [1].

1. What it is

A shared pool

Aave pools the assets that users supply. Borrowers draw from that pool against collateral they have supplied. There is no single lender on the other side of a loan; the rules in Aave's smart contracts decide when a borrower can borrow and when a loan is closed out.

Analogy, not the mechanism itself: it is a pawnshop run by a vending machine. You leave something worth more than you take, and the machine sells your item if its value falls too far.

Over-collateralized by design

Aave loans are backed by more collateral than the amount borrowed. Aave's help center describes this as maintaining "overcollateralised borrow positions" [1]. The safety margin is what protects the pool if collateral prices fall.

Which version this page covers

This page describes Aave v3. Its design is set out in the Aave V3 Technical Paper of Jan. 27, 2022 [4], and its current code is maintained in the aave-v3-origin repository, whose README calls it the "Aave v3.7 complete codebase" [5]. Liquidation figures below come from that code [2].

Governance sets the dials

Many of the numbers that decide a loan's safety are chosen by Aave Governance, not fixed in code. The help center says the liquidation threshold is "set by Aave Governance for each collateral asset" [1]. The technical paper describes caps, isolation listings and efficiency categories that governance configures [4].

2. How it works

The health factor

Aave's help center gives the formula [1]:

Health Factor = (Total Collateral Value × Weighted Average Liquidation Threshold) / Total Borrow Value

The help center describes a health factor "below 1 signaling the risk of liquidation" [1]. In v3's code, the liquidation line is the constant HEALTH_FACTOR_LIQUIDATION_THRESHOLD, set to 1 [3].

A worked example

The help center's own example: supply $10,000 of ETH with an 80% liquidation threshold, borrow $6,000 of GHO, and "your health factor would be 1.333" [1]. That is $10,000 × 0.8, or $8,000, divided by $6,000. The figures are illustrative, not market data.

Analogy, not the mechanism itself: the health factor is a fuel gauge. Above 1 you are still driving; at 1 the engine can be shut off by anyone who notices.

Borrowing power vs liquidation line

V3 splits two settings that older lending protocols often merged. The technical paper says LTV, or loan-to-value, "defines the borrowing power for new borrows," while the liquidation threshold defines "the collateral/debt ratio at which the position is considered undercollateralized and therefore subjected to liquidation" [4]. The gap between them is a borrower's buffer.

How much can be liquidated

In the code, the 50% figure is DEFAULT_LIQUIDATION_CLOSE_FACTOR, the 0.95 line is CLOSE_FACTOR_HF_THRESHOLD, and the $2,000 line is MIN_BASE_MAX_CLOSE_FACTOR_THRESHOLD; the $1,000 leftover is set at half of it [2]. A code comment says the leftover rule ensures "liquidators don't optimize gas by leaving some wei on the liquidation" [2]. Wei is the smallest unit of ether; the rule stops tiny, unprofitable remainders being left behind.

Who liquidates, and why

"Liquidations are permissionless, meaning any network participant can initiate the process," the help center says [1]. The liquidator "repays debt on behalf of the borrower and receives an equivalent value plus a liquidation bonus from the borrower's collateral" [1]. That bonus is the incentive. Liquidators "quickly react to changes in oracle prices, collateral balances, and protocol parameters," often with automated bots [1].

Prices come from oracles

A health factor depends on prices, and the contracts read those prices from oracles, services that bring outside market prices onto the blockchain. The help center ties liquidations to "changes in oracle prices" [1]. If an oracle reports a lower price for collateral, health factors fall, whether or not the borrower has done anything.

3. What changed

Efficiency Mode (v3)

The technical paper says High Efficiency Mode, or E-Mode, "allows borrowers to extract the highest borrowing power out of their collateral" [4]. Assets are grouped into categories, each with its own LTV, liquidation threshold, liquidation bonus and an optional custom price oracle [4]. Borrowers who stay within one category get that category's settings.

Why it mattered: assets that move together, such as stablecoins, can be borrowed against each other with a thinner margin.

Isolation Mode (v3)

V3 "introduces Isolation Mode, inspired by the MakerDAO approach for exposure management" [4]. Governance can list an asset as "isolated." A borrower using it as collateral "cannot supply other assets as collateral," and can borrow only governance-approved stablecoins "up to a specified debt ceiling" [4].

Why it mattered: a new or riskier asset can be listed without exposing the whole pool's liquidity to it.

Supply and borrow caps (v3)

"Aave governance can now configure Borrow Caps and Supply Caps," the paper says [4]. Supply caps help in "reducing exposure to a certain asset" and mitigate "risks such as infinite minting or price oracle manipulation" [4].

Two separate limits (v3)

The paper presents the LTV and liquidation threshold split as a v3 design choice that lets governance cut an asset's borrowing power "while avoiding impacting existing users" [4].

Why it mattered: governance can make new borrowing harder without pushing existing loans into liquidation.

Liquidation sizing (v3 code)

The 50%, 0.95, $2,000 and $1,000 rules in section 2 are in the current v3 code [2]. Earlier v3 releases may have differed; this page describes the code at the cited commit.

Aave v4, per its own docs

Aave has published developer documentation for a v4. Its liquidations page says: "In Aave v4, liquidation bonuses follow a Dutch auction where lower health factors result in higher liquidation bonuses" [6]. In that design, the liquidator's reward grows as a loan gets less healthy. This page does not describe v4 further.

4. What is open

No universally safe level

The help center says "there is no universally 'safe' health factor, as this depends on the volatility and correlation of your assets" [1]. A borrower who picks a buffer is making a judgment about how far prices can move.

Price drops and liquidation

When collateral falls in value, "your health factor drops, heightening the risk of liquidation" [1]. A fast drop can push a position from safe to liquidatable before its owner can add collateral or repay.

Oracle dependence

Aave's contracts act on the prices their oracles report [1][4]. An oracle that is wrong, late or manipulated changes health factors for everyone using that price. Supply caps are one stated defense against oracle manipulation [4].

Governance choices

Thresholds, caps, isolation listings and E-Mode categories are governance decisions [1][4]. A change to any of them changes the risk of positions already open.

Liquidation competition

The help center calls liquidations "highly competitive" [1]. In Le Coin's view, the pool relies on that competition: if no one liquidates a failing position in time, the pool can be left with debt its collateral no longer covers.

What this page leaves out

By Learning Hub policy, this dive carries no price, market value, total-value-locked or usage figures. It does not name the oracle provider for each asset, describe Aave's governance process step by step, or cover Aave v4 beyond the one quoted line.

Not financial advice.