> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tplus.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# Liquidations & circuit breakers

> Liquidation mechanics, the price-state machine, and caps.

## 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](/trading/margin#requirements-and-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](/trading/margin#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](/api-reference/websockets)).

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.

```text theme={null}
sell_liquidation_price = reference_price * (1 + CF) / 2
buy_liquidation_price = reference_price * (1 + (2 - LF)) / 2
liquidation_quantity = abs(position_quantity)
```

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.

```mermaid theme={null}
flowchart TD
    A["Account below MM (liquidatable)"] --> B["Orderbook deleveraging"]
    B --> C{"Account solvent?"}
    C -->|Yes| Z["Done"]
    C -->|No| D["Backstop takeover:<br/>positions moved to a new<br/>backstop sub-account"]
    D --> E["Provisional collateral<br/>credited to 2% above IM"]
    E --> F

    subgraph loop["Backstop clearing + ADL loop"]
        F["Net offsetting positions<br/>across backstop sub-accounts"] --> G["Work positions down:<br/>sell clips into the orderbook"]
        G --> H{"Sub-account below IM?"}
        H -->|No| L{"All positions closed?"}
        H -->|Yes| I["ADL ranked counterparties<br/>to restore 2% above IM"]
        I --> J{"Buffer restored?"}
        J -->|Yes| L
        J -->|"No: ADL exhausted"| K["Post additional<br/>backstop collateral"]
        K --> L
        L -->|No| F
    end

    L -->|Yes| M["Settle: collateral returned to restakers;<br/>net loss covered by slashing"]
```

### 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.

```text theme={null}
target_collateral = initial_margin_requirement * 1.02
```

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:

```
ADL score = account leverage * position return

  account leverage = total notional / account equity
  position return  = position PnL / position notional
```

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.

| State           | Condition                                                                                          | Effect                                                       |
| --------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Warming up      | New asset; needs consecutive valid oracle updates                                                  | Risk-increasing activity blocked                             |
| Ready           | Oracle fresh                                                                                       | All activity allowed                                         |
| Degraded        | Oracle stale; fresh mark or orderbook [impact price](/trading/fees-and-rates#funding-rates) exists | Risk-increasing trades blocked; risk-reducing trades allowed |
| Circuit breaker | No usable price                                                                                    | Margin trading and liquidation blocked for the asset         |

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](/trading/margin#protocol-caps).

| Cap                                                      | Hit when                                                                        | Effect                                                                                               |
| -------------------------------------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Total open interest (`max_total_open_interest_notional`) | Aggregate open-interest notional - at mark or oracle - would rise above the cap | Risk-increasing leveraged trades reject; the market is effectively reduce-only, while spot continues |
| Spot-margin open interest (`max_spot_open_interest`)     | Net directional margin exposure would rise above the cap                        | `im_factor` tightens as exposure nears the cap; trades past it reject                                |
| Collateral (`max_collateral`)                            | Collateral held in margin sub-accounts would rise above the cap                 | Further collateralizing transfers and trades reject                                                  |

### Flow caps

These bound how fast value enters or leaves an asset's pool.

| Cap                                       | Hit when                                                                                                            | Effect                                                                                                                                  | Recovery                                                   |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Deposit (`maxDeposits`, `max1hrDeposits`) | Total `(asset, chain)` deposits would exceed `maxDeposits`, or trailing-hour deposits would exceed `max1hrDeposits` | The deposit is still credited, but as an isolated, non-fungible `Address(token@chain)` balance with no leverage                         | Total or rolling deposits fall below the cap               |
| Utilization (`max_utilization`)           | Borrow utilization of the asset's pool reaches the cap                                                              | Settlements that would move the asset out of the vault are blocked, unless offsetting inflows in the same batch net the outflow to zero | Utilization falls as borrows are repaid or deposits arrive |

Deposit isolation is described under [asset fungibility](/funds/fungibility#deposit-caps-and-isolation): an isolated balance becomes fungible with the pooled asset once caps allow. Utilization is the same ratio that drives [borrow rates](/trading/fees-and-rates#borrow-rates); its effect on settlements is detailed under [settlement utilization caps](/funds/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.