Как работают ликвидации в DeFi простыми словами: кто запускает продажу залога и где здесь нужен automation layer

Когда команда впервые смотрит на DeFi-lending протокол, механика кажется почти банковской:

пользователь вносит залог
под этот залог берёт займ
пока цена залога держится, всё нормально
если цена падает слишком сильно, позицию ликвидируют

Но в реальной системе слово «ликвидируют» скрывает целую машину:

кто именно замечает рискованную позицию
откуда берётся цена
кто имеет право закрыть часть долга
кто продаёт залог
почему это вообще выгодно делать быстро
и как сделать так, чтобы вся эта механика не остановилась в самый плохой момент рынка

Свежие обсуждения на Hacker News вокруг automation для денежных workflow хорошо подсвечивают общий инженерный запрос: людям уже мало просто видеть баланс и статусы, им нужен слой, который сам замечает риск, принимает ограниченное решение и исполняет его без ручной паники. В DeFi это особенно заметно именно на ликвидациях.

Ниже — разбор без лишнего жаргона: как работает liquidation flow, кто в нём участвует, где спрятан риск и какой automation layer вокруг него имеет смысл строить продукту, фонду или infrastructure-команде.

Что такое ликвидация на практике

Ликвидация в DeFi — это не «протокол наказал пользователя».

Это защитный механизм, который нужен, чтобы в системе не осталось долга, который уже недостаточно покрыт залогом.

Упрощённо картина такая:

пользователь положил collateral, например ETH
под этот collateral занял стейблкоин
цена ETH упала
стоимость залога стала слишком близка к размеру долга
протокол разрешает внешнему участнику закрыть часть долга пользователя
взамен этот участник получает часть залога со скидкой или бонусом

То есть ликвидатор не просто нажимает кнопку «закрыть чужую позицию». Он фактически делает полезную работу для протокола:

возвращает системе часть плохеющего долга
уменьшает риск недообеспеченности
получает экономический стимул за скорость и правильный execution

Кто с кем взаимодействует

Если убрать маркетинговые слова, у liquidation flow обычно есть пять ключевых участников.

1. Заёмщик

Он создаёт позицию:

вносит collateral
берёт debt asset
поддерживает приемлемый уровень обеспечения

2. Lending protocol

Протокол хранит правила:

какие активы можно использовать как залог
какой у них collateral factor
где находится liquidation threshold
какую часть долга можно закрыть за одну ликвидацию
какой liquidation bonus получит ликвидатор

3. Oracle

Oracle приносит цену, без которой протокол не понимает, насколько позиция безопасна.

Если oracle опоздал, дал плохую цену или обновляется слишком редко, можно получить две проблемы:

ликвидация не произошла там, где была нужна
ликвидация произошла слишком агрессивно по искажённой цене

4. Liquidator / keeper / bot

Это внешний исполнитель. Он следит за позициями, находит те, что перешли границу риска, и отправляет транзакцию ликвидации.

5. DEX или другой execution venue

После получения залога ликвидатору часто нужно быстро продать его, чтобы вернуть капитал, погасить флэш-ликвидность или зафиксировать спред.

Именно поэтому liquidation flow редко живёт в изоляции. Он почти всегда связан с:

swap routing
MEV-конкуренцией
скоростью включения транзакции
глубиной ликвидности на DEX
cost of gas

Самая полезная модель: health factor, а не просто «цена упала»

Ключевая переменная в lending — не просто курс актива, а насколько позиция далека от границы ликвидации.

Обычно это выражается через health factor или аналогичную метрику.

Упрощённо:

если обеспечение большое, health factor высокий
если долг растёт или залог дешевеет, health factor снижается
когда он доходит до порога, позиция становится liquidatable

Это важно, потому что ликвидация зависит не от одного графика цены, а от комбинации факторов:

price move collateral asset
price move borrowed asset
accrued interest
protocol-specific thresholds
иногда корреляции между активами

Для automation это означает простую вещь: нельзя строить риск-мониторинг только на ценовых алертах. Нужен слой, который считает состояние позиции так же, как его считает сам протокол.

Что происходит в момент ликвидации

В хорошем объяснении DeFi ликвидация выглядит так:

price update -> position becomes unsafe -> bot detects opportunity -> bot submits liquidation tx -> protocol accepts debt repayment -> protocol releases discounted collateral -> bot unwinds inventory

Теперь разложим это по шагам.

Шаг 1. Oracle обновляет цену

Протокол видит, что collateral теперь стоит меньше.

Шаг 2. Позиция пересекает threshold

Health factor падает ниже допустимого уровня.

Шаг 3. Бот решает, выгодно ли её брать

Бот смотрит не только на то, что позицию можно ликвидировать, но и на то, стоит ли это делать экономически.

Он оценивает:

размер liquidation bonus
gas cost
slippage при продаже залога
доступную ликвидность
конкуренцию других ботов
latency и вероятность, что его опередят

Шаг 4. Бот исполняет транзакцию

Он гасит часть долга и получает залог по правилам протокола.

Шаг 5. Бот закрывает собственный рыночный риск

После этого у него на руках оказывается актив, который нужно:

продать
перевести
захеджировать
или временно удерживать по treasury-логике

Именно на этом шаге «чисто DeFi-протокол» внезапно превращается в проблему automation infrastructure.

Почему ликвидации — это не просто бот, а целая операционная система

Многие думают, что liquidation bot — это один скрипт: проверил позицию, отправил транзакцию, заработал бонус.

На практике зрелая система почти всегда состоит из нескольких слоёв.

Observation layer

Собирает:

позиции из протокола
oracle updates
mempool сигналы
liquidity snapshots
gas conditions

Risk engine

Решает:

какая позиция реально liquidatable
сколько долга выгодно закрывать
не изменился ли oracle state
не уйдёт ли прибыль в минус после gas и slippage

Execution layer

Отвечает за:

формирование транзакции
выбор nonce / fee strategy
retry logic
fallback route
отправку через private relay или публичный mempool

Inventory / treasury layer

После ликвидации управляет тем, что получилось на балансе:

продаёт collateral
переводит актив между кошельками
ребалансирует капитал для следующих сделок
следит, чтобы liquidation bot не умер от нехватки working capital

Control layer

Нужен, чтобы automation не начала создавать новый риск:

лимиты на капитал в одной сети
лимиты на один протокол
circuit breaker по oracle anomalies
запрет на execution при высокой base fee
hold mode при проблемах с DEX liquidity

Где на самом деле ломаются liquidation pipelines

Самые неприятные сбои редко звучат как «бот совсем не работает».

Чаще проблемы тоньше.

1. Oracle вроде жив, но цена уже stale

Формально апдейт есть, но для волатильного рынка он уже бесполезен.

2. Позиция ликвидируема математически, но невыгодна экономически

После gas, slippage и конкуренции бот берёт красивую сделку на бумаге и уходит в минус.

3. После получения collateral нечем или негде быстро выйти

На маленьком пуле можно получить залог со скидкой и тут же отдать весь бонус в slippage.

4. Бот выигрывает onchain, но проигрывает в treasury

Например:

капитал застрял в одном домене
bridge идёт слишком долго
stable liquidity закончилась
нет автоматического replenish рабочего баланса

5. Протокол жив, а control plane вокруг него нет

Команда видит только итоговую PnL, но не видит:

какие opportunities были пропущены
где risk engine был слишком консервативен
какие liquidations отменились из-за nonce / gas / relay issues
какие execution path создают скрытый inventory risk

Что полезно автоматизировать бизнесу или тех-команде

Если вы строите продукт вокруг DeFi, брокерскую инфраструктуру, treasury stack или внутренний execution tooling, ликвидации полезно рассматривать не как «бота ради доходности», а как управляемый сервисный слой.

Практический блок: как превратить ликвидации в нормальный automation layer

1. Какая проблема возникает у бизнеса или продукта

Обычно проблема не в том, что команда не знает слово liquidation.

Проблема в другом:

позиции мониторятся разными скриптами и дашбордами
risk logic и execution logic размазаны по нескольким сервисам
treasury не понимает, сколько капитала нужно держать для быстрого реагирования
никто не может объяснить, почему opportunity была пропущена
оператор узнаёт о проблеме уже после движения рынка

2. Какой архитектурный паттерн имеет смысл внедрить

Хороший базовый паттерн выглядит так:

protocol watchers -> normalized risk state -> liquidation candidate queue -> policy/risk gate -> execution worker -> inventory unwind -> reconciliation + metrics

Что это даёт:

единый формат состояния позиций
отдельный decision layer вместо ad-hoc скриптов
явные лимиты и circuit breakers
предсказуемый execution path
post-trade разбор, а не гадание по логам

На практике особенно полезны такие сущности:

position_risk_snapshots
liquidation_candidates
execution_attempts
inventory_exposures
missed_opportunities
oracle_health_events

3. Что именно можно предоставить как service / implementation / automation layer

Здесь уже появляется прикладная коммерческая ценность.

Не обязательно строить «ещё один DeFi-протокол». Часто реальная ценность — в слое над ним:

liquidation monitoring service — следит за health factor, oracle freshness, gas и liquidity conditions
keeper orchestration layer — управляет несколькими ботами, приоритетами и failover
policy-controlled execution gateway — не даёт исполнять сделки вне лимитов и risk profile
inventory unwind service — автоматически продаёт или хеджирует collateral после ликвидации
treasury replenishment automation — поддерживает working capital в нужных сетях и кошельках
ops dashboard + alerting — показывает missed opportunities, stuck executions, PnL by route и признаки деградации

Для фонда, market-neutral стратегии, lending desk или инфраструктурного продукта это уже не «бот», а нормальный production capability.

Какие метрики здесь важнее всего

Если смотреть на ликвидации как на инженерную систему, полезнее всего мониторить не только прибыль.

Минимальный набор:

opportunities detected
opportunities executed
win rate against competitors
median detection-to-submit latency
execution success rate
realized bonus after gas and slippage
stale oracle incidents
missed opportunities by reason
working capital utilization
time to inventory unwind

Именно эти метрики показывают, где у вас проблема: в протоколе, в инфраструктуре, в treasury или в risk logic.

Главное

Ликвидации в DeFi — это хороший пример того, как «простая» механика протокола на деле превращается в многослойную автоматизацию.

Снаружи всё выглядит как одно событие: позицию закрыли.

Внутри же работают сразу несколько систем:

pricing
risk calculation
keeper logic
transaction execution
liquidity routing
treasury management
policy controls
monitoring и reconciliation

Поэтому самый полезный способ думать о liquidations — не как о случайной onchain-возможности, а как о risk-driven automation workflow.

И если этот workflow построен хорошо, команда получает не только шанс заработать liquidation bonus, но и гораздо более важную вещь: предсказуемый control layer вокруг DeFi-механики, где риск, скорость и исполнение управляются как инженерная система, а не как набор героических скриптов.