What is Liquidation Threshold?

Introduction

liquidation threshold is the risk boundary a DeFi lending protocol uses to decide when a loan has become unsafe enough to liquidate. If that sounds like just another percentage in a settings table, it helps to start from the underlying problem: a lending protocol lets you borrow against volatile assets, but it cannot call you, negotiate new terms, or send a margin clerk when markets move. The contract needs a hard rule for when collateral still counts as sufficient and when it no longer does.

That rule is the liquidation threshold. It is what turns a floating market value into an on-chain decision. Above the threshold, your position is considered adequately collateralized. Below it, the protocol is allowed to force repayment by selling or seizing collateral through its liquidation mechanism. In practice, this is one of the most important numbers in DeFi credit markets because it determines both how much you can safely borrow and how close you are to losing collateral during volatility.

The key idea is simple: lending protocols need a buffer between borrowing capacity and liquidation. That buffer absorbs ordinary price movement. Without it, a position opened within the allowed borrow limit could become liquidatable immediately from tiny market noise, rounding, or fees. Once you see liquidation threshold as a buffer rather than just a cap, the rest of the design starts to make sense.

How is a liquidation threshold different from the maximum borrow limit (LTV)?

A collateralized loan always depends on a comparison between two moving values: the market value of the collateral and the value of the debt. The collateral can fall, the debt can grow from interest, and the protocol has to keep lenders protected if the borrower stops being sufficiently backed. So the protocol defines a boundary: if debt rises too close to the effective value of the collateral, the position becomes eligible for liquidation.

What matters here is that the liquidation threshold is not always the same thing as the maximum initial borrow amount. Many protocols separate these concepts. A borrower may be allowed to open a position up to some loan-to-value ratio, often called LTV or a borrow collateral factor, while liquidation happens only at a stricter boundary later. Aave documents this explicitly: each collateral asset has a governance-set liquidation threshold, and a position’s health depends on collateral value times a weighted average liquidation threshold relative to debt. Compound III similarly distinguishes borrow collateral factors from liquidation collateral factors, with the liquidation factors set to provide a buffer beyond initial borrowing capacity.

That separation solves a concrete mechanical problem. If the “you may borrow this much” line and the “you may be liquidated now” line were identical, then any slight adverse price move could flip a new loan directly into liquidation. Aave’s smart-contract configuration for collateral enforces a related invariant: ltv <= liquidationThreshold, with the comment that otherwise borrowing against the asset would cause instantaneous liquidation. That is the protocol expressing the buffer in code.

So the liquidation threshold should be understood as the point where the protocol stops treating collateral at face value for solvency purposes. It is not there to maximize borrowing. It is there to protect the system against the reality that crypto collateral is volatile, prices are observed through oracles, and liquidations themselves are costly and competitive.

How can you visualize liquidation thresholds and account health?

A useful way to picture a lending position is as a bridge with a weight limit and a collapse point. The weight limit is the amount of debt the protocol is willing to let you put on the bridge when conditions are normal. The collapse point is farther out: it is the point at which the bridge is no longer safe and emergency action has to happen.

This analogy explains why protocols have both an initial borrowing parameter and a liquidation threshold. The protocol does not want you driving right up to structural failure the moment you enter the bridge. It wants room for wind, vibration, and estimation error. In DeFi, those disturbances are price volatility, interest accrual, oracle lag, and transaction-ordering races.

Where the analogy fails is that a bridge’s collapse point is a physical fact, while a liquidation threshold is a governance and modeling choice. Protocols choose it based on asset risk, liquidity, correlation, oracle quality, and liquidator behavior. There is no universal “correct” threshold outside those assumptions.

How do lending protocols compute liquidation thresholds and health factors?

The mechanism becomes clearer with the simplest nontrivial example. Imagine you deposit collateral worth $1,000 and borrow $700 of a stablecoin. If the protocol’s liquidation threshold for that collateral is 80%, the collateral is treated as supporting debt up to an effective safety boundary of $800. At the moment you borrow $700, you are below that boundary, so the position is healthy. If the collateral later falls from $1,000 to $850 while the debt stays near $700, the effective boundary becomes $680, which is now below the debt. The loan has crossed into liquidatable territory.

This is the basic structure even when different protocols present it with different labels. Some describe a required collateral ratio, some use account liquidity or shortfall, and some expose a health metric that collapses the comparison into a single number. The underlying invariant is the same: liquidation eligibility starts when discounted collateral value is no longer enough to cover debt.

Aave makes this explicit with its Health Factor, defined as:

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

Here, a health factor above 1 means the position is safe by the protocol’s rules. Below 1, the position becomes eligible for liquidation. The phrase weighted average liquidation threshold matters because many users post more than one collateral asset. The protocol then combines the asset-specific thresholds into one effective boundary for the whole account. The supplied material does not specify the exact weighting formula, but the purpose is clear: a basket of safer and riskier assets should not inherit one single asset’s threshold unchanged.

Compound v2 expresses the same idea differently. The Comptroller computes account liquidity by taking the supplied balances in each entered market, multiplying by the market’s collateral factor, and subtracting borrowed balances. A nonzero shortfall means the account is below its collateral requirement and can be liquidated. The docs do not use the term liquidation threshold in the same way Aave does, but economically the role is the same: there is a protocol-defined boundary on how much debt the collateral may support.

Maker uses the term liquidation ratio instead of liquidation threshold. For each collateral type, governance sets a ratio such as 150%, meaning the collateral value must remain at least 1.5 times the debt to avoid liquidation. That sounds inverted relative to an 80% threshold, but it is the same idea expressed from the other side. A 150% liquidation ratio corresponds to debt being at most two-thirds of collateral value.

Why do protocols set different liquidation thresholds for each collateral asset?

The reason thresholds differ by asset is that not all collateral fails the same way. A large liquid asset with deep markets, broad price discovery, and relatively stable oracle coverage can usually support more borrowing than a thinly traded token whose price can gap or be manipulated. The threshold is where the protocol encodes that judgment.

Aave states directly that the liquidation threshold is set per collateral asset by governance. Maker does the same with liquidation ratios per vault type. Compound III uses governance-set liquidation collateral factors. The repeated pattern across protocols is important: the threshold is a risk parameter, not a law of nature.

Here is the mechanism behind that choice. If an asset is volatile or hard to liquidate, the protocol needs a larger cushion so that when the position crosses into danger, there is still enough value left for liquidators or auctions to recover debt. If governance set a threshold too aggressively, a fast downward move could leave the protocol undercollateralized before liquidators can act. If governance set it too conservatively, borrowing becomes unnecessarily capital-inefficient and users stop using that asset as collateral.

This is also why protocols care about more than volatility in the narrow statistical sense. Liquidity matters because collateral must actually be sold or absorbed. Correlation matters because if many users borrow stablecoins against the same falling asset, liquidations arrive together. Oracle design matters because the threshold is only as sound as the price used to evaluate it.

Chainlink’s discussion of market manipulation versus oracle exploits makes the dependency stark. Even if a liquidation engine is implemented correctly, a misreported or manipulable price can push an account across the liquidation threshold unfairly. Paradigm’s oracle design guide pushes the same point further: if a protocol reads a manipulable on-chain spot price in the middle of a transaction, it can approve bad borrowing or trigger harmful liquidations. So the liquidation threshold is never just a credit parameter. It is a credit parameter coupled to a pricing system.

What happens when a loan crosses the liquidation threshold?

Crossing the liquidation threshold does not by itself repay debt. It changes the set of actions the protocol now permits. At that point, third parties can usually step in and perform liquidation according to protocol rules.

In Aave, when health factor falls below 1, a liquidation can occur. The liquidator repays debt on behalf of the borrower and receives equivalent collateral plus a liquidation bonus. That bonus is the incentive that turns protocol safety into an open market function. Aave’s help page also shows that liquidation need not always be all-or-nothing: depending on health factor and position size, only part of the debt may be liquidated, while deeper distress or smaller positions can allow full liquidation.

Compound v2 uses a related but differently structured mechanism. Once an account has shortfall, a liquidator can repay part of a borrowed asset and seize collateral, subject to the close factor, which limits how much of a single borrowed asset can be repaid in one liquidation transaction. The liquidator receives extra collateral through the liquidation incentive. Here the threshold decides eligibility, while the close factor and incentive shape how liquidation unfolds.

Compound III changes the flow more substantially. Any address can call absorb on underwater accounts. The protocol itself takes on the debt using its base-asset reserves and receives the collateral. If reserves drop below a target, anyone can later buy that collateral from the protocol at a discount. The threshold still determines when an account is unsafe, but the immediate counterparty is the protocol rather than a direct debt-repaying liquidator.

Maker again uses a different enforcement path. When a vault falls below its liquidation ratio, the system takes the collateral and starts an auction to raise DAI to cover debt plus a liquidation penalty. In Liquidation 2.0, the protocol takes all of the vault’s debt at liquidation time and sells collateral through Dutch auctions, even though auction participants can purchase collateral in pieces. Same boundary, different machinery.

Euler shows yet another design choice: once health score falls to 1 or below, anyone can repay part or all of the debt and claim collateral at a discount that grows with how unhealthy the position is. Euler describes this as a reverse Dutch auction for liquidation discounts. The threshold still marks the entry into liquidation, but the penalty becomes dynamic rather than fixed.

Worked example: how collateral price moves trigger liquidation eligibility

Suppose Alice deposits ETH worth $10,000 into a lending protocol and borrows $6,000 in a stablecoin. Assume, for simplicity, that the protocol gives this collateral a liquidation threshold of 80%. That means the position remains safe as long as the debt stays below 80% of collateral value, or $8,000 at the time the loan opens.

At first glance Alice may think she has plenty of room, because she is only borrowing 60% of collateral value. But the threshold is not static in dollar terms. It moves with the collateral price. If ETH falls 20%, her collateral is now worth $8,000. The threshold applied to that new collateral value is $6,400. Her $6,000 debt is still below the boundary, so she is not yet liquidatable. If ETH falls further to $7,200, the threshold becomes $5,760. Now the debt exceeds the boundary and the position becomes eligible for liquidation.

What happens next depends on the protocol. In Aave, a liquidator can repay eligible debt and seize collateral plus a bonus. In Compound v2, the amount repayable in one transaction is limited by close factor. In Compound III, the protocol absorbs the account and later sells collateral if reserves need rebuilding. In Maker, the vault’s collateral moves into auction. In Euler, the discount to the liquidator depends on how far the health score has fallen below the threshold.

The important thing to notice is that the liquidation threshold is doing exactly one conceptual job throughout this story: it converts price movement into liquidation eligibility.

Everything after that is implementation detail layered on top of the same boundary condition.

• bonus
• auction
• absorb
• partial liquidation
• full liquidation

Why don’t protocols use a single universal liquidation threshold for all assets?

A smart reader might ask: if the purpose is just safety, why not choose a very conservative universal number for everything? Because the threshold sits inside several tradeoffs at once.

A high threshold, meaning users can borrow closer to collateral value before liquidation, makes the protocol more capital-efficient and attractive. But it leaves less room for volatility, oracle delay, and slippage during liquidation. A low threshold reduces insolvency risk but makes borrowing more expensive in collateral terms. The “best” setting depends on the asset and the liquidation mechanism.

The Berkeley DeFi study highlights this design dimension by contrasting Compound’s historically simpler structure with protocols like Aave that use asset-specific thresholds. The paper’s broader point is that these parameters shape system-wide fragility. If many users are levered close to thresholds, a relatively small price move can make large amounts of collateral liquidatable at once.

The theoretical work on DeFi fragility makes an even deeper point: rigid, pre-programmed haircut and threshold rules can create feedback loops between prices and lending. If falling prices trigger liquidations, and liquidations push prices down further, the threshold is part of a reflexive system rather than a passive safety line. That does not mean thresholds are a mistake. It means the threshold is a control parameter in a dynamic market, not merely a static rule.

How does liquidation threshold relate to LTV, collateral ratio, and health factor?

These terms are easy to blur together, so the clean distinction matters.

LTV describes how much you can borrow relative to collateral value when opening or expanding a position. It is an entry constraint.

Liquidation threshold describes when the position becomes eligible for forced unwinding. It is an enforcement boundary.

Collateral ratio expresses the same relationship from the opposite angle: collateral value divided by debt. Maker’s liquidation ratio is this style of parameter.

Health factor or health score is a normalized summary of how far a position is from the liquidation threshold. In Aave and Euler, 1 is the critical line. Above 1, the position is safe by protocol rules; at or below 1, liquidation becomes possible.

The deepest unifying idea is that all of these are different interfaces for the same solvency question: *after applying the protocol’s risk discount to collateral, does enough value remain to cover debt? * The labels differ because protocols optimize for different user experiences and enforcement mechanics, but the underlying economic boundary is the same.

What assumptions can fail and cause wrongful or failed liquidations?

The threshold works only under assumptions that are easy to ignore when markets are calm. The most obvious one is reliable pricing. If the oracle is wrong, the protocol may liquidate healthy positions or fail to liquidate unhealthy ones. Chainlink’s educational material distinguishes oracle misreporting from true market-wide price manipulation, and that distinction matters. A good oracle can reduce reporting errors, but it cannot make a manipulated market price cease to be the market price.

A second assumption is liquidation capacity. The protocol is assuming that once a position crosses the threshold, someone can and will act fast enough. Aave’s docs emphasize that liquidations are permissionless and highly competitive. In practice this means bots, monitoring infrastructure, and transaction-ordering competition. Research on MEV and priority gas auctions shows why this matters: when profit depends on winning the liquidation race, block ordering becomes part of the mechanism.

A third assumption is sufficient market depth for the collateral. Thinly traded assets are much harder to liquidate without large price impact. Secondary sources on oracle and market-manipulation risk repeatedly stress that low-liquidity assets are especially dangerous as collateral because both their reported price and their executable sale price are fragile.

A fourth assumption is governance calibration. The threshold has to be set with some model of volatility, liquidity, and correlation, but those can change faster than governance reacts. The supplied research notes that DeFi protocols are often slow to update risk parameters because changes require governance coordination. That makes thresholds inherently approximate.

How should borrowers, liquidators, and protocol teams use liquidation thresholds?

For borrowers, the liquidation threshold is the number that tells you how much room you really have. Not your optimistic borrow amount, but your distance from forced unwinding. On Aave, that often means watching health factor, because it compresses threshold information into a single metric. The protocol explicitly notes there is no universal “safe” health factor; the right buffer depends on asset volatility and correlation.

For liquidators, the threshold is the event trigger that creates opportunities. Their systems watch positions, prices, and parameter changes so they can act the moment a position becomes eligible. This is why liquidation infrastructure tends to be highly automated.

For protocol designers and governance participants, the threshold is one of the central knobs of market design. Set it too tight and usage shrinks. Set it too loose and the protocol absorbs more bad-debt risk, more auction stress, and more contagion during volatility. It also has to be coordinated with neighboring parameters such as LTV, liquidation bonus, close factor, reserve targets, and oracle configuration. A threshold is not safe in isolation; it is safe only within a consistent risk system.

Conclusion

A liquidation threshold is the rule that tells a DeFi lending protocol when a collateralized loan has become unsafe enough to liquidate. Its purpose is not just to cap borrowing, but to create a buffer between ordinary use and emergency unwinding.

Across Aave, Compound, Maker, and Euler, the labels and mechanics differ, but the invariant is the same: once discounted collateral value no longer adequately covers debt, the protocol must be allowed to act. If you remember one thing, remember this: the liquidation threshold is where price risk becomes protocol action.

How do you evaluate a DeFi lending or collateral market before using it or buying related tokens?

Evaluate a lending or collateral market by checking its liquidation thresholds, oracle setup, market depth, and liquidation mechanics, then translate that assessment into a trading or hedging action on Cube Exchange. Use Cube to adjust exposure (buy, sell, or hedge the related token) after you’ve quantified how close a position would be to the protocol’s liquidation boundary.

1. Open the protocol’s risk docs and record the collateral’s liquidation threshold, LTV/borrow limits, close factor, and liquidation bonus.
2. Verify the protocol’s oracle sources and update cadence (e.g., Chainlink vs TWAP) and note any single‑feed or delay risks.
3. Check on‑chain and CEX order-book depth for the collateral and estimate slippage for a liquidation‑sized sell.
4. Calculate the price move that would cross the liquidation threshold for your intended exposure (current price × threshold vs your planned debt or position size).
5. Fund your Cube Exchange account via fiat on‑ramp or transfer, open the TOKEN/USDC market, place a size‑optimized limit order (or split orders) to avoid large slippage, and set a stop-loss or buy a stablecoin hedge to cap downside.