> 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/ru/torgovlya/likvidaciya.md). # Ликвидация ### Общее описание Ликвидация — это процесс, в ходе которого риск-движок сокращает или закрывает позиции, когда маржа аккаунта опускается ниже поддерживающих требований. Backpack использует многоуровневую систему ликвидации, задачи которой: 1. Минимизировать убытки пользователя за счёт постепенного сокращения позиции 2. Сохранять исполнение через книгу ордеров там, где это возможно 3. Предотвращать системный риск с помощью backstop-механизмов 4. Обеспечивать платёжеспособность платформы в экстремальных условиях Маржа, активы и позиции аккаунта оцениваются по Mark Price, чтобы исключить манипуляции через всплески цены последней сделки. Ликвидации исполняются в книге ордеров или через другие механизмы каскада. *** ### Триггер ликвидации #### Когда происходит ликвидация Ликвидация запускается, когда **Maintenance Margin Ratio (MMR) достигает 100%**. ``` MMR = Account MMF / Account Margin Fraction ``` Где: * Account Margin Fraction = Net Equity / Total Exposure Notional * Account MMF = Σ(Notional Position Size × Position MMF) / Total Exposure Notional #### Что происходит при срабатывании триггера Когда MMR достигает 100%, движок ликвидации выполняет следующее: 1. **Отмена всех открытых ордеров** — освобождает заблокированную маржу 2. **Погашение займов и сворачивание позиций** — погашение займов и сворачивание позиций происходят параллельно #### Расчётная и фактическая цена ликвидации Расчётная цена ликвидации, отображаемая в интерфейсе, носит **исключительно справочный характер**. Она предполагает: * Отсутствие изменений в других позициях * Отсутствие изменений в составе обеспечения * Отсутствие выплат по фандингу и начисления процентов * Неизменные Mark Price по другим активам **Фактическая ликвидация происходит при MMR ≥ 100%**, и этот показатель учитывает полное состояние вашего субаккаунта. Для аккаунтов со сложной экспозицией (несколько позиций, обеспечение не в USD, активные займы) система может не отображать точную расчётную цену ликвидации. *** ### Каскад ликвидации Backpack использует трёхэтапный каскад ликвидации. Каждый этап активируется только в том случае, если предыдущий этап не может полностью восстановить маржинальное состояние аккаунта. ``` ┌─────────────────────────────────────────────────────────────────┐ │ LIQUIDATION WATERFALL │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Stage 1: ORDERBOOK LIQUIDATION │ │ ├── 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) │ │ ├── Activates when: ACMF breached │ │ ├── Positions transfer to BLP participants │ │ ├── Portion of remaining equity paid to backstop fund │ │ └── BLPs assume position management │ │ │ │ │ ▼ │ │ Stage 3: AUTO-DELEVERAGING (ADL) │ │ ├── Activates when: ACMF breached AND no BLP capacity │ │ ├── Profitable counterparties' positions partially closed │ │ ├── No account or user restrictions after priority scoring │ │ └── Last resort to maintain system solvency │ │ │ └─────────────────────────────────────────────────────────────────┘ ``` > **Примечание об отображении цен:** транзакции backstop и ADL исполняются вне книги ордеров (за пределами публичной книги ордеров). Поэтому эти цены исполнения не отражаются на графиках K-line. #### Этап 1: Ликвидация через книгу ордеров **Триггер:** MMR ≥ 100% **Механизм:** * Движок ликвидации размещает **рыночные ордера reduce-only** в публичной книге ордеров * Ордера исполняются против размещённой ликвидности по текущим рыночным ценам * Ликвидация выполняется циклически (1 секунда на тик, вероятность 50% на каждом тике), сокращая 10% позиции за итерацию, с ограничением по ёмкости ликвидации * Процесс продолжается, пока MMR не станет < 100% **Защитные механизмы:** * **Ценовые ограничения** не допускают исполнения по манипулятивным ценам * **Постепенное сокращение** минимизирует рыночное воздействие * Ликвидации видны в публичной книге ордеров и в ленте сделок **Частичная ликвидация:** система ликвидирует только минимальный объём, необходимый для восстановления маржинального состояния. Это означает: * После ликвидации у вас может остаться уменьшенная позиция * Оставшийся капитал остаётся на вашем аккаунте * Если цена продолжит двигаться против вас, могут произойти дополнительные ликвидации #### Этап 2: Backstop Liquidity Providers (BLPs) **Триггер:** маржинальная фракция аккаунта (Account Margin Fraction) опускается ниже **Auto-Close Margin Fraction (ACMF)** **Расчёт Auto-Close Margin Fraction:** ``` ACMF = max(Account MMF / ACMF Divisor, Account MMF - ACMF Offset) ``` ACMF всегда меньше MMF, что создаёт буферную зону между нарушением поддерживающей маржи и передачей позиции BLP. **Механизм:** 1. Оставшаяся позиция передаётся Backstop Liquidity Providers 2. Часть оставшегося капитала аккаунта выплачивается в фонд backstop-ликвидности 3. BLP принимают на себя управление позицией 4. Маржа аккаунта обнуляется (аккаунт остаётся активным для торговли) или снижается до безопасных уровней маржи **Требования к BLP:** * Требования к минимальному балансу на платформе * Обязательство абсорбировать заданные объёмы ликвидаций * Возможное требование соответствовать стандартам маркет-мейкинга #### Этап 3: Auto-Deleveraging (ADL) Полные подробности см. в разделе [Auto-Deleveraging (ADL)](#auto-deleveraging-adl). *** ### Комиссии за ликвидацию **Ставка:** 1% с каждого исполнения (fill) **Область применения:** * Ликвидации бессрочных фьючерсов, инициированные системой * Ликвидации по заимствованию/спот-марже, инициированные системой **Расчёт:** * Комиссия начисляется на исполненный номинальный объём каждого ликвидационного ордера * Удерживается из поступлений от ликвидации (не взимается отдельно) **Исключения:** * Закрытие позиций по инициативе пользователя (применяются обычные торговые комиссии) * Ручное погашение займов *** ### Процесс ликвидации по продуктам #### Ликвидация бессрочных фьючерсов 1. Открытые ордера отменяются 2. Доступный баланс используется для погашения займов 3. Обеспечение продаётся для покрытия оставшегося долга по займу 4. Позиция сокращается через книгу ордеров 5. Если нарушен ACMF → передача BLP 6. Если ёмкость BLP превышена → ADL **Расчёты:** поступления от ликвидации рассчитываются в USDC. PnL (положительный или отрицательный) реализуется немедленно. #### Ликвидация спот-маржи 1. Открытые ордера отменяются 2. Доступный баланс используется для погашения займов 3. Обеспечение продаётся для покрытия оставшегося долга по займу 4. Если обеспечения недостаточно → ликвидация дополнительных активов **Расчёты:** заимствованные активы возвращаются в пул кредитования. Оставшееся обеспечение (если оно есть) остаётся на аккаунте. #### Ликвидация позиции заимствования Когда ликвидацию запускает именно позиция заимствования: 1. Система продаёт обеспечение для погашения займа 2. К проданному объёму применяется комиссия за ликвидацию 3. Оставшееся обеспечение возвращается на аккаунт **Сценарий 100% использования:** если пул кредитования использован полностью и обеспечение невозможно изъять, активируются механизмы ADL. *** ### Auto-Deleveraging (ADL) #### Общее описание Auto-Deleveraging (автоматическое снижение плеча) — это **экстренный механизм**, который активируется, когда стандартные процессы ликвидации не могут быть завершены. ADL обеспечивает: 1. Кредиторы получают стоимость размещённых ими в лендинг активов 2. Платформа остаётся платёжеспособной 3. Убытки не распределяются за пределы прямых контрагентов ADL — это **крайняя мера**, применяемая только когда: * Цены движутся быстрее, чем может исполниться ликвидация * Ликвидности в книге ордеров недостаточно * Ёмкость BLP превышена * Уровень использования рынка не позволяет изъять размещённые в лендинг средства > **Примечание об отображении цен:** транзакции ADL исполняются напрямую в бэкенде, минуя публичную книгу ордеров. Эти цены исполнения не отражаются на графиках K-line. #### ADL для фьючерсных позиций **Условия срабатывания:** маржинальная фракция аккаунта опускается ниже ACMF И отсутствует доступная ёмкость BLP Обычно это происходит, когда: * Позицию ликвидируемого аккаунта невозможно закрыть через книгу ордеров * Ёмкости BLP недостаточно * Оставшегося капитала не хватает для покрытия убытков по доступным ценам **Выбор контрагентов:** ADL не выбирает контрагентов случайным образом. Система ранжирует трейдеров с противоположными позициями по их **ADL Priority Score**: ``` ADL Priority = f(Unrealized PnL, Effective Leverage) ``` Трейдеры с наибольшим сочетанием: 1. **Прибыли** по позиции (выше нереализованный PnL = выше приоритет) 2. **Кредитного плеча** по позиции (выше плечо = выше приоритет) …выбираются для ADL в первую очередь. **Отсутствие ограничений по аккаунтам:** в ADL нет ограничений по аккаунтам или пользователям. После завершения расчёта приоритетов (первый и второй проход) выполняется полное сопоставление лонгов и шортов независимо от аккаунта. **Более низкий приоритет:** базисные сделки и дельта-нейтральные позиции имеют пониженный приоритет и попадут под ADL только тогда, когда других позиций окажется недостаточно. **Процесс исполнения:** 1. Система определяет размер и направление ликвидируемой позиции 2. Контрагенты ранжируются по ADL Priority 3. Позиция контрагента с наивысшим приоритетом частично закрывается 4. Цена закрытия = цена банкротства ликвидируемого аккаунта 5. Процесс повторяется, пока ликвидируемая позиция не будет полностью абсорбирована **Пример:** ``` 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 ``` **Уведомление:** * Исполнения ADL отображаются в истории ваших исполнений с origin `ADL_AUTOCLOSE` * Обновления ордеров по WebSocket содержат `O: "ADL_AUTOCLOSE"` #### ADL для позиций заимствования/кредитования ADL в системе заимствования/кредитования защищает кредиторов, когда заёмщики допускают дефолт или когда рыночные условия не позволяют провести обычную ликвидацию. **Сценарий 1: дефолт заёмщика** Когда аккаунт заёмщика становится банкротом, не имея заимствованного актива: **Пример:** ``` 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 ``` **Ключевой принцип:** основная задача — обеспечить, чтобы кредитор получил стоимость размещённых им в лендинг активов: либо в исходном токене, либо в номинальном выражении в USD на момент ликвидации. **Сценарий 2: 100% использования** Когда использование пула кредитования достигает 100%, размещённые в лендинг активы невозможно изъять. Если кредитор с размещённым в лендинг обеспечением сталкивается с ликвидацией: **Процесс:** 1. У кредитора есть позиции, обеспеченные размещённым в лендинг обеспечением 2. Позиции кредитора движутся против него → срабатывает ликвидация 3. Движок ликвидации пытается изъять размещённые в лендинг активы 4. Пул использован на 100% → изъятие заблокировано 5. Активируется ADL **Разрешение через ADL:** 6. Система находит заёмщиков с доступным обеспечением 7. Номинальный объём USDC (≤ исходной стоимости размещённых средств) переводится: заёмщик → кредитор 8. Позиция кредитования кредитора закрывается 9. У кредитора теперь есть USDC для покрытия ликвидации 10. Заём заёмщика закрывается; обеспечение могло быть конвертировано **Влияние на заёмщика:** * Заём заёмщика принудительно закрывается * Обеспечение заёмщика может быть конвертировано в другой актив * Общая стоимость аккаунта заёмщика остаётся неизменной * Заёмщик не несёт убытка: меняется только состав активов *** ### Ликвидация в API #### Типы исполнений (Fill Types) Эндпоинт `/fills` возвращает все исполнения, включая системные ордера. Для фильтрации используйте параметр `fillType`: | fillType | Описание | | ---------------------- | ---------------------------------------------- | | `User` | Только обычные пользовательские ордера | | `BookLiquidation` | Исполнения ликвидации через книгу ордеров | | `Adl` | Исполнения ADL (автоматическое снижение плеча) | | `Backstop` | Исполнения Backstop Liquidity Provider | | `Liquidation` | Все типы ликвидаций | | `AllLiquidation` | Все типы ликвидаций вместе | | `CollateralConversion` | Конвертация обеспечения для погашения долга | #### Источники (origin) в потоке обновлений ордеров Поток WebSocket `account.orderUpdate` содержит поле `O`, указывающее источник (origin): | Origin | Описание | | ----------------------------- | ------------------------------------------- | | `USER` | Ордер, инициированный пользователем | | `LIQUIDATION_AUTOCLOSE` | Позиция закрыта движком ликвидации | | `ADL_AUTOCLOSE` | Событие ADL (автоматическое снижение плеча) | | `COLLATERAL_CONVERSION` | Конвертация обеспечения для погашения долга | | `SETTLEMENT_AUTOCLOSE` | Расчёты по позиции датированного рынка | | `BACKSTOP_LIQUIDITY_PROVIDER` | Ликвидация проведена через BLP | #### Запрос цены ликвидации Расчётную цену ликвидации можно запросить через REST: ``` GET /api/v1/position?symbol=BTC_USDC_PERP ``` Возвращает `estLiquidationPrice` для указанной позиции. **Примечание:** поле `l` в WebSocket-потоке обновлений позиций устарело и возвращает `0`. Для запроса цены ликвидации используйте REST-эндпоинт. #### История расчётов Запрос расчётных операций, включая ликвидации: ``` GET /wapi/v1/history/settlement ``` Фильтрация по источнику: * `BackstopLiquidation` * `TradingFeesSystem` * `RealizePnl` *** ### Просмотр истории ликвидаций #### В интерфейсе **Ликвидации фьючерсов:** * Перейдите: Portfolio → Futures → Liquidations * Прямая ссылка: **Ликвидации по заимствованию/кредитованию:** * Перейдите: Portfolio → Lending → Liquidations * Прямая ссылка: #### Через API Используйте эндпоинт истории исполнений с фильтром `fillType`: ``` GET /wapi/v1/history/fills?fillType=AllLiquidation ``` --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://support.backpack.exchange/technical-docs/ru/torgovlya/likvidaciya.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.