> For the complete documentation index, see [llms.txt](https://support.backpack.exchange/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.backpack.exchange/technical-docs/vn/trading/thanh-ly.md).

# Thanh lý

## Liquidation

### Tổng Quan

Thanh lý là quá trình hệ thống quản lý rủi ro tự động giảm hoặc đóng vị thế khi ký quỹ của tài khoản giảm xuống dưới mức yêu cầu duy trì. Backpack sử dụng cơ chế thanh lý nhiều tầng nhằm:

1. Giảm thiểu tổn thất cho người dùng thông qua cơ chế giảm vị thế dần dần
2. Ưu tiên khớp lệnh trên orderbook khi có thể
3. Ngăn ngừa rủi ro hệ thống thông qua cơ chế backstop
4. Đảm bảo khả năng thanh toán của nền tảng trong điều kiện thị trường cực đoan

Tài sản, vị thế và ký quỹ được định giá theo **mark price** để tránh thao túng giá thông qua last-trade price. Thanh lý có thể được thực hiện trên orderbook hoặc thông qua các cơ chế waterfall khác.

***

### Điều Kiện Kích Hoạt Thanh Lý

#### Khi Nào Thanh Lý Xảy Ra?

Thanh lý bắt đầu khi **Maintenance Margin Ratio (MMR) đạt 100%**.

{% code collapsedlinecount="10" %}

```
MMR = Account MMF / Account Margin Fraction
```

{% endcode %}

Trong đó:

* Account Margin Fraction = Net Equity / Total Exposure Notional
* Account MMF = Σ(Notional Position Size × Position MMF) / Total Exposure Notional

#### Điều Gì Xảy Ra Khi Bị Kích Hoạt?

Khi MMR đạt 100%, hệ thống sẽ:

1. **Huỷ toàn bộ lệnh đang mở** — giải phóng margin bị khoá
2. **Hoàn trả khoản vay và đóng vị thế song song**

#### Giá Thanh Lý Ước Tính vs Thực Tế

Giá thanh lý hiển thị trên giao diện chỉ mang tính **tham khảo**, giả định:

* Không thay đổi các vị thế khác
* Không thay đổi tài sản thế chấp
* Không có funding hoặc lãi phát sinh
* Mark price của tài sản khác không thay đổi

Thanh lý thực tế xảy ra khi **MMR ≥ 100%**, dựa trên toàn bộ trạng thái sub-account.

Với tài khoản có nhiều vị thế, tài sản thế chấp không phải USD hoặc có khoản vay đang hoạt động, hệ thống có thể không hiển thị chính xác giá thanh lý ước tính.

***

### Cơ Chế Liquidation Waterfall

Backpack sử dụng cơ chế 3 tầng. Mỗi tầng chỉ kích hoạt nếu tầng trước đó không thể khôi phục margin.

{% code collapsedlinecount="10" %}

```
┌─────────────────────────────────────────────────────────────────┐
│                    LIQUIDATION WATERFALL                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Giai đoạn 1: Thanh lý qua Orderbook                            │
│  ├── Reduce-only orders placed on public orderbook              │
│  ├── Executes against available market liquidity                │
│  ├── Price bands prevent execution at extreme prices            │
│  └── Gradual reduction until margin health restored             │
│                           │                                     │
│                           ▼                                     │
│  Stage 2: BACKSTOP LIQUIDITY PROVIDERS (BLPs)                   │
│  ├── Kích hoạt khi: tỷ lệ ký quỹ vị thế thấp hơn ACMF                              │
│  ├── Positions transfer to BLP participants                     │
│  ├── Portion of remaining equity paid to backstop fund          │
│  └── BLPs assume position management                            │
│                           │                                     │
│                           ▼                                     │
│  Stage 3: AUTO-DELEVERAGING (ADL)                               │
│  ├── Kích hoạt khi: tỷ lệ ký quỹ vị thế thấp hơn ACMF và không có khả năng tiếp nhận từ BLP          │
│  ├── Profitable counterparties' positions partially closed      │
│  ├── No account or user restrictions after priority scoring     │
│  └── Last resort to maintain system solvency                    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

{% endcode %}

> **Price Display Note:** Backstop and ADL transactions are executed off-book (outside the public orderbook). As a result, these execution prices are not reflected in K-line charts.

**Stage 1: Orderbook Liquidation**

**Trigger:** MMR ≥ 100%

**Mechanism:**

* Liquidation engine places **reduce-only market orders** on the public orderbook
* Orders execute against resting liquidity at prevailing market prices
* Liquidation runs in a loop (1 second per tick, 50% probability each tick), reducing 10% of the position per iteration, capped by liquidation capacity
* Process continues until MMR < 100%

**Protections:**

* **Price bands** prevent execution at manipulated prices
* **Gradual reduction** minimizes market impact
* Liquidations are visible on the public orderbook and trade feed

**Partial Liquidation:** The system liquidates only the minimum amount necessary to restore margin health. This means:

* You may retain a reduced position after liquidation
* Remaining equity stays in your account
* If price continues moving against you, additional liquidations may occur

**Stage 2: Backstop Liquidity Providers (BLPs)**

**Điều kiện kích hoạt:** Tỷ lệ ký quỹ của vị thế thấp hơn **Tỷ lệ ký quỹ tự động đóng (ACMF)**

**Auto-Close Margin Fraction Calculation:**

{% code collapsedlinecount="10" %}

```
ACMF = max(Position MMF / ACMF Divisor, Position MMF - ACMF Offset)
```

{% endcode %}

The ACMF is always less than the MMF, creating a buffer zone between maintenance margin breach and BLP handoff.

**Mechanism:**

1. Remaining position is transferred to Backstop Liquidity Providers
2. A portion of remaining account equity is paid to the backstop liquidity fund
3. BLPs assume management of the position
4. Account margin is zeroed (account remains active for trading) or reduced to safe margin levels

**BLP Requirements:**

* Minimum balance requirements on platform
* Commitment to absorb specified liquidation volumes
* May be required to meet market making standards

**Stage 3: Auto-Deleveraging (ADL)**

See Auto-Deleveraging (ADL) section for complete details.

***

### Ký quỹ được bảo vệ (Protected Margin)

Backpack sử dụng cơ chế ký quỹ chéo, trong đó toàn bộ tài sản thế chấp hỗ trợ tất cả các vị thế đang mở trong cùng một tài khoản phụ. Cơ chế này không thay đổi cho đến khi tài khoản không còn đáp ứng yêu cầu ký quỹ duy trì và bắt đầu bị thanh lý.

Khi quá trình thanh lý bắt đầu, ký quỹ duy trì của từng vị thế được bảo vệ và không thể dùng để bù đắp khoản lỗ từ các vị thế khác.

**Cách hoạt động của ký quỹ được bảo vệ**

* **Khoản lỗ gắn với từng vị thế:** Khoản lỗ do vị thế nào phát sinh sẽ do vị thế đó chịu. Nếu tỷ lệ ký quỹ của một vị thế thấp hơn Tỷ lệ ký quỹ tự động đóng (ACMF), vị thế đó có thể được tự động đóng thông qua Nhà cung cấp thanh khoản dự phòng (BLP) hoặc cơ chế Tự động giảm đòn bẩy (ADL).
* **Bảo vệ các vị thế khác:** Các vị thế khác được đánh giá dựa trên ký quỹ duy trì riêng và không bị tự động đóng thông qua BLP hoặc ADL chỉ vì một vị thế khác chịu khoản lỗ lớn.
* **Thanh lý qua sổ lệnh vẫn được áp dụng:** Các vị thế khác vẫn có thể bị giảm một phần qua sổ lệnh cho đến khi sức khỏe ký quỹ của tài khoản được khôi phục.

**Ví dụ**

{% code collapsedlinecount="10" %}

```
Trạng thái ban đầu:
  - Nhà giao dịch nắm giữ các vị thế BTC-PERP và DOGE-PERP
  - Giá DOGE giảm mạnh
  - Tài khoản không còn đáp ứng yêu cầu ký quỹ duy trì

Thanh lý:
  - Tài khoản bắt đầu bị thanh lý
  - Khoản lỗ vượt ngưỡng tự động đóng

Trước đây:
  - Tài khoản được đánh giá như một tổng thể
  - Cả BTC-PERP và DOGE-PERP đều có thể bị tự động đóng

Với ký quỹ được bảo vệ:
  - DOGE-PERP chịu khoản lỗ riêng và có thể bị tự động đóng qua BLP hoặc ADL
  - BTC-PERP giữ lại phần ký quỹ duy trì được bảo vệ
  - BTC-PERP không bị tự động đóng chỉ vì khoản lỗ của DOGE-PERP
  - BTC-PERP vẫn có thể bị giảm một phần qua sổ lệnh
    cho đến khi tỷ lệ ký quỹ của tài khoản vượt yêu cầu
    ký quỹ duy trì
```

{% endcode %}

***

#### Liquidation Fees

**Rate:** 1% per fill

**Scope:**

* System-triggered perpetual futures liquidations
* System-triggered borrow/spot-margin liquidations

**Calculation:**

* Fee is applied to the filled notional amount of each liquidation order
* Deducted from liquidation proceeds (not charged separately)

**Exclusions:**

* User-initiated position closes (regular trading fees apply)
* Manual repayment of borrows

***

#### Liquidation Process by Product

**Perpetual Futures Liquidation**

1. Open orders cancelled
2. Available balance used to repay borrows
3. Collateral sold to cover remaining borrow liability
4. Position reduced via orderbook
5. Nếu tỷ lệ ký quỹ của một vị thế thấp hơn ACMF → BLP tiếp quản
6. Nếu khả năng tiếp nhận của BLP không đủ → ADL

**Settlement:** Liquidation proceeds settle in USDC. PnL (positive or negative) is realized immediately.

**Spot Margin Liquidation**

1. Open orders cancelled
2. Available balance used to repay borrows
3. Collateral sold to cover remaining borrow liability
4. If collateral insufficient → additional asset liquidation

**Settlement:** Borrowed assets are repaid to the lending pool. Remaining collateral (if any) stays in account.

**Borrow Position Liquidation**

When a borrow position specifically triggers liquidation:

1. System sells collateral to repay borrow
2. Liquidation fee applied to sold amount
3. Remaining collateral returned to account

**100% Utilization Scenario:** If the lending pool is fully utilized and collateral cannot be redeemed, ADL mechanisms activate.

***

#### Auto-Deleveraging (ADL)

**Overview**

Auto-Deleveraging is an **emergency mechanism** that activates when standard liquidation processes cannot complete. ADL ensures:

1. Lenders receive the value of their lent assets
2. The platform remains solvent
3. Losses do not socialize beyond direct counterparties

ADL is a **last resort** used only when:

* Prices move faster than liquidation can execute
* Orderbook liquidity is insufficient
* BLP capacity is exceeded
* Market utilization prevents lend redemption

> **Price Display Note:** ADL transactions are executed directly in the backend, bypassing the public orderbook. These execution prices are not reflected in K-line charts.

**ADL for Futures Positions**

**Điều kiện kích hoạt:** Tỷ lệ ký quỹ của vị thế thấp hơn ACMF và BLP không còn khả năng tiếp nhận.

This typically occurs when:

* Liquidating account's position cannot be closed via orderbook
* BLP capacity is insufficient
* Remaining equity cannot cover losses at available prices

**Counterparty Selection:**

ADL does not randomly select counterparties. The system ranks traders with opposing positions by their **ADL Priority Score**:

{% code collapsedlinecount="10" %}

```
ADL Priority = f(Unrealized PnL, Effective Leverage)
```

{% endcode %}

Traders with the highest combination of:

1. **Profit** on the position (higher unrealized PnL = higher priority)
2. **Leverage** on the position (higher leverage = higher priority)

…are selected first for ADL.

**No Account Restrictions:** ADL has no account or user restrictions. After all priority scoring (first and second pass), there is a complete matching of longs and shorts regardless of account.

**Lower priority:** Basis trades and delta-neutral positions are deprioritized and will only be ADL'd when other positions are insufficient.

**Execution Process:**

1. System identifies the liquidating position's size and direction
2. Counterparties are ranked by ADL Priority
3. Highest-priority counterparty's position is partially closed
4. Giá đóng = giá phá sản của vị thế bị thanh lý
5. Process repeats until liquidating position is fully absorbed

**Example:**

{% code collapsedlinecount="10" %}

```
Liquidating Account:
  - Long 10 BTC-PERP
  - Bankruptcy price: $50,000
  - Cannot close via orderbook

ADL Queue (Short BTC-PERP holders ranked by priority):
  1. Trader A: Short 5 BTC, +$20,000 PnL, 10x leverage
  2. Trader B: Short 8 BTC, +$15,000 PnL, 5x leverage
  3. Trader C: Short 3 BTC, +$5,000 PnL, 2x leverage

Execution:
  - Trader A: 5 BTC of short closed at $50,000
  - Trader B: 5 BTC of short closed at $50,000
  - Liquidation complete
```

{% endcode %}

**Notification:**

* ADL fills appear in your fill history with origin `ADL_AUTOCLOSE`
* WebSocket order updates include `O: "ADL_AUTOCLOSE"`

**ADL for Borrow/Lend Positions**

ADL in the borrow/lend system protects lenders when borrowers default or when market conditions prevent normal liquidation.

**Scenario 1: Borrower Default**

When a borrower's account goes bankrupt without holding the borrowed asset:

**Example:**

{% code collapsedlinecount="10" %}

```
Initial State:
  - Borrower borrows 1 BTC from Lender
  - Borrower sells the BTC, holds USDC
  - BTC price rises significantly
  - Borrower's collateral insufficient to cover borrow

Liquidation:
  - Borrower's account goes bankrupt
  - BTC trading at $100,000
  - Borrower no longer has BTC to return

Resolution:
  - System liquidates Borrower's remaining assets
  - Lender receives $100,000 USDC (notional value)
  - Lender receives value, but in USD not BTC
  - Loan is closed
```

{% endcode %}

**Key Principle:** The primary mandate is ensuring the Lender receives the value of their lent assets—either in the original token or in notional USD terms at liquidation time.

**Scenario 2: 100% Utilization**

When lending pool utilization reaches 100%, lent assets cannot be redeemed. If a lender with lent collateral faces liquidation:

**Process:**

1. Lender has positions backed by lent collateral
2. Lender's positions move against them → liquidation triggers
3. Liquidation engine attempts to redeem lent assets
4. Pool at 100% utilization → redemption blocked
5. ADL activates

**ADL Resolution:**

6. System identifies borrowers with available collateral
7. Notional USDC (≤ original lend value) transfers: Borrower → Lender
8. Lender's loan position closes
9. Lender now has USDC to cover liquidation
10. Borrower's loan is closed; collateral may have converted

**Borrower Impact:**

* Borrower's loan is forcibly closed
* Borrower's collateral may convert to a different asset
* Borrower's total account value remains unchanged
* No loss to borrower—only asset composition changes

***

#### Liquidation in the API

**Fill Types**

The `/fills` endpoint returns all fills including system orders. Use the `fillType` parameter to filter:

| fillType               | Description                          |
| ---------------------- | ------------------------------------ |
| `User`                 | Regular user orders only             |
| `BookLiquidation`      | Orderbook liquidation fills          |
| `Adl`                  | Auto-deleveraging fills              |
| `Backstop`             | Backstop Liquidity Provider fills    |
| `Liquidation`          | All liquidation types                |
| `AllLiquidation`       | All liquidation types combined       |
| `CollateralConversion` | Collateral conversion to settle debt |

**Order Update Stream Origins**

WebSocket `account.orderUpdate` stream includes an `O` field indicating the origin:

| Origin                        | Description                          |
| ----------------------------- | ------------------------------------ |
| `USER`                        | User-initiated order                 |
| `LIQUIDATION_AUTOCLOSE`       | Liquidation engine closed position   |
| `ADL_AUTOCLOSE`               | Auto-deleveraging event              |
| `COLLATERAL_CONVERSION`       | Collateral conversion to settle debt |
| `SETTLEMENT_AUTOCLOSE`        | Settlement of dated market position  |
| `BACKSTOP_LIQUIDITY_PROVIDER` | BLP facilitated the liquidation      |

**Querying Liquidation Price**

Query estimated liquidation price via REST:

{% code collapsedlinecount="10" %}

```
GET /api/v1/position?symbol=BTC_USDC_PERP
```

{% endcode %}

Returns `estLiquidationPrice` for the specified position.

**Note:** The `l` field in the position update WebSocket stream is deprecated and returns `0`. Use the REST endpoint for liquidation price queries.

**Settlement History**

Query settlement operations including liquidations:

{% code collapsedlinecount="10" %}

```
GET /wapi/v1/history/settlement
```

{% endcode %}

Filter by source:

* `BackstopLiquidation`
* `TradingFeesSystem`
* `RealizePnl`

***

#### Viewing Liquidation History

**In the UI**

**Futures Liquidations:**

* Navigate to: Portfolio → Futures → Liquidations
* Direct link: <https://backpack.exchange/portfolio/futures/liquidations>

**Borrow/Lend Liquidations:**

* Navigate to: Portfolio → Lending → Liquidations
* Direct link: <https://backpack.exchange/portfolio/borrow-lend/liquidations>

**Via API**

Use the fill history endpoint with `fillType` filter:

{% code collapsedlinecount="10" %}

```
GET /wapi/v1/history/fills?fillType=AllLiquidation
```

{% endcode %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://support.backpack.exchange/technical-docs/vn/trading/thanh-ly.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.