Crypto Exchange Liquidation Engine: Design and Risk Controls

Table of Contents

• Why the Liquidation Engine Decides Your Survival
• Margin Math Every Founder Should Understand
• Mark Price and Index Design
• The Liquidation Pipeline Step by Step
• Insurance Fund and Auto-Deleveraging
• Risk Limits and Leverage Brackets
• Performance and Fault Tolerance
• Transparency and Regulatory Expectations
• Design Choices Compared
• Launch Checklist
• Frequently Asked Questions
• Bottom Line and Next Steps

Why the Liquidation Engine Decides Your Survival

A spot exchange that goes down for an hour loses fees and some goodwill. A derivatives venue whose risk engine fails for an hour can lose its entire insurance fund and end up owing money to its own users. The crypto exchange liquidation engine is the component that stands between leveraged positions and that outcome, which is why experienced operators treat it as the most important system they run, ahead of the order book itself.

The failure pattern repeats across market cycles. A sharp move arrives, positions on the wrong side cross their maintenance margin faster than the engine can close them, closing orders hit a thinning book, and the venue absorbs the gap between the price it achieved and the price at which the account ran out of collateral. In March 2020, through 2022, and again in the October 2025 cascade, venues with slow or poorly tuned engines reported bad debt, socialized losses, or emergency auto-deleveraging, while better-designed engines closed positions in time and kept their insurance funds intact. The exact figures vary by venue and are disputed, so treat the lesson, not the numbers, as the takeaway: the quality of your engine sets the ceiling on how much leverage you can safely offer.

Understanding how liquidation works on a futures exchange is therefore not optional reading for a founder. It determines product design, fee design, capital reserves, and the leverage you advertise. This guide covers the mechanics and the design choices, and it is the companion to our deeper piece on exchange matching engine architecture, which handles the order flow the liquidation engine sits beside.

Margin Math Every Founder Should Understand

Every leveraged product rests on a handful of definitions. Get these consistent across the engine, the UI and the API, or users will dispute every liquidation.

Initial and maintenance margin

Initial margin is the collateral required to open a position. At 10x leverage the initial margin rate is 10 percent of notional; at 50x it is 2 percent. Maintenance margin is the smaller amount that must remain to keep the position open. Typical maintenance rates run from 0.4 percent for small positions in liquid pairs to 5 percent or more for large positions or thin markets.

Margin ratio and liquidation price

The engine evaluates one number per position or account: the margin ratio, defined as maintenance margin divided by available collateral plus unrealized profit or loss. When the ratio reaches 100 percent the position is eligible for liquidation. Expressed as a price, the maintenance margin and liquidation price for isolated positions are:

• Liquidation price (long) = Entry price × (1 − Initial margin rate + Maintenance margin rate)
• Liquidation price (short) = Entry price × (1 + Initial margin rate − Maintenance margin rate)

A 10x long on BTC at 60,000 with a 0.5 percent maintenance rate liquidates near 54,300, not at 54,000, because the maintenance buffer sits above the bankruptcy price. That buffer is what gives the engine room to close the position before collateral hits zero.

Isolated versus cross margin

Isolated margin pins collateral to one position, so a liquidation can only consume that collateral. Cross margin lets the whole account balance backstop every position, which delays liquidation but means one bad position can take the account down. The engine must support both and must compute cross-margin ratios at the account level, netting unrealized gains on winners against losses on losers. Most venues launch isolated first and add cross once the engine has proven itself under load, a sequencing we recommend to operators building on perpetual futures infrastructure.

Mark Price and Index Design

The most common design mistake on new venues is liquidating against the last traded price on the venue’s own book. On a thin book a single market order can print a price 3 percent away from fair value for a few milliseconds. If the engine liquidates on that print, an attacker can trigger a cascade for the cost of one order, a pattern documented in our guide to market manipulation detection on exchanges.

The fix is a mark price built from two inputs:

1. Index price: a volume-weighted median of the same asset across several reference venues, with outlier rejection when one source deviates more than a set threshold and a staleness check that drops any feed older than a few seconds.
2. Basis component: for perpetuals, a moving average of the premium of your own order book over the index, bounded so a momentary squeeze cannot drag the mark far from the index.

Mark price = Index price × (1 + Bounded basis). Unrealized PnL, margin ratio and liquidation triggers all use mark price. Last price is only used for executing the closing orders. Publish the index composition and update cadence on your documentation pages; regulators and sophisticated traders both ask for it.

The Liquidation Pipeline Step by Step

A production crypto exchange liquidation engine is a pipeline, not a single rule. Each stage has its own failure modes.

1. Risk monitor loop

A dedicated process holds every open position in memory, subscribes to mark-price updates, and recomputes margin ratios on each tick. Accounts are kept in a sorted structure by ratio so the engine can scan only those near the threshold rather than the whole book on every update.

2. Warning thresholds

Before liquidation, the engine emits warnings at configurable ratios, typically 80 and 90 percent, through push notification, email and a WebSocket event. Warnings reduce liquidations, reduce disputes, and give users a chance to add margin.

3. Trigger and position takeover

At 100 percent the position is transferred to the liquidation account. The user’s open orders on that symbol are cancelled first so stale orders cannot interfere. The takeover is logged with the mark price, the margin ratio and a timestamp; this record is what support and compliance rely on later.

4. Partial liquidation

Closing a large position in one shot moves the market against the venue. A partial liquidation engine design closes only enough of the position to restore the margin ratio to a safe level, often with tiered maintenance rates that fall as the position shrinks. Small retail positions below a notional threshold are closed in full because partial handling is not worth the complexity.

5. Order placement

The engine submits closing orders to the matching engine. The choice between a market order and a limit order at the bankruptcy price is a trade-off between certainty and slippage, covered in the comparison table below. Either way the orders must bypass normal user rate limits and carry a reduce-only flag.

6. Liquidation fee and settlement

A liquidation fee, commonly 0.5 to 1.5 percent of notional, is charged to the liquidated account and credited to the insurance fund. Any collateral left after the close is returned to the user. If the close executed below the bankruptcy price, the shortfall is booked as bad debt and handed to the insurance fund.

The fee level is a product decision as much as a risk decision, and it belongs in the same spreadsheet as your maker and taker rates. Our guide to crypto exchange fee structure design covers how liquidation fees interact with the rest of the schedule.

Insurance Fund and Auto-Deleveraging

The insurance fund and auto-deleveraging mechanism together form the venue’s loss waterfall.

Insurance fund. Funded by liquidation fees and by the positive slippage when a position closes better than its bankruptcy price. Its job is to absorb shortfalls so profitable traders are paid in full. Operators should seed it with their own capital at launch, since fee income takes months to build a meaningful balance, and should publish its size and daily change. How much to seed relative to open interest is a capital-planning question we address in our piece on exchange insurance and risk coverage.

Auto-deleveraging (ADL). If the fund cannot cover a shortfall, the engine closes the positions of the most profitable, most leveraged traders on the opposite side at the bankruptcy price of the failed position. Each trader sees an ADL indicator in the UI showing their rank in the queue. ADL is legal and widely used, but every ADL event costs you institutional users, so treat it as an alarm, not a routine.

Socialized losses. Spreading a shortfall across all profitable traders is the older, cruder alternative. Avoid it. The reputational cost is high and some regulators now treat undisclosed socialization as a conduct issue.

Bad-debt accounting matters too. Every shortfall should be recorded as a ledger entry against the insurance fund, not quietly netted inside position records, so the fund balance shown to users reconciles with the books.

Risk Limits and Leverage Brackets

Uniform leverage across all position sizes is how a venue ends up with a single account that can sink the fund. Leverage brackets tie maximum leverage and maintenance margin to position notional:

Position notional (USDT)	Max leverage	Maintenance margin
Up to 50,000	100x	0.5%
50,000 to 250,000	50x	1.0%
250,000 to 1,000,000	20x	2.5%
1,000,000 to 5,000,000	10x	5.0%
Above 5,000,000	5x	10.0%

Brackets should be per symbol, since a position that is small for BTC is enormous for a mid-cap altcoin, and they should be editable without a deploy. Operators running Codono manage brackets, maintenance rates, liquidation fees and insurance-fund parameters from the exchange admin panel, with every change logged against the admin who made it.

Add account-level limits as well: maximum open interest per user, maximum total open interest per symbol relative to available liquidity, and a cap on new positions when the insurance fund falls below a threshold. The liquidity side of that equation is covered in our guide to liquidity management for exchanges.

Performance and Fault Tolerance

The engine is only as good as its worst minute. Design for the cascade, not the average day.

Latency. Mark price updates arrive several times per second during volatility. The engine must re-evaluate every at-risk account on each update, so the critical path from price tick to closing order should stay well under 100 milliseconds. Keep positions in memory, avoid database reads on the hot path, and write audit records asynchronously.

Throughput. A 10 percent move can push thousands of accounts past their thresholds within seconds. Batch closing orders, prioritize by margin ratio, and give liquidation traffic a dedicated lane into the matching engine so it is never queued behind retail order flow. The scaling patterns are the same ones we describe for high-throughput exchange infrastructure.

Stalls. If the engine stops, positions keep losing money with no one closing them. Run it as an active-passive pair with a heartbeat; if the primary misses two heartbeats the standby takes over from a replicated snapshot. Alert loudly on any gap in mark-price updates.

Circuit breakers. Define automatic actions for extreme conditions: pause new position opening when the index deviates more than a set percentage from the mark, widen the basis bound during exchange-wide outages on reference venues, and expose a manual kill switch that halts liquidations while keeping the engine’s view of risk live. Document when each breaker fires so support can explain it.

Funding-rate interaction. For perpetuals, funding payments move collateral in and out of accounts every interval. The engine must apply funding before evaluating margin at each settlement, or an account can be liquidated by a payment it has not yet seen. Spot margin products have the analogous issue with interest accrual, which the same engine should handle alongside spot order flow.

Transparency and Regulatory Expectations

Users accept liquidations they can predict. They litigate liquidations they cannot.

In the UI. Show the estimated liquidation price on the order ticket before the trade, on the open positions table, and in the margin-add dialog. Show the mark price and the index price side by side. Show the ADL rank indicator on every position.

In the API. Expose liquidation price, margin ratio, mark price and insurance fund balance as fields, and emit a distinct event type for liquidation warnings and executions so algorithmic clients can react.

In the records. Keep an immutable log of every liquidation with the triggering mark price, the index inputs at that moment, the orders placed, the fills, the fee, and any insurance-fund draw. This is the file you hand to a complaints team, an auditor or a regulator.

Regulators are increasingly specific. MiCA requires crypto-asset service providers to act fairly and to disclose risks clearly, and supervisors have read that to include liquidation methodology. VARA’s rulebooks in Dubai call for documented risk management and client disclosure for leveraged products. Other jurisdictions restrict retail leverage outright. Treat these as orientation and confirm the current position with local counsel before launch, because leverage rules change faster than most of the regulatory stack.

Design Choices Compared

Decision	Option A	Option B	Our recommendation
Trigger price	Last price on own book	Mark price from multi-venue index	Mark price, always
Closing order type	Market order	Limit at bankruptcy price, escalating	Limit first for large positions, market for small
Close size	Full position	Tiered partial liquidation	Partial above a notional threshold
Loss backstop	Socialized losses	Insurance fund, then ADL	Insurance fund with published balance, ADL as alarm
Leverage policy	Flat max leverage	Brackets by notional and symbol	Brackets, editable from admin
Engine topology	Inline with matching engine	Separate process with dedicated lane	Separate process, active-passive
Parameter changes	Code deploy	Admin-configurable with audit log	Admin-configurable

Launch Checklist

• Maintenance and initial margin rates defined per symbol and per bracket
• Liquidation price formula identical in engine, UI and API
• Mark price built from a multi-venue index with outlier and staleness rules
• Basis component bounded and published
• Warning events at two thresholds before liquidation
• Partial liquidation tiers above a notional threshold
• Closing orders flagged reduce-only with a dedicated lane into matching
• Liquidation fee routed to a seeded, published insurance fund
• ADL queue with a visible per-position rank indicator
• Bad debt recorded as ledger entries against the fund
• Active-passive engine with heartbeat failover and stall alerts
• Circuit breakers and a manual kill switch, each documented
• Funding and interest applied before margin evaluation
• Immutable liquidation log with index inputs captured
• Leverage disclosures reviewed against the rules of each target market

Frequently Asked Questions

What is a crypto exchange liquidation engine?

It is the risk component that continuously checks every leveraged position against its maintenance margin and, when a position can no longer cover potential losses, closes it in an orderly way. It coordinates the trigger, the closing orders, the liquidation fee, the insurance fund and, as a last resort, auto-deleveraging so the exchange does not end up holding bad debt.

What is the difference between mark price and last price for liquidation?

Last price is simply the most recent trade on your own order book, which a single large order can move. Mark price blends an external index from several reference venues with a funding-based basis, so it reflects fair value. Serious venues liquidate on mark price, never on last price, because that removes the incentive to manipulate a thin book to trigger liquidations.

Why does an exchange need an insurance fund if positions are liquidated?

Liquidation is not instant. During fast moves the engine may close a position below its bankruptcy price, leaving a shortfall. The insurance fund, built from liquidation fees and the positive slippage of profitable liquidations, absorbs that shortfall. If the fund runs dry the venue must fall back to auto-deleveraging or socialized losses, both of which damage trust.

How fast does a liquidation engine need to run?

In calm markets a one-second recheck cycle is adequate. During volatility the engine must re-evaluate every at-risk account on every mark-price update, which in practice means hundreds of milliseconds or faster, with batching and prioritization by margin ratio so the most endangered positions are handled first.

Bottom Line and Next Steps

Leverage is the highest-margin product most exchanges will ever offer, and the liquidation engine is the only thing that makes it a product rather than a liability. The venues that survive volatile weeks are the ones that liquidate on a manipulation-resistant mark price, close positions in tiers, keep a funded and transparent insurance fund, and run the engine as a hardened, separately monitored service with controls an operator can tune without a deploy.

If you are evaluating platforms, ask to see the engine’s behavior under a simulated 15 percent move, the insurance-fund accounting, and the admin screens for brackets and fees. Codono’s margin trading module and perpetual futures engine ship with these controls built in, and the same risk core runs across the wider exchange platform.

Ready to launch leveraged products with a risk engine you can trust? Request a demo or explore the perpetual futures software to see the liquidation engine in action.

---

The Codono Team has been building crypto exchange infrastructure since 2017. This guide reflects production experience across 250+ exchanges and the risk-engine requirements of modern derivatives venues.