Liquidation engine
Why Liquidation Design Matters
Every liquidation engine has to make a tradeoff: liquidate quickly enough to protect solvency, while keeping guardrails against oracle misprints, or extremely short lived price spikes.
In a volatile market, bad oracle data or sudden price wicks can create sudden crises. A DEX that instantly liquidates based on a single bad price tick can wipe out healthy traders. Furthermore, liquidating at extreme temporary price can create bad debt, which can be dangerous for the protocol itself.
By design, Drift’s liquidation engine revolves around 3 key areas:
- Partial liquidation, breaking liquidations into multiple steps.
- Speed, adjusting liquidation speed based on account health.
- Price, filters extreme wicks through oracle based guardrails.
Partial Liquidations
To limit risk and reduce the severity of liquidation events, Drift uses partial liquidation. Instead of closing an entire position at once, the system liquidates portions over time, throttled across multiple slots. This gives the account a chance to recover as new oracle prices arrive, while ensuring the system remains solvent.
The buffer system ensures that users aren’t liquidated right back at maintenance margin. Instead, Drift places liquidated accounts slightly behind a safe margin buffer, far enough to reduce immediate risk but close enough to stay competitive for traders using leverage.
How Drift handles speed
Drift’s liquidation engine liquidates progressively, adjusting speed based on how “unhealthy” the user’s account is and how the price evolves after the liquidation starts.
When a liquidation begins, Drift records how much margin has already been freed. From that point:
- If the price keeps moving against the user, the system accelerates liquidation.
- If the price moves in favor of the user, liquidation slows down, since the position is recovering naturally.
This happens over a slot-based window (set to 25 by default).
From empirical data, even a few slots of delay can prevent unnecessary liquidations during a temporary wick. The goal isn’t to pause liquidation, but to make it responsive, reacting quickly when needed and backing off when conditions improve.
How Drift handles price
Liquidations on Drift aren’t triggered directly by the mark price, instead, the engine references the oracle price for liquidation thresholds. The engine compares the current oracle price with the five-minute average oracle price(TWAP) to detect outliers.
If the oracle price deviates 50% or more from the 5min TWAP, liquidations are temporarily blocked. This gives time for additional oracle updates to confirm whether the move is real. Once the deviation narrows, normal liquidation resumes, following the same pacing described above.
Insurance Fund as a safety net
Even with all these protections, extreme events can still create negative balances. That’s where Drift’s Insurance Fund comes in. It’s the protocol’s first backstop against insolvency.
The Insurance Fund covers trader losses that exceed their account balances. Anyone can stake assets, like USDC, SOL, BTC, or ETH, into the fund and earn a share of Drift’s trading and liquidation fees.
How It’s Used
- Spot markets: Covered in full.
- Perpetual markets: Covered up to a set per-market limit.
Each asset has its own Insurance Fund. For example, the USDC fund backs both perps and borrow/lend, while SOL, BTC, and ETH funds cover borrow/lend losses specific to those assets.
The fund accumulates capital through user staking (deposits) and from a portion of trading, borrowing, and liquidation fees
How Perp Bankruptcy Resolution Works
Drift follows a clear hierarchy:
- External Insurance Fund (USDC) covers the debt up to its per market limit.
- Internal Insurance (the vAMM’s lifetime profit for that market) covers remaining losses.
- If both are exhausted, socialized loss applies pro rata across all open positions within that market.
This structure ensures that insolvency events are handled fairly and predictably. The system aims to keep socialized losses as close to zero as possible.