LIVE

Liquidation price formula for decentralized stablecoin loans

The liquidation price of a decentralized stablecoin loan is not a universal DeFi constant.

UpdatedAugust 07, 2026
Read time22 min read
Liquidation price formula for decentralized stablecoin loans

It is a protocol-specific result of debt, collateral, risk parameters, oracle pricing, and the way the system unwinds a position under stress.

A borrower holding 10 ETH against a $7,000 Aave loan, for example, can estimate a liquidation price of $848.48 when the applicable liquidation threshold is 82.5%. That number is useful, but it is not the whole risk picture. It says where the position reaches the protocol’s trigger under the stated assumptions. It does not say how quickly the liquidation will happen, how much collateral will be sold, whether the position can be partially repaired, or what execution cost the borrower will absorb.

That distinction matters because decentralized stablecoin protocols do not share one liquidation model. MakerDAO uses collateral-type-specific parameters and Clipper auctions. Aave uses a health factor and asset-specific liquidation thresholds. Liquity uses a hard minimum collateral ratio and distributes liquidated collateral through the Stability Pool. Curve’s crvUSD uses LLAMMA, where collateral is progressively exchanged across price bands rather than being seized at one binary trigger.

The formula gives you the first-order answer: when does the position become unsafe? The mechanism gives you the more consequential answer: what happens next?

The Mechanics of Collateralized Debt: MakerDAO and Liquity Models

MakerDAO’s Liquidation 2.0 system uses Clipper contracts to conduct Dutch-style collateral auctions. A Vault becomes eligible for liquidation when its collateralization ratio falls below the liquidation ratio assigned to its collateral type, known in Maker terminology as the ilk ratio.

For a simple single-collateral Vault, the estimated liquidation price is:

Liquidation Price = (Generated DAI × Liquidation Ratio) / Collateral Amount

If a Vault contains 10 ETH, has generated 7,000 DAI, and uses a 150% liquidation ratio, the estimated trigger price is:

(7,000 × 1.50) / 10 = $1,050 per ETH

This is a threshold calculation, not a guaranteed execution price. The actual outcome depends on the oracle update, the Vault’s accumulated debt, stability fees, liquidation-related parameters, and the auction mechanics that follow.

The ratio is not the same for every collateral type. ETH-A, ETH-B, and other ilks can have different risk settings. A borrower therefore needs to identify the specific collateral type before applying a Maker liquidation price formula. Substituting a familiar ETH ratio into the calculation without checking the relevant ilk can create a materially false safety margin.

The liquidation penalty, called chop, should also be treated as an ilk-specific parameter rather than a universal MakerDAO markup. Chop is a debt multiplier used when determining the amount that must be recovered from a liquidated Vault. A value of 1.13 corresponds to a 13% penalty, but that figure is not a protocol-wide constant. It can differ by collateral type and governance configuration.

When a Vault is liquidated, the Clipper does not simply begin selling at an unadjusted spot price. The auction uses a buffered starting price derived from the oracle price and the collateral type’s auction parameters. The buffer is intended to give keepers an incentive to participate and to account for market conditions, execution risk, and the penalty structure.

The price then follows the configured Dutch-auction curve. Two parameters are especially important:

  • Tail sets the maximum duration of an individual auction before it must be reset.
  • Cusp sets a price or time condition at which the auction can be restarted rather than continuing indefinitely.

A tail value of 1,800 seconds means that the auction has a maximum configured lifetime of 30 minutes. It does not necessarily mean that the price linearly decays from the oracle price to zero over those 30 minutes. The exact trajectory depends on the Clipper implementation and price function. Nor does the auction always run uninterrupted for the full tail: if the price reaches the cusp condition, or if the tail expires, the auction can reset with a new starting price.

Maker liquidations can be partial

MakerDAO’s model is not accurately described as “above the ratio or the entire collateral is seized.” Liquidation eligibility is binary, but the amount taken in a Clipper transaction does not have to equal the entire Vault.

The auction can sell enough collateral to cover the required debt and liquidation-related amount while leaving excess collateral in the Vault. Whether that happens depends on the keeper’s take transaction, the available lot, debt limits, minimum auction sizes, and the state of the collateral market. In some cases, the whole Vault may be liquidated; in others, only part of the collateral is sold.

That distinction is operationally important. The liquidation price identifies when the Vault enters the danger zone. It does not prove that 100% of the borrower’s collateral will be removed in the next transaction. The liquidation process is a series of permissionless auction actions, not one indivisible seizure event.

ParameterMakerDAOLiquity V1
Primary triggerCollateral ratio below the collateral type’s liquidation ratioTrove collateral ratio below the 110% MCR
Basic price formulaDebt × applicable ratio ÷ collateral1.10 × debt including the reserve, divided by collateral
Liquidation mechanismClipper Dutch-style auctionDirect redistribution through the Stability Pool and, where relevant, redistribution mechanisms
Penalty or discountIlk-specific chop and auction execution conditionsLiquidator and Stability Pool economics rather than a Dutch auction
Partial liquidationPossible through auction lot sizing and take actionsTroves are generally liquidated as positions rather than gradually auctioned
Time-based auction parameterTail limits an auction before reset; cusp can trigger resetNo auction tail

Liquity takes a different route. Its Troves must remain above a Minimum Collateral Ratio, or MCR, of 110%. For a simplified ETH-backed Trove, the estimated liquidation price can be written as:

Liquidation Price = (1.10 × (Borrowed LUSD + 200 LUSD Liquidation Reserve)) / Collateral Amount

The 200 LUSD liquidation reserve is part of the Trove’s debt accounting and is intended to compensate for the gas cost of liquidation. It is not a pool of collateral that earns a return for the borrower. Because it increases the amount that must be covered by the collateral, omitting it makes the position appear slightly safer than it is.

Liquity does not send liquidated collateral through a price-discovery auction. The Stability Pool absorbs debt and receives the corresponding collateral. Stability Pool depositors provide the system with a standing source of LUSD liquidity; in exchange, they can receive ETH from liquidated Troves. The mechanism is fast and avoids the auction-tail problem, but it transfers directional exposure to the pool’s depositors. During a sharp decline, they may end up holding collateral that is worth less than the LUSD debt they extinguished, offset by the liquidation economics built into the system.

The difference between Maker and Liquity is therefore not simply “auction versus no auction.” Maker allows market participants to determine execution through a buffered, resetting auction process. Liquity pre-positions liquidity in the Stability Pool and uses direct absorption. Both systems have a formula for identifying an unsafe position, but they distribute execution risk to different participants.

Health Factor Dynamics: How Aave V3 Triggers Liquidations

Aave does not use one collateralization ratio for the entire account. It uses a health factor, which aggregates the dollar value and liquidation threshold of every collateral asset against the account’s total borrow value.

The simplified formula is:

HF = (Total Collateral Value in USD × Weighted Average Liquidation Threshold) / Total Borrow Value in USD

A health factor above 1 means that the account is above the liquidation threshold under the current oracle prices and risk parameters. A value below 1 makes the account eligible for liquidation. The word “eligible” matters: the account still depends on an external liquidator submitting a transaction, gas markets, available liquidity, and the protocol’s close-factor rules.

For a single collateral asset and a single debt asset, the liquidation price can be derived as:

Liquidation Price = Debt Value / (Collateral Amount × Liquidation Threshold)

With $7,000 of debt, 10 ETH, and an 82.5% liquidation threshold:

$7,000 / (10 × 0.825) = $848.48 per ETH

That is the clean version of the decentralized stablecoin liquidation price formula. In a live account, the calculation can be affected by accrued interest, the exact oracle price, the denomination of the debt, and whether the borrower has supplied or borrowed several assets.

For multiple collateral assets, Aave’s weighted threshold is commonly represented as:

Weighted Average Liquidation Threshold = Σ(Collateral Valueᵢ × Thresholdᵢ) / Σ(Collateral Valueᵢ)

A second collateral asset can therefore change the liquidation price of the entire account even if the price of ETH has not moved. Adding a volatile token with a lower liquidation threshold can dilute the account’s weighted average. Adding a relatively stable asset may improve the account’s effective buffer, but only if that asset remains eligible as collateral and its oracle value behaves as expected.

This is why a borrower should not calculate a liquidation price from the largest collateral position alone. The relevant question is not “How far can ETH fall?” It is “What is the health factor of the complete account after every collateral and debt balance is marked to the current protocol prices?”

Aave’s liquidation process can also be partial. The close factor determines how much of a debt position a liquidator may repay in one transaction. Under some conditions, a liquidator may repay up to a partial share of the debt; under more severe conditions, the permitted amount can rise, potentially allowing the full debt position to be covered. The exact boundary is controlled by the protocol’s configuration rather than by a universal rule that applies to every market.

The liquidator receives collateral with a market-specific liquidation bonus. A bonus in the 5–10% range is common in simplified examples, but the actual value is asset- and governance-dependent. It is better understood as an incentive for the liquidator than as a guaranteed deduction applied identically to every borrower. The realized cost depends on which collateral is seized, the repayment amount, oracle pricing, and the market price at which the liquidator later sells or holds the collateral.

A health factor is a live trigger metric, not a comfort score. An account at 1.01 has very little room for an adverse oracle update, interest accrual, or execution delay, even though the displayed value is technically above one.

A useful safety margin is the distance between the current collateral price and the calculated liquidation price. It can be expressed as:

Safety Margin = (Current Collateral Price − Liquidation Price) / Current Collateral Price

If ETH trades at $1,200 and the calculated liquidation price is $848.48, the nominal price margin is approximately 29.3%. That margin is not a promise that the account can absorb a 29.3% decline without consequences. It can shrink as debt accrues, as another collateral asset falls, or as the weighted liquidation threshold changes through governance.

The same logic applies to a CDP liquidation price calculation. A borrower should update the calculation after:

  • borrowing additional stablecoins;
  • repaying only one of several debt assets;
  • adding collateral with a different liquidation threshold;
  • withdrawing a high-quality collateral asset;
  • allowing variable-rate debt to accrue;
  • moving collateral into a market with a different oracle or risk configuration.

The formula is simple enough to calculate by hand. The account state is not.

Soft-Liquidation and LLAMMA: The crvUSD Price Band Approach

Curve’s crvUSD uses the Lending-Liquidating AMM Algorithm, or LLAMMA, to make liquidation more gradual. Instead of waiting for the collateral to cross one hard trigger and then selling it through a single auction, the system distributes collateral across a sequence of price bands.

As the collateral price moves downward through those bands, part of the collateral can be exchanged for crvUSD. If the price later recovers, the position can move in the opposite direction, converting some crvUSD exposure back into the collateral asset. The borrower’s balance therefore changes composition as the market travels through the band structure.

A simplified representation of the band geometry is:

Upper price of the n-th band: pᵤₚ = pᵦₐₛₑ × ((A − 1) / A)ⁿ

The precise implementation includes the band state, the amplification parameter, oracle behavior, and the amount of collateral assigned to each band. The formula is useful for understanding the structure, but it should not be treated as a complete liquidation-price calculator for every crvUSD position.

At the upper part of a band, the position may be predominantly collateral. As price declines, the AMM gradually sells collateral into crvUSD. Deeper into the band sequence, the position can become increasingly stablecoin-denominated. If the decline continues far enough, the collateral may be fully converted. That outcome is economically similar to liquidation, but the path is distributed across price movement rather than concentrated at a single threshold.

The discount is not a flat 6% on every downward tick

LLAMMA’s economics are often summarized with a single discount figure, but that shortcut obscures the mechanism. The effective cost of moving through a band is influenced by the band’s price geometry, the amplification parameter, oracle updates, pool balances, fees, and the direction and speed of the market move. It is not accurate to say that every downward price movement automatically imposes a fixed 6% loss.

A borrower can still realize a loss during a decline, especially if the position is converted into crvUSD and the market does not recover. But that loss is path-dependent. The borrower may experience a different result depending on how far price moves, how quickly the oracle and bands update, whether the price reverses, and how much of the position has already been converted.

A recovery can reverse some of the collateral transformation, but it does not guarantee a frictionless return to the original position. Trading fees, band-level price effects, timing, and the sequence of conversions can all matter. “Soft liquidation” describes the distribution of the process, not the absence of economic loss.

The maximum LTV or other borrowing limit for a crvUSD market is also a market-specific risk parameter. It should not be presented as one permanent value for every crvUSD collateral type or deployment. A higher permitted LTV can be supported by the gradual mechanism, but it also leaves less room for oracle lag, abrupt gaps, and adverse band transitions.

LLAMMA changes liquidation from a single cliff into a path through price bands. That can reduce the shock of one forced sale, but it does not turn declining collateral into a free option.

The health calculation introduces another layer of complexity. LLAMMA does not rely on a simple comparison between one external spot price and one collateral value. Its accounting can involve simulated conversions between collateral and crvUSD using a dynamic oracle anchor and band-related prices. The result is sensitive to the relationship between the oracle, the AMM state, and the assumed conversion path.

That creates a distinct risk from ordinary oracle failure. An external price feed can be functioning as designed while an internal health calculation still makes a dangerous assumption about how two prices relate. If the simulated sale and repurchase prices diverge sharply, the calculated health of a position can deteriorate even when the broader market has not moved by the same amount.

Risk Vectors: Oracle Manipulation and the sDOLA Exploit Lessons

The sDOLA LLAMMA market on Curve was exploited on March 2, 2026, for approximately $239,000. The reported attack focused on the interaction between the get_x_down() health calculation, an ERC4626 vault, and the prices used to simulate a round trip through the LLAMMA system.

The function calculated position health using both a dynamic oracle price anchor and a static band price anchor. The attacker used an ERC4626 donation to inflate the vault’s apparent share price. That pushed the oracle anchor upward without representing a corresponding improvement in the underlying asset’s genuine market value.

Once the manipulated value entered the health calculation, the simulated round trip could produce a negative health result. Positions that had not become conventionally undercollateralized were treated as liquidatable, allowing the attacker to obtain collateral at a discount. The reported profit was approximately $239,000.

This was not a conventional Chainlink compromise. Nor did it require the attacker to move a widely traded spot market in the ordinary sense. The weakness was in the connection between vault accounting and liquidation logic: an ERC4626 donation changed the apparent per-share value, and the health function trusted that value in a way that affected liquidation eligibility.

The broader lesson is not that simulated conversions are inherently unsafe. Simulation is often necessary in a band-based liquidation system. The problem is that every simulation contains assumptions about price sources, share accounting, liquidity, timing, and reversibility. If one of those assumptions can be altered more cheaply than the real market price, the formula becomes an attack surface.

A robust risk review therefore asks more than whether the protocol uses an oracle. It asks:

  • Can the relevant share price be changed through a donation or accounting edge case?
  • Does the health function use a value that can be manipulated in one transaction?
  • Are the prices used for liquidation eligibility the same prices available for execution?
  • Can a calculated negative or extreme value trigger collateral transfer without an independent sanity check?
  • What happens when the oracle price, band price, and vault share price disagree?

These questions apply to decentralized stablecoins, lending markets, yield-bearing collateral, and any protocol that derives solvency from an internal conversion rather than a direct and independently bounded market price.

The sDOLA incident also illustrates why a liquidation formula cannot be evaluated separately from its implementation. On paper, a price band and a round-trip conversion can look conservative. In production, the relevant issue is whether an attacker can influence one leg of the calculation while leaving the other unchanged.

Operational Parameters: From Auction Tail Limits to Liquidation Penalties

Liquidation parameters define how a theoretical trigger becomes an actual loss. They determine the starting point, the size of the incentive for liquidators, the time available for execution, and the amount of collateral that can be removed in one transaction.

MakerDAO

Maker’s operational parameters include:

  • Liquidation ratio: the collateralization threshold for the specific collateral type.
  • Chop: an ilk-specific debt multiplier applied in liquidation accounting. A value such as 1.13 represents a 13% penalty, but the value is not universal across all ilks.
  • Buf: a price buffer used when establishing the initial Clipper auction price relative to the oracle-derived reference.
  • Tail: the maximum duration of an auction before it can be reset.
  • Cusp: a reset condition tied to the auction’s price decline.
  • Step or price-function settings: parameters governing how the auction price changes over time.

A tail of 1,800 seconds means a 30-minute maximum auction lifetime under that configuration. It does not mean that every auction takes 30 minutes, that the price falls linearly, or that it necessarily reaches zero. A keeper can buy collateral before the tail expires, and the auction can reset when the cusp condition is met.

The borrower’s realized cost is therefore not simply “the chop percentage.” Chop affects the debt that must be covered, while the Clipper’s buffered starting price, auction curve, keeper competition, gas costs, and market liquidity affect the execution result. The auction may clear quickly near a favorable price, or it may need to reset during a volatile market.

Aave V3

Aave’s key parameters include:

  • Liquidation threshold: the percentage of collateral value counted toward solvency.
  • Health factor trigger: liquidation eligibility begins below 1.0.
  • Close factor: the maximum portion of debt a liquidator can repay in a transaction.
  • Liquidation bonus: the collateral incentive paid to the liquidator, set by asset and market.
  • Oracle configuration: the price source and fallback behavior for each asset.
  • Reserve-specific caps and restrictions: limits that can affect how much collateral can be supplied or borrowed.

The liquidation bonus is not a Dutch-auction penalty. It is a predefined incentive that allows a liquidator to repay debt and claim a greater value of collateral. Because the transfer happens at the protocol’s configured pricing rules, the process can be executed at block level rather than waiting for a competitive auction. The trade-off is that the position can be liquidated during a single adverse update if liquidators are active and the account has crossed the threshold.

For an account with several assets, a dashboard’s health factor is usually more informative than a manually calculated ETH-only liquidation price. The manual formula remains useful as a stress-test, but it should be recalculated for every material change in debt or collateral.

Liquity

Liquity’s main parameters are more compact:

  • MCR: 110% for the relevant Troves in the original ETH-backed design.
  • Liquidation reserve: 200 LUSD included in the Trove’s debt accounting.
  • Stability Pool capacity: the available LUSD that can absorb liquidated debt.
  • Recovery-mode rules: system-wide conditions that can change which Troves are eligible and how redemptions or liquidations interact.

Liquity’s lack of an auction tail removes one category of execution delay. It does not remove market risk. The Stability Pool must have sufficient deposits, and depositors receive collateral whose value can continue to move after absorption. A fast mechanism can still transfer losses quickly.

Curve crvUSD and LLAMMA

For LLAMMA, the relevant parameters include:

  • Band count and placement: how far the collateral can move through the liquidation range.
  • Amplification parameter: how the price bands and conversion curve are shaped.
  • Oracle behavior: how quickly the system’s reference price follows the market.
  • AMM liquidity and balances: factors that affect conversion outcomes.
  • Fees and band-level price effects: costs that can compound during repeated conversions.
  • Borrowing limits: market-specific parameters that determine the initial collateral buffer.

There is no single flat “soft-liquidation penalty” that captures all LLAMMA outcomes. A position that enters a band briefly and recovers can have a different result from one that travels through several bands during a fast decline. A borrower must examine the path, not only the headline LTV.

ProtocolTrigger or Entry ConditionExecution ModelHow the Borrower’s Loss Is DeterminedPartial or Gradual Process
MakerDAOCollateral ratio falls below the applicable ilk ratioBuffered Clipper auction with reset conditionsIlk-specific chop plus auction execution price and market conditionsPartial collateral sale is possible
Aave V3Health factor falls below 1Permissionless liquidator repays debt and receives collateral bonusAsset-specific bonus, oracle price, close factor, and market liquidityYes; amount depends on close-factor rules
LiquityTrove collateral ratio falls below the MCRDirect absorption through the Stability Pool and related system rulesStability Pool allocation and collateral price movementTrove liquidation is generally position-level
Curve crvUSDCollateral moves through LLAMMA price bandsGradual AMM conversion between collateral and crvUSDPath through bands, oracle state, fees, and conversion pricesYes; band by band

Reading the Formula Without Misreading the Risk

A liquidation price is best treated as a moving estimate. It is calculated from the current state of the position, while the position itself changes continuously.

For a basic CDP, the most important variables are:

1. Debt balance. Interest, stability fees, and accrued borrowing costs increase the numerator.

2. Collateral amount. Withdrawals reduce the denominator and move liquidation closer.

3. Risk threshold. A higher liquidation ratio or lower liquidation threshold leaves less borrowing capacity.

4. Oracle price. The protocol may use a delayed, smoothed, or otherwise configured reference rather than the price shown on a retail exchange.

5. Execution mechanism. The liquidation price does not determine the final sale price by itself.

6. Liquidity and transaction conditions. Gas spikes, congestion, thin markets, and unavailable keepers can change the practical result.

Suppose a borrower calculates a 25% price margin and decides that the position is safe because the collateral “can fall by a quarter.” That conclusion ignores the difference between a clean market decline and a discontinuous move. A slow decline may give liquidators time to act and the borrower time to add collateral. A sharp gap can cross the trigger, consume the available close factor, and leave the borrower with a smaller and more expensive position before any manual response is possible.

The same problem appears when borrowers compare protocols using only headline ratios. A 110% MCR, an 82.5% Aave liquidation threshold, and a 150% Maker liquidation ratio are not interchangeable numbers. They belong to different debt systems with different definitions of collateral value, different liquidation mechanics, and different treatment of the post-trigger state.

Maker’s 150% ratio does not mean a Vault loses 50% of its collateral at the instant of liquidation. Aave’s 82.5% threshold does not mean the liquidator receives exactly 17.5% of the collateral. Liquity’s 110% MCR does not mean every liquidated Trove is sold at a 10% discount. LLAMMA’s bands do not guarantee that a temporary decline produces no loss.

The correct comparison is between complete mechanisms:

  • What value enters the trigger formula?
  • Which parameter determines eligibility?
  • How much debt can be repaid?
  • How much collateral can be taken?
  • Is there an auction, a pool, or an AMM?
  • Can the position recover if price reverses?
  • Who absorbs the collateral and timing risk?
The formula tells you when the protocol considers the position unsafe. The liquidation mechanism determines who gets the collateral, at what reference price, and how much of the loss becomes real.

That is the practical meaning of a collateralized debt position safety margin. It is not just the difference between two prices. It is the distance to the trigger after accounting for debt growth, oracle behavior, liquidation granularity, and the protocol’s ability to execute under stress.

For a simple loan, the calculation can be done with a calculator. For a multi-asset DeFi account, it should be treated as a live risk model. Recalculate after every borrow, repayment, collateral swap, parameter change, and major market move. Then examine the protocol mechanics separately: the possibility of a partial Clipper sale, Aave’s close factor, Liquity’s Stability Pool capacity, or LLAMMA’s path through its bands.

Decentralized stablecoin lending is not protected by one liquidation price. It is protected, or exposed, by the interaction between formulas and mechanisms. A borrower who understands only the trigger is measuring the edge of the cliff. A borrower who understands the execution model knows what the fall may cost.

FAQ

What is the difference between a liquidation trigger and the final liquidation cost?
The trigger is a threshold that determines when a position becomes eligible for liquidation, while the final cost is determined by the protocol's specific execution mechanism, such as auction results, liquidation bonuses, or AMM conversion paths.
Why is the liquidation price for a MakerDAO Vault not a guaranteed execution price?
The calculated price is a threshold for auction eligibility; the actual outcome depends on the Dutch-auction mechanics, the buffered starting price, keeper competition, and market conditions at the time of the auction.
How does Aave's health factor affect liquidation?
A health factor below 1.0 makes an account eligible for liquidation. The protocol then allows liquidators to repay a portion of the debt, determined by the close factor, in exchange for collateral plus a liquidation bonus.
Does Liquity liquidate positions through auctions?
No, Liquity does not use auctions. Instead, it uses a Stability Pool that absorbs debt and distributes the corresponding collateral directly to depositors.
How does Curve's crvUSD handle liquidations differently?
Curve uses LLAMMA, which distributes collateral across a sequence of price bands. As the price declines, the system gradually converts collateral into crvUSD rather than triggering a single, binary liquidation event.