Skip to main content

Liquidation conditions

Maintenance margin is checked on a fixed interval and on price updates (price-triggered checks are batched every 10 ms). The margin engine computes MM surplus over the whole sub-account. An account is liquidatable only when it has borrows, has no circuit-broken collateral, and MM surplus is below zero. Monitor your own account via the margin endpoints.

Liquidation execution

Liquidations execute on the open orderbook; there is no privileged liquidation counterparty. Any participant resting liquidity can take the other side. So that participants can quote against expected liquidations, the protocol streams aggregate at-risk positions over an authenticated WebSocket. This is a global aggregate broadcast, not a user-filtered feed. Per asset, it reports the aggregate quantity nearing liquidation on each side - long (to be sold) and short (to be bought) - plus estimated liquidation prices. Quantities are summed across all at-risk accounts per asset and liquidation prices are estimated, so no address or individual position is exposed. Stream: GET /liquidation/at_risk/ws (WebSocket streams). When an account becomes liquidatable:
  1. The account’s open orders are canceled.
  2. The system submits reduce-only IOC limit orders against each position: opposite side, full position size. The limit price is the midpoint between a reference price and that price scaled by the asset’s collateral factor (sells) or liability factor (buys), so it crosses resting liquidity. The reference price is whichever usable last-trade or oracle price reaches deeper into the book: the lower for sells, the higher for buys. The liquidation path excludes sources that fail the price-manager freshness checks (last trade: 60 seconds; oracle: 1 hour), and the same price manager will not return stored prices after its 2-hour TTL.
  3. Clearing validates every liquidation fill: the account must be below maintenance margin pre-trade, the fill must reduce or maintain risk, and it cannot exceed position size.
This initial deleveraging process is carried out within an Order Management System component colocated with the orderbook to minimize time-to-liquidate. A 5-second per-account cooldown prevents an account from being re-triggered while a prior liquidation is still settling.

Backstop and auto-deleveraging

Orderbook deleveraging falls short when the book is too thin to absorb an account’s positions at acceptable prices. Whatever it cannot clear is moved to the protocol backstop - a liquidation operator account funded by restakers - which inherits the positions and clears them over time. Clearing and auto-deleveraging (ADL) are a single loop, not separate phases. The backstop works inherited positions down through the market, and ADL escalates whenever a sub-account’s solvency degrades faster than clearing can repair it.

Backstop takeover

  1. The clearing engine spawns a new sub-account inside the backstop for the delinquent account, isolating its risk from other liquidations.
  2. The delinquent account’s remaining holdings and positions are transferred into that sub-account in one move.
  3. Provisional collateral from restaked capital is credited to bring the sub-account to 2% above its IM requirement. The collateral is provisional: capital is spent - and restakers slashed - only if it must actually cover a loss while clearing.
Example: positions requiring 100,000 USD of initial margin are collateralized to 102,000 USD.

Clearing loop

The backstop runs a continuous loop on each inherited sub-account:
  1. Net internally. Offsetting positions are consolidated across the backstop’s own sub-accounts without trading - a long BTC from one liquidation cancels a short BTC from another. This is a backstop-only privilege; a moved position takes on its destination sub-account’s margin mode.
  2. Work positions down. Remaining exposure is sold into the orderbook in clips over time, sized to avoid moving the market against the backstop.
  3. Watch solvency. Each sub-account’s IM surplus is monitored continuously. Adverse price moves or thin liquidity can push a sub-account back below IM faster than clearing reduces it.
  4. Escalate to ADL. When a sub-account falls below IM, ADL closes ranked counterparty positions to restore it to 2% above IM, then clearing resumes. ADL re-triggers as often as price and position changes push the sub-account back under IM.
  5. Post collateral as a last resort. Only when ADL cannot find enough eligible counterparties to restore the buffer does the protocol post additional backstop collateral for the shortfall.
When a sub-account’s positions are fully closed, its remaining collateral is returned to restakers. A net loss is covered by slashing restaked capital. Restakers absorb that tail risk in exchange for clearing profits and a share of protocol fees.

Auto-deleveraging (ADL)

ADL is the escalation inside the clearing loop: it forcibly closes profitable, highly leveraged counterparty positions to restore a backstop sub-account to 2% above IM when clearing alone cannot keep pace. Eligibility. Only positions on the side opposite the backstop’s position in that market, and only those currently in profit, are eligible. A break-even or losing position is never auto-deleveraged. Ranking. Eligible positions are closed worst-offender first, by score:
The most profitable, most-leveraged counterparties rank highest. The ranking refreshes as positions change and as prices move. Example: an account at 4x leverage with a 30% profitable position scores 4 * 30% = 1.2, ranking ahead of one at 3x leverage with a 20% position (score 0.6). Amount. ADL works one market at a time, largest backstop exposure first. Within a market it takes counterparties in rank order until the sub-account returns to the 2% IM buffer or hits the per-market cap (max_adl). The last position taken can be partially closed; the rest close in full. Any remaining shortfall carries to the next-largest market. Example: to shed 40,000 USD of exposure when the highest-ranked eligible counterparty holds 25,000 USD, ADL closes that position in full, then 15,000 USD of the next. Price. ADL executes at the price that favors the backstop: the lower of oracle and mark when the backstop is short, the higher when it is long. Example: backstop short with oracle 100 USD and mark 98 USD -> ADL at 98 USD; backstop long with the same prices -> 100 USD.

Circuit breakers

Each asset’s price feed runs through a state machine that degrades automatically when prices stop arriving. Oracle prices go stale after 1 hour; trade-derived mark prices after 60 seconds. A stale source must deliver consecutive fresh updates before it counts as recovered, which prevents flapping. Spot trading is always allowed so an oracle can always recover to at least degraded even if the oracle is completely lost. Consequences:
  • An account holding collateral in a circuit-broken asset cannot be liquidated. If the broken asset is only borrowed, liquidation proceeds.
  • In margin math, circuit-broken collateral is valued at zero; borrows count in full.

Caps and halts

Liquidation, backstopping, ADL, and circuit breakers are reactive - they contain risk after it appears. Caps are preventive: per-asset limits that bound how much exposure, collateral, and flow the protocol accepts in the first place, so no single asset can accumulate enough risk to threaten the system. Every cap rejects only the change that would push past it; reducing or unwinding always passes, and each cap clears on its own as the underlying measure falls back below the threshold.

Exposure caps

These bound how much leveraged risk an asset can carry. They are evaluated on the proposed post-trade state and detailed under protocol caps.

Flow caps

These bound how fast value enters or leaves an asset’s pool. Deposit isolation is described under asset fungibility: an isolated balance becomes fungible with the pooled asset once caps allow. Utilization is the same ratio that drives borrow rates; its effect on settlements is detailed under settlement utilization caps. Risk-parameter caps are served by GET /registry/risk-parameters; deposit caps by GET /registry/assets. All values are per-asset (or per (asset, chain)) and set by governance - read them from the registry rather than hardcoding.