Liquidation Engine Design & Execution Quality

TL;DR

A liquidation engine is the internal pipeline that detects undercollateralized accounts, sequences position closures, and routes fills — it decides when, how fast, and at what price a position dies
Execution quality is measurable: the gap between the mark price when liquidation triggers and the actual fill price is the engine's report card. Good engines minimize this gap; bad ones donate it to MEV bots, backstop vaults, or the insurance fund
Three fill strategies dominate: on-book IOC orders (fast but high impact), backstop liquidity providers (off-book, guaranteed fill, negotiated price), and auto-deleveraging (last resort, forces counterparties to close)
Latency budgets matter more than people think: FTX sent 10% of a position every 6 seconds. Backpack sends ~10% every ~2 seconds with 50% probability gating. Hyperliquid sends the full position as a market order immediately. Each choice has radically different cascade and slippage profiles
Keeper networks (DeFi) and internal liquidation loops (CeFi) solve the same problem differently — keepers compete for profit in a gas auction; CeFi engines execute deterministically but opaquely
Zombie accounts — positions stuck with negative equity that no one wants to fill — are an underappreciated operational problem. They accumulate bad debt silently and must be swept into the insurance fund or written off
Oracle Extractable Value (OEV) is the new frontier: every liquidation triggered by a price oracle update creates value that keepers, MEV searchers, or the protocol itself can capture. Aave V4 and Pyth/UMA Oval represent competing approaches to routing this value
The insurance fund settlement workflow is the final step — surplus from clean liquidations flows in, bad debt from failed liquidations flows out, and the net balance determines whether the exchange can avoid socializing losses
Aave V4's Dutch auction model scales liquidation bonuses with risk severity, replacing fixed close factors with dynamic incentives that prioritize the riskiest positions
Historical failures are instructive: Hyperliquid's JELLY exploit (March 2025) showed what happens when a liquidation engine inherits a position too large for available liquidity — $12M in losses, emergency delisting, and a centralization controversy

1. What the Liquidation Engine Actually Does

The liquidation engine is the most consequential piece of software at any leveraged trading venue. It runs continuously, scanning every account's margin fraction against maintenance requirements, and when an account crosses the threshold, the engine takes over that account's positions and attempts to close them at the best available price.

This sounds simple. It is not. The engine must make a series of decisions under extreme time pressure:

Detection: Which accounts are undercollateralized right now?
Prioritization: If 500 accounts breach maintenance simultaneously, which ones get processed first?
Sizing: Should the entire position be closed at once, or in pieces?
Routing: Should the order go to the public order book, to a backstop liquidity provider, or directly to ADL?
Pricing: What price limit should be placed on the liquidation order?
Timing: How fast should the engine iterate? Every millisecond? Every second? Every 6 seconds?
Escalation: If the first attempt fails, when and how does the engine escalate to more aggressive mechanisms?

Every one of these decisions involves a tradeoff between speed (closing the position before more losses accumulate) and market impact (not crashing the price with aggressive selling). Get the balance wrong in either direction and the consequences are severe: too slow, and bad debt accumulates; too fast, and the engine itself causes a cascade that liquidates hundreds of additional accounts.

The Liquidation Pipeline:

  Account Monitoring (continuous)
        │
        ▼
  MF < MMF detected
        │
        ▼
  ┌─────────────────────┐
  │ PRIORITIZATION      │
  │ • Most undercoll.   │
  │   accounts first    │
  │ • Largest positions  │
  │   may get special   │
  │   handling           │
  └─────────────────────┘
        │
        ▼
  ┌─────────────────────┐         ┌─────────────────────┐
  │ TIER 1: On-Book     │────────▶│ Fill successful?    │
  │ IOC limit orders    │         │ MF restored?        │
  │ Throttled chunks    │         │                     │
  └─────────────────────┘         └─────────┬───────────┘
                                       │ No
                                       ▼
  ┌─────────────────────┐         ┌─────────────────────┐
  │ TIER 2: Backstop    │────────▶│ Fill successful?    │
  │ Designated LPs      │         │ MF restored?        │
  │ Off-book fills      │         │                     │
  └─────────────────────┘         └─────────┬───────────┘
                                       │ No
                                       ▼
  ┌─────────────────────┐
  │ TIER 3: ADL         │
  │ Force-close vs      │
  │ profitable traders  │
  └─────────────────────┘
        │
        ▼
  ┌─────────────────────┐
  │ SETTLEMENT          │
  │ Surplus → Ins. Fund │
  │ Deficit → Ins. Fund │
  │ (or socialized)     │
  └─────────────────────┘

The quality of each step in this pipeline determines how much value is preserved for the liquidated trader (leftover margin returned), how much flows to the insurance fund (surplus), and how much is destroyed (slippage, bad debt, MEV extraction).

2. Fill Strategies: How Liquidation Orders Get Executed

The engine has detected an undercollateralized account. Now it needs to close the position. There are fundamentally three strategies, and every exchange uses some combination.

Strategy 1: On-Book Execution

The engine sends orders directly to the public order book, typically as IOC (Immediate-Or-Cancel) limit orders that cross the spread. This is the simplest and most transparent approach.

Advantages:

Transparent price discovery — the position is closed at whatever price the market offers
No special relationships or off-book arrangements required
Any market participant can provide the liquidity

Disadvantages:

High market impact during stress — liquidation orders consume resting bids/asks and push the price
Susceptible to front-running — other participants see the liquidation order and trade ahead of it
In thin markets, may not fill at all (or fill at catastrophic prices)

Implementation variations:

Exchange	Order Size	Frequency	Price Limit
FTX (historical)	10% of position	Every 6 seconds	1-5 bps through book
Backpack	10% of position	Every ~2 sec (50% probability)	2% from index price
Hyperliquid	100% of position (or 20% if >$100K)	Immediate	Market order
Binance	Tiered by position size	Sub-second	Mark price ± band

The differences are stark. FTX's approach was deliberately slow — 10% every 6 seconds meant a full liquidation took roughly a minute, giving the book ample time to refill between chunks. Hyperliquid's approach is the opposite extreme: the full position hits the book as a market order immediately. For small positions this works fine. For a $300M ETH position (as in the March 2025 incident), it is catastrophic.

Strategy 2: Backstop Liquidity Providers (BLPs)

When on-book execution fails or would cause excessive market impact, the engine routes to designated market makers who have contractually agreed to absorb liquidation flow.

How it works:

The exchange maintains a registry of approved backstop LPs for each market
Each BLP has capacity limits (position size they will absorb) that refresh periodically
When triggered, the BLP takes on the liquidated position at a negotiated price — typically derived from the mark price with a spread that compensates for the risk
The fill happens off-book, meaning it does not affect the public order book or the market price

On-Book vs. Backstop Fill:

On-Book:
  Liquidation sell order ──▶ PUBLIC ORDER BOOK ──▶ Price impact
                                    │                   │
                                    ▼                   ▼
                            Bids consumed        Other liquidations
                                                 may be triggered

Backstop:
  Liquidation sell order ──▶ BACKSTOP LP ──▶ No public price impact
                                    │
                                    ▼
                            LP manages position
                            on their own book
                            (may hedge on other
                            venues)

FTX pioneered this model in crypto. Their Backstop Liquidity Provider program allowed approved firms to register with pre-committed capacity. When an account's margin dropped dangerously low, the engine would transfer the entire position and collateral to a BLP, who then managed the unwinding themselves. The key insight was that professional market makers, with access to liquidity across dozens of venues, could unwind a large position far more efficiently than dumping it onto a single exchange's order book.

Backpack implements a similar system where BLPs receive 2/3 of the spread between mark price and zero-equity price, with 1/3 flowing to the liquidity fund. Each BLP has hourly and minutely capacity limits that prevent any single provider from becoming overexposed.

Strategy 3: Auto-Deleveraging (ADL)

The last resort. When both on-book execution and backstop capacity are exhausted, the engine matches the liquidated position against profitable traders on the opposite side. This is covered extensively in Insurance Funds, so we will focus here on the engine-specific mechanics.

From the engine's perspective, ADL is the simplest fill strategy: select counterparties by ranking (typically profit x leverage, or margin fraction ascending), force-close their positions at the bankruptcy price of the liquidated account, and settle. There is no price discovery, no order book interaction, and no market impact. The position simply transfers from one account to another at a predetermined price.

The engine's ADL implementation must handle edge cases:

Delta-reducing constraint: Backpack first tries to match only against counterparties where the fill reduces (not flips) their position. A short trader should get their short reduced, not flipped to long. Only if this constraint produces insufficient fills does the engine relax it.
Partial fills: If the top-ranked counterparty has a smaller position than the liquidated account, multiple counterparties are filled in sequence.
Cross-margin effects: ADL fills change the counterparty's margin fraction, which could theoretically push them into liquidation. Good engines check for this.

3. Latency Budgets and Timing

How fast should a liquidation engine run? This question sounds technical but it is fundamentally an economic one. Every second of delay is a second where the market can move further against the liquidated position, increasing the probability of bad debt. But every second of delay is also a second where the order book can refill, reducing slippage.

The Latency-Slippage Tradeoff

                    Liquidation Speed

Fast (ms)                               Slow (minutes)
   ◄─────────────────────────────────────────►
   │                                         │
   │ Low latency risk                        │ High latency risk
   │ (position closed before                 │ (market moves further,
   │  market moves further)                  │  bad debt accumulates)
   │                                         │
   │ High impact risk                        │ Low impact risk
   │ (large order crashes                    │ (small orders, book
   │  the book immediately)                  │  refills between fills)
   │                                         │
   │ Hyperliquid-style                       │ FTX-style
   │ "Send everything now"                   │ "10% every 6 seconds"
   │                                         │
   │         Backpack-style                  │
   │         "10% every ~2s,                 │
   │          probabilistic"                 │

Concrete Example: 7 Seconds of Missed Price Improvement

Consider a trader being liquidated on their 100 BTC long at a mark price of $60,000. The engine triggers and begins sending liquidation sell orders. But the market is volatile — during the 7 seconds it takes for the first chunks to fill, the price has bounced from $59,500 to $60,200 and back to $59,800.

Time	Mark Price	Engine Action	Fill Price	Slippage
t=0s	$60,000	Trigger. Send 10 BTC IOC	$59,950	$50/BTC
t=2s	$59,800	Send 10 BTC IOC	$59,720	$80/BTC
t=4s	$59,500	Send 10 BTC IOC	$59,350	$150/BTC
t=5s	$59,800	50% probability skip	—	—
t=6s	$60,200	Send 10 BTC IOC	$60,100	-$100/BTC (improvement)
t=7s	$59,800	Send 10 BTC IOC	$59,680	$120/BTC

The average fill across these chunks is $59,760, versus a mark price at trigger of $60,000. That is $240 of slippage per BTC, or $24,000 total on 100 BTC. If the engine had waited 1 more second (when the price bounced to $60,200) and sent a larger chunk, it could have captured significantly better fills.

But the engine does not know the future. It cannot predict the bounce. The throttling approach accepts some fills at bad prices in exchange for the statistical benefit of not dumping everything into a thin book at the worst possible moment. Over thousands of liquidations, the throttled approach produces better average execution than the dump-everything approach — even though any individual liquidation may have a worse outcome than a perfectly timed instant execution.

CeFi vs. DeFi Latency Profiles

Dimension	CeFi (Binance, Backpack)	DeFi (Aave, Hyperliquid)
Detection latency	Sub-millisecond (in-memory)	Block time (1-12 seconds)
Execution latency	Milliseconds per order	Block time per transaction
Throttling	Engine-controlled timing	Gas price / block inclusion
Fill certainty	High (backstop LPs)	Variable (keeper competition)
Observability	Opaque (engine internals hidden)	Transparent (on-chain)

CeFi engines have a fundamental speed advantage: they run in-memory, in the same datacenter as the matching engine, and can detect and act on margin breaches in single-digit milliseconds. DeFi engines are constrained by block times — on Ethereum L1, a liquidation cannot execute faster than 12 seconds (one block). On L2s and app-chains (Hyperliquid, dYdX v4), block times are sub-second, closing the gap.

4. Keeper Networks and Liquidator Competition

In DeFi, the liquidation engine is not a single process run by the exchange. It is an open system where anyone can trigger a liquidation by calling a smart contract function. The entities that do this are called keepers (or liquidators, or liquidation bots).

How Keeper Competition Works

Oracle publishes new price
        │
        ▼
┌───────────────────────────────────┐
│  MEMPOOL                          │
│                                   │
│  Keeper A: liquidate(account_42)  │
│  Keeper B: liquidate(account_42)  │
│  Keeper C: liquidate(account_42)  │
│  Keeper D: liquidate(account_42)  │
│                                   │
│  All see the same opportunity     │
│  All race to be included first    │
└───────────────────────────────────┘
        │
        ▼
  Block builder selects highest
  gas bid (or MEV bundle)
        │
        ▼
  ONE keeper wins. Others waste gas.

The dynamics of keeper competition have evolved significantly:

Early days (2019-2021): Few keepers, slow oracle updates, large liquidation bonuses (5-10% of collateral value). Keepers were highly profitable. Many liquidations went uncontested for multiple blocks.

Competitive era (2022-2024): Dozens of sophisticated keepers with sub-30ms mempool monitoring, private relay access, and cross-protocol arbitrage strategies. Keeper profit margins compressed as competition intensified. On Aave V2, 73.97% of liquidators paid above-average gas fees to win priority — a clear sign of competitive pressure.

OEV era (2024-present): The realization that liquidation events create extractable value (OEV) that should flow to the protocol, not to keepers. UMA's Oval wraps Chainlink price updates and channels liquidation opportunities through a Flashbots MEV-share auction. Pyth uses express relay auctions. Aave V4 implements a Dutch auction where the keeper bonus scales with health factor severity.

The Liquidation Bonus Problem

Every DeFi lending protocol must pay keepers to perform liquidations. This payment is the liquidation bonus — a discount on the collateral that the keeper receives for repaying the borrower's debt.

On Aave V3, the typical bonus is 5-10% of the liquidated collateral value. Across Aave and Compound's history, over $1 billion in collateral has been liquidated with an average premium of ~4.5%. That represents roughly $45-50 million in value that left the protocol and went to liquidators.

This value leakage is why protocol designers are moving toward auction-based models:

Model	Keeper Incentive	Value Capture	Who Benefits
Fixed bonus (Aave V2/V3)	5-10% of collateral	None — all goes to keeper	Keepers
Dutch auction (Aave V4)	Scales with risk severity	Protocol sets floor and ceiling	Borrowers (less over-liquidation)
OEV auction (UMA Oval)	Auction-determined	~90% back to protocol	Protocol and its users
Express relay (Pyth)	Bundled cross-protocol auction	Revenue to integrating protocols	Protocols using Pyth oracles

CeFi's "Internal Keeper"

Centralized exchanges do not have keeper networks. The exchange itself is the sole liquidator. This has advantages (no MEV extraction, no gas wars, deterministic execution) and disadvantages (no competition to improve execution quality, no transparency about how well the engine performs).

Some CeFi exchanges publish liquidation data (Binance shows recent liquidations on CoinGlass, exchanges report total liquidation volume), but none publish execution quality metrics — the actual fill prices relative to mark prices at trigger time. This is the single biggest transparency gap in CeFi exchange infrastructure.

5. Execution Quality: Measuring the Engine's Performance

How good is a liquidation engine? The answer is measurable, but almost no exchange publishes the data.

The Core Metric: Fill Price vs. Trigger Price

When the engine triggers a liquidation, the mark price at that instant represents the "fair" price. The actual execution price (volume-weighted average across all fills) represents what the position was actually closed at. The difference is execution slippage.

Execution Quality Spectrum:

Better ◄─────────────────────────────────────────────► Worse

  Fill above          Fill at         Fill at         Fill below
  mark price          mark price      bankruptcy      bankruptcy
  (surplus to         (break-even)    price           price
  ins. fund)                          (zero surplus)  (BAD DEBT)
      │                   │               │               │
      ▼                   ▼               ▼               ▼
  Engine captured     Neutral        All margin       Insurance fund
  price improvement                  consumed         must cover
                                                      the shortfall

What Good Looks Like

A well-designed engine should produce the following distribution across all liquidations:

80-90%+ of liquidations fill above the bankruptcy price, generating surplus for the insurance fund
5-15% fill near or at the bankruptcy price, breaking even
< 5% generate bad debt (fill below bankruptcy), typically only during extreme volatility

During calm markets, nearly 100% of liquidations should generate surplus. The engine's true test is during crashes — how much of its liquidation volume generates bad debt vs. surplus.

Benchmarking Against Available Market Prices

A more sophisticated analysis compares the engine's fill prices against the best available price on any venue at the time of each fill. If BTC is trading at $60,000 on Binance and $60,100 on OKX when the engine fills a liquidation at $59,800, the execution quality relative to best available is $200 worse than it could have been.

This benchmark matters because backstop LPs can (and do) hedge liquidation positions on other exchanges. A BLP that takes on a 100 BTC short at $59,800 and immediately sells on Binance at $60,000 captures $200/BTC risk-free. The existence of this profit indicates the engine's price could have been better.

Timeline of a liquidation with missed price improvement:

    $60,200 ┤
             │           ╱╲
    $60,000 ┤──────────╱──╲──────── Best available (other venues)
             │        ╱    ╲
    $59,800 ┤───────╱──────╲─────── Actual fill price
             │     ╱        ╲
    $59,600 ┤    ╱           ╲
             │  ╱
    $59,400 ┤ ╱  ← Mark price at trigger
             │╱
             └──────────────────────
             t=0  t=2s  t=5s  t=7s

    Gap between actual fill and best available = value leaked
    to backstop LPs, arbitrageurs, or simply destroyed as slippage

Why Exchanges Don't Publish This Data

Publishing execution quality metrics would expose the engine's weaknesses. An exchange that liquidates aggressively (to protect the insurance fund) would show consistently high slippage. An exchange with poor backstop LP coverage would show frequent bad debt events. An exchange with slow detection would show large gaps between available prices and actual fills.

The incentive to publish is low (it invites criticism), while the cost is high (it reveals proprietary engine design). As a result, traders have essentially no way to compare liquidation engine quality across venues — a gap that meaningfully affects which exchange they should trust with leveraged positions.

6. Zombie Accounts and Negative Equity Cleanup

Not every liquidation resolves cleanly. Sometimes a position cannot be closed — the book is empty, backstop capacity is exhausted, ADL has been triggered but the counterparty pool is insufficient, or the position is in an illiquid market where nobody wants to take the other side. These positions become zombie accounts: accounts with negative equity that sit on the exchange's books, accumulating losses.

How Zombie Accounts Form

Normal Liquidation:

  Account breaches MMF → Engine closes position → Account settled
  (clean exit, surplus or deficit determined, insurance fund updated)


Zombie Formation:

  Account breaches MMF → Engine attempts close → Partial fill only
       │
       ├─ Book is empty (no resting orders)
       ├─ Backstop LPs at capacity
       ├─ ADL pool insufficient
       ├─ Market is delisted or halted
       │
       ▼
  Account stuck with open position
  Equity: NEGATIVE (and getting worse)
  Status: ZOMBIE — no one wants this position

The Accumulation Problem

Zombie accounts are insidious because they accumulate silently. A single zombie account with -$500 in equity is trivial. But during a crash, hundreds of accounts might fail to fully liquidate in illiquid altcoin markets. Each one carries negative equity. Collectively, they represent a growing drain on the insurance fund.

Consider the lifecycle:

Phase	Zombie Count	Cumulative Bad Debt	Status
Normal markets	0-5	< $10K	Negligible
Moderate volatility	10-50	$50K-$500K	Manageable
Major crash	100-500+	$1M-$10M+	Insurance fund stress
Delisting event	Varies	Market-dependent	Requires manual intervention

Cleanup Strategies

1. Periodic sweeping: The engine runs a background process that identifies accounts with negative equity and no open orders. These accounts are settled against the insurance fund at the current mark price (or at zero, if the position is worthless). This writes off the bad debt formally.

2. Market maker absorption: In some cases, the exchange can negotiate with market makers to absorb zombie positions in bulk at a steep discount. The market maker takes on the risk of unwinding; the exchange takes a known, fixed loss rather than an open-ended one.

3. Forced settlement at oracle price: For positions in markets that still have oracle prices, the exchange can force-settle the position at the oracle price. The difference between the position's entry and the oracle price determines the final loss, which flows to the insurance fund.

4. Delisting settlement: When a market is being delisted (because the asset has died, liquidity has evaporated, or regulatory requirements mandate removal), all remaining positions — including zombies — are settled at a final settlement price. Binance, for example, publishes a delisting schedule with a settlement price determined by the average of the last hour of index prices.

The Hyperliquid JELLY Incident: Zombie at Scale

The March 2025 JELLY exploit on Hyperliquid is the most dramatic example of a zombie account creating systemic risk. The attacker:

Opened three accounts: two longs ($2.15M and $1.9M) and one short ($4.1M) on JELLY, an illiquid meme token
Pumped JELLY's price 400% on external exchanges
The short position was liquidated, but was too large for the order book to absorb
The position was transferred to the HLP vault (Hyperliquid's backstop)
As the price kept rising, the HLP vault — holding $230M in total assets — was accumulating losses on this single inherited position
Hyperliquid's validators emergency-delisted JELLY, settling all positions at $0.0095 (the attacker's entry price), not the $0.50 market price

The short position had become a zombie: negative equity, no available counterparties, and a market that was being actively manipulated to worsen the position. The vault absorbed $12M in losses before the manual intervention. The engine had no mechanism to handle a position that was simultaneously too large to fill, in a market too illiquid to support it, with a price being actively manipulated against it.

This incident led Hyperliquid to reduce maximum leverage on major assets from 50x to 25-40x and implement position size limits relative to market depth.

7. Insurance Fund Settlement Workflow

The insurance fund is the financial counterpart to the liquidation engine. Every liquidation produces either a surplus (fill was better than bankruptcy price) or a deficit (fill was worse). The settlement workflow routes these flows correctly.

The Flow: From Liquidation to Settlement

LIQUIDATION COMPLETED
        │
        ├── Calculate: Fill Price vs. Bankruptcy Price
        │
        ▼
┌───────────────────┐     ┌───────────────────┐
│ Fill > Bankruptcy  │     │ Fill < Bankruptcy  │
│                   │     │                   │
│ SURPLUS           │     │ DEFICIT           │
│                   │     │                   │
│ Remaining margin  │     │ Account equity    │
│ after position    │     │ is NEGATIVE       │
│ closed above      │     │                   │
│ bankruptcy price  │     │ Someone must      │
│                   │     │ absorb the loss   │
└────────┬──────────┘     └────────┬──────────┘
         │                         │
         ▼                         ▼
┌───────────────────┐     ┌───────────────────┐
│ Insurance Fund    │     │ Insurance Fund    │
│ INFLOW            │     │ OUTFLOW           │
│                   │     │                   │
│ Surplus added     │     │ Deficit covered   │
│ to fund balance   │     │ from fund balance │
└───────────────────┘     └───────────────────┘
                                   │
                                   │ If fund balance
                                   │ insufficient:
                                   ▼
                          ┌───────────────────┐
                          │ SOCIALIZATION     │
                          │                   │
                          │ ADL or clawback   │
                          │ against profitable │
                          │ traders           │
                          └───────────────────┘

Settlement Timing

Insurance fund settlement is not always instantaneous. Different exchanges handle it differently:

Real-time settlement (most modern exchanges): The surplus or deficit is applied to the insurance fund balance immediately upon liquidation completion. This gives the most accurate real-time picture of fund health.

Periodic settlement (some legacy systems): Surpluses and deficits are batched and applied at fixed intervals (hourly, daily, or at the end of each settlement period). OKEx's 2018 clawback was settled on a weekly basis — the bad debt accumulated over the week and was socialized at settlement.

Hybrid: Real-time for surpluses (which grow the fund), periodic for deficits (which give the exchange time to assess whether the fund can cover the total shortfall before triggering ADL).

The Surplus Calculation

The surplus from a liquidation is straightforward in concept but nuanced in practice:

Liquidation Surplus Calculation:

Entry price:        $50,000 (long, 20x leverage)
Position size:      10 BTC
Margin deposited:   $25,000

Liquidation price:  $48,750  (MMF threshold)
Bankruptcy price:   $47,500  (equity = $0)

Actual fill (VWAP): $48,200

Surplus per BTC:    $48,200 - $47,500 = $700
Total surplus:      10 × $700 = $7,000 → Insurance Fund

Remaining margin returned to trader:
  $25,000 - (10 × ($50,000 - $48,200)) = $25,000 - $18,000 = $7,000
  (This $7,000 goes back to the trader, NOT the insurance fund)

Note the distinction: the surplus is the margin between the fill price and the bankruptcy price. The remaining margin returned to the trader is what is left of their original collateral after covering the position loss. These are different flows that go to different places.

What Happens When the Fund Runs Dry

When total deficits exceed the insurance fund balance, the exchange must socialize losses. The exact mechanism varies (see Insurance Funds for full detail), but from the engine's perspective, the settlement workflow adds an additional step:

Liquidation produces a deficit of $X
Insurance fund has balance $Y, where $Y < $X
Insurance fund covers $Y of the deficit
Remaining $X - $Y is flagged for socialization
ADL engine activates, selecting counterparties to absorb the shortfall
Counterparties' positions are force-closed at the bankruptcy price of the original liquidation
The shortfall is eliminated; the insurance fund balance is now $0

Some exchanges have additional safeguards. OKX triggers ADL proactively when the insurance fund drops by 30% from its daily peak within 8 hours — rather than waiting for full depletion. This preserves a buffer for subsequent liquidations.

8. DeFi Liquidation Engine Design: Keepers, Auctions, and OEV

DeFi liquidation engines face a fundamentally different design challenge than CeFi engines. The liquidation trigger, execution, and settlement all happen on-chain, in public, with permissionless participation.

The Aave V4 Model: Dutch Auctions for Liquidations

Aave V4 represents the most sophisticated DeFi liquidation engine design as of 2025. It replaces V3's fixed close factor with a dynamic system:

Target Health Factor: Instead of always closing 50% of a position (V3's fixed close factor), V4 calculates exactly how much debt needs to be repaid to restore the position to a governance-defined target health factor. This prevents over-liquidation — a $100K debt position that only needs $5K repaid to become healthy will not have $50K liquidated.

Scaling Liquidation Bonus: The bonus paid to keepers is no longer fixed. It scales inversely with the health factor:

Liquidation Bonus vs. Health Factor (Aave V4):

Bonus %
   │
   │
10%├─────────────────╲
   │                  ╲
 8%├───────────────────╲
   │                    ╲
 6%├─────────────────────╲
   │                      ╲
 4%├───────────────────────╲
   │                        ╲
 2%├─────────────────────────╲
   │                          ╲
 0%├───────────────────────────╲──
   └──────────────────────────────
   0.0    0.5    0.8    1.0
              Health Factor

   Lower HF = higher bonus = keepers rush to liquidate riskiest positions
   Higher HF = lower bonus = less urgency, less value extraction

This Dutch-auction structure means the most dangerous positions (lowest health factor) attract the most keeper attention because the reward is highest. Positions that are barely undercollateralized may sit for a few blocks until the bonus rises enough to be worth a keeper's gas costs. This is an elegant market-based solution to prioritization.

Dust Handling: V4 also addresses "dust" — positions so small that no keeper will bother liquidating them because the gas costs exceed the bonus. When remaining debt or collateral falls below a configurable DUST_LIQUIDATION_THRESHOLD (e.g., $1,000), liquidators can clear the entire position, preventing fragmented zombie dust accounts from accumulating.

Oracle Extractable Value (OEV)

Every time a price oracle updates, it may push some positions below their liquidation threshold. The keeper who acts on this update first captures the liquidation bonus. This creates a category of MEV called Oracle Extractable Value — the profit available to the first actor who sees an oracle update and executes the resulting liquidations.

OEV is substantial. Across Aave and Compound, roughly $45-50 million in liquidation bonuses have been paid out over their lifetimes. Much of this value flows to MEV searchers who use private relay infrastructure and sophisticated gas bidding strategies to win the execution priority.

Two competing approaches to recapturing OEV:

UMA Oval: Wraps Chainlink oracle updates and routes them through a Flashbots MEV-share auction. Before the price update reaches the lending protocol, searchers bid for the right to act on it. The winning bid is split between the protocol (~90%) and the block builder (~10%). The protocol captures value that would otherwise go entirely to keepers.

Pyth Express Relay: Bundles liquidation opportunities across multiple protocols into a single auction. Searchers bid on bundles of cross-protocol liquidation rights, creating deeper auction liquidity and higher revenue for participating protocols.

Both approaches recognize the same core problem: the fixed-bonus model of DeFi liquidations leaks enormous value to sophisticated keepers and MEV infrastructure, at the expense of borrowers and protocol treasuries.

9. Historical Engine Failures and Lessons

BitMEX Black Thursday (March 2020): The Engine That Wouldn't Stop

BitMEX's liquidation engine during the March 2020 crash processed over $1 billion in forced liquidations in 24 hours. The engine had no meaningful throttling — liquidation orders were sent as fast as accounts breached maintenance margin. The result:

The order book was completely overwhelmed
BitMEX's price diverged from other exchanges by over $1,000 (trading at $3,596 while Coinbase was near $4,500)
The engine's own selling was the primary driver of further price declines
BitMEX eventually went "offline for maintenance" — widely interpreted as a deliberate (and effective) circuit breaker

The irony: BitMEX's insurance fund actually grew during this event (it was well-capitalized), but the engine's execution quality was terrible. Positions that should have been liquidated at $5,500 were filled at $4,000 or below because the engine dumped everything into a book with no bids. The liquidated traders lost far more than necessary, and the cascade spread to every other exchange via index price feeds.

Lesson: A well-funded insurance fund does not compensate for poor execution quality. The engine's fill prices matter as much as the insurance fund's balance.

Hyperliquid's March 2025 Double Crisis

Hyperliquid experienced two liquidation engine failures in the same month:

ETH whale (March 12): A trader opened a $306M ETH long at up to 19.2x leverage, then withdrew margin to force their own liquidation. The HLP vault inherited the position and absorbed $4M in losses. The trader walked away with $1.86M in profit.

JELLY exploit (March 26): As described in Section 6, an attacker used coordinated positions in an illiquid token to force the HLP vault to inherit an unfillable short position, then pumped the token's price to extract $6.26M.

Both incidents exposed the same engine weakness: the engine had no circuit for rejecting positions it couldn't safely liquidate. It blindly transferred any failing position to the HLP vault regardless of size, market depth, or manipulation risk. The vault had no position limits, no per-asset exposure caps, and no mechanism to refuse a toxic inheritance.

Lesson: A backstop mechanism must have limits. An unlimited backstop is not a safety net — it is a target.

dYdX V3 YFI Attack (November 2023): Oracle Manipulation via the Engine

An attacker used dYdX's liquidation engine against its own insurance fund by:

Building large YFI long positions on dYdX
Manipulating YFI's spot price upward on external venues
Withdrawing unrealized gains as the mark price rose
Allowing positions to collapse, creating $9M in bad debt absorbed by the insurance fund

The engine processed these liquidations normally — the attacker's positions were correctly identified as undercollateralized and closed. The problem was upstream: the oracle accepted the manipulated price, and the engine had no mechanism to flag that a single low-liquidity asset was generating an anomalous volume of liquidations.

Lesson: Execution quality requires the engine to evaluate not just whether an account should be liquidated, but whether the liquidation itself is occurring under legitimate market conditions.

10. Engine Design Comparison: Major Exchanges

Dimension	Binance	Backpack	Hyperliquid	Aave V4	FTX (historical)
Architecture	Centralized, multi-tier	Centralized, 3-tier with throttling	On-chain, vault backstop	Smart contract, permissionless keepers	Centralized, 3-tier
Detection speed	Sub-ms	Sub-ms	Sub-second (block time)	Per-block (~12s L1)	Sub-ms
Chunk size	Tiered by position	10% per cycle	100% (or 20% if >$100K)	Calculated to target HF	10% per cycle
Cycle frequency	Sub-second	~2s (probabilistic)	Immediate	Per-block	6 seconds
Expected full liquidation time	Seconds	~20 seconds	Immediate (small) / 30s+ (large)	1-5 blocks (12-60s)	~60 seconds
On-book fill	IOC with price bands	IOC, 2% from index	Market order	N/A (keeper fills)	IOC, 1-5 bps through book
Backstop	Insurance fund + ADL	Designated BLPs	HLP vault	Keeper competition	Registered BLPs
Last resort	ADL	ADL (MF ascending)	ADL	Bad debt accumulation	ADL
Throttling	Yes (undisclosed)	Yes (50% prob, 10% size)	Partial (>$100K only)	Implicit (block time)	Yes (6s interval)
Position limits	Yes (tiered by leverage)	Yes	Post-March 2025: Yes	N/A (protocol-level)	Yes

What This Table Reveals

The most notable pattern is the speed-safety tradeoff. Hyperliquid prioritizes speed (immediate market order for the full position), which works for small positions but caused catastrophic outcomes for large ones. FTX prioritized safety (10% every 6 seconds), which minimized cascade risk but meant positions spent longer in the danger zone. Backpack occupies a middle ground (10% every ~2 seconds with randomization), which provides throttling without excessive delay.

Aave V4 is in a different category entirely — its "speed" is constrained by block time, but it compensates with economic incentives (Dutch auction bonuses) that ensure the most dangerous positions are prioritized by the keeper market.

11. Building a Better Engine: Design Principles

Based on historical failures and current best practices, a well-designed liquidation engine should follow these principles:

Principle 1: Throttle, Don't Dump

Never send the full position as a single order. Chunk it. Randomize the timing. Give the order book time to refill between fills. The marginal cost of a few extra seconds of delay is far less than the cost of a cascade triggered by a book-clearing liquidation order.

Principle 2: Layer Your Fill Strategies

On-book execution is the first line, not the only line. Backstop LPs provide off-book absorption for positions too large for the book. ADL is the final backstop. Each layer should have clear escalation triggers — not just "book is empty" but quantitative thresholds (MF dropping below a second threshold, position size exceeding available book depth by a multiple).

Principle 3: Limit Backstop Exposure

The backstop is not a dumping ground. Every backstop mechanism — whether it is an HLP vault, a BLP program, or an insurance fund — must have per-asset exposure limits, per-period capacity limits, and the ability to refuse positions that exceed safe thresholds. An unlimited backstop is a vulnerability.

Principle 4: Benchmark Execution Quality

Track fill prices against mark prices at trigger, against best available prices on other venues, and against theoretical prices with zero market impact. Publish these metrics (or at minimum, use them internally to tune engine parameters). An engine that is not measured cannot be improved.

Principle 5: Defend Against Manipulation

The engine must be aware that liquidations can be induced artificially. Position size limits relative to market depth, oracle manipulation detection, and cross-account linkage analysis are all necessary to prevent the engine from being weaponized against the exchange's own backstop.

Principle 6: Clean Up Zombie Accounts

Run continuous sweeps for accounts with negative equity. Settle them promptly against the insurance fund. Do not let bad debt accumulate silently — every zombie account is an unrecognized liability.

Key Takeaways

The liquidation engine is the exchange's most critical system. It runs during the moments of highest stress, with the highest financial stakes, and the least room for error. Engine design decisions — chunk size, cycle frequency, escalation thresholds — directly determine whether a market correction becomes a cascade.
Execution quality is the engine's report card, and almost no exchange publishes it. The gap between trigger price and fill price, aggregated across all liquidations, tells you more about an exchange's risk management than any marketing page.
Fill strategies must be layered. On-book, backstop, and ADL are not alternatives — they are sequential lines of defense. The boundaries between them (when to escalate, how fast, with what limits) are the most consequential design decisions.
DeFi keeper markets are evolving rapidly. Fixed liquidation bonuses are being replaced by Dutch auctions (Aave V4) and OEV capture mechanisms (UMA Oval, Pyth Express Relay) that route value back to protocols instead of MEV extractors.
Zombie accounts are a silent risk. Unfilled liquidations with negative equity accumulate bad debt that compounds over time. Proactive cleanup and formal settlement against the insurance fund are essential.
Historical failures are the best teacher. BitMEX's cascade-inducing engine in 2020, Hyperliquid's vault exploitation in 2025, and dYdX's oracle-manipulation-via-liquidation in 2023 each illustrate a different failure mode. The best engines are designed by people who have studied these failures in detail.

Liquidation Cascades — How individual liquidations chain-react into market-wide events
Insurance Funds — The funding, depletion, and socialization mechanics downstream of liquidation
Collateral — How collateral valuation and haircuts affect when liquidations trigger
Price Oracle — Mark price construction that determines liquidation thresholds
Circuit Breakers — Exchange-level mechanisms that pause or slow liquidation activity during extreme moves

Liquidation Engine Design & Execution Quality ​

TL;DR ​

1. What the Liquidation Engine Actually Does ​

2. Fill Strategies: How Liquidation Orders Get Executed ​

Strategy 1: On-Book Execution ​

Strategy 2: Backstop Liquidity Providers (BLPs) ​

Strategy 3: Auto-Deleveraging (ADL) ​

3. Latency Budgets and Timing ​

The Latency-Slippage Tradeoff ​

Concrete Example: 7 Seconds of Missed Price Improvement ​

CeFi vs. DeFi Latency Profiles ​

4. Keeper Networks and Liquidator Competition ​

How Keeper Competition Works ​

The Liquidation Bonus Problem ​

CeFi's "Internal Keeper" ​

5. Execution Quality: Measuring the Engine's Performance ​

The Core Metric: Fill Price vs. Trigger Price ​

What Good Looks Like ​

Benchmarking Against Available Market Prices ​

Why Exchanges Don't Publish This Data ​

6. Zombie Accounts and Negative Equity Cleanup ​

How Zombie Accounts Form ​

The Accumulation Problem ​

Cleanup Strategies ​

The Hyperliquid JELLY Incident: Zombie at Scale ​

7. Insurance Fund Settlement Workflow ​

The Flow: From Liquidation to Settlement ​

Settlement Timing ​

The Surplus Calculation ​

What Happens When the Fund Runs Dry ​

8. DeFi Liquidation Engine Design: Keepers, Auctions, and OEV ​

The Aave V4 Model: Dutch Auctions for Liquidations ​

Oracle Extractable Value (OEV) ​

9. Historical Engine Failures and Lessons ​

BitMEX Black Thursday (March 2020): The Engine That Wouldn't Stop ​

Hyperliquid's March 2025 Double Crisis ​

dYdX V3 YFI Attack (November 2023): Oracle Manipulation via the Engine ​

10. Engine Design Comparison: Major Exchanges ​

What This Table Reveals ​

11. Building a Better Engine: Design Principles ​

Principle 1: Throttle, Don't Dump ​

Principle 2: Layer Your Fill Strategies ​

Principle 3: Limit Backstop Exposure ​

Principle 4: Benchmark Execution Quality ​

Principle 5: Defend Against Manipulation ​

Principle 6: Clean Up Zombie Accounts ​

Key Takeaways ​

Related Reading ​