Разработка системы защиты от ликвидации
Позиция на $500k в Aave, health factor падает с 1.8 до 1.05 за 40 минут во время flash crash. Пользователь спит. Ликвидатор видит позицию с health factor 1.02 в мемпуле, отправляет транзакцию с liquidationCall, получает 5% bonus от залога. $25k уходит ликвидатору за одну транзакцию.
Системы автоматической защиты от ликвидации решают именно эту ситуацию: мониторинг health factor в реальном времени, автоматическое пополнение залога или частичное погашение долга до того, как позиция станет уязвимой.
Архитектура защиты: три подхода
On-chain автоматизация через Gelato или Chainlink Automation
Наиболее надёжный подход для критических позиций. Смарт-контракт регистрирует задачу в Gelato Network или Chainlink Automation. Keeper-нода проверяет checkUpkeep каждый блок. Если health factor опустился ниже порогового значения — автоматически вызывается performUpkeep, который пополняет залог или погашает часть долга.
Ключевые параметры:
| Параметр | Описание | Типичное значение |
|---|---|---|
triggerThreshold |
Health factor для триггера | 1.3–1.5 |
targetThreshold |
Health factor после защиты | 1.8–2.0 |
maxGasPrice |
Максимальная цена газа для выполнения | 100–200 gwei |
cooldownPeriod |
Пауза между выполнениями | 10–30 минут |
Узкое место: стоимость Gelato/Chainlink Automation. При $0.05/исполнение и мониторинге каждые 30 секунд — $144/месяц на одну позицию. Для позиций с залогом >$50k это оправдано; для мелких — нет.
Flash loan-based rebalancing
Если у пользователя нет свободных средств для пополнения залога, защита может использовать flash loan. Алгоритм:
- Взять flash loan из Aave/Balancer в collateral token
- Пополнить залог в защищаемом протоколе
- Занять debt token под новый, более высокий залог
- Погасить flash loan из занятых средств
- Net результат: позиция rebalanced, flash loan возвращён, небольшая комиссия протокола удержана
Это работает только если target health factor достижим с текущим LTV и рыночными ценами. Контракт обязан проверять это перед исполнением — иначе транзакция ревертится после списания gas fee.
Мониторинг через The Graph + off-chain сервис
Off-chain компонент: сервис подписывается на события Aave Borrow, Withdraw, LiquidationCall через WebSocket к ноде (Alchemy/Infura). При каждом событии, затрагивающем отслеживаемые адреса — пересчёт health factor через multicall к getAccountData. При пересечении порога — отправка защитной транзакции.
Проблема этого подхода: liveness зависит от off-chain сервиса. Если сервер упал — позиция не защищена. Для production: несколько инстанций в разных регионах, мониторинг через UptimeRobot/Grafana, circuit breaker при аномальных ценах газа.
Глубже: как устроена ликвидация в Aave v3
Понимание механизма ликвидации критично для правильной настройки защиты. В Aave v3 ликвидация возможна когда:
healthFactor = sum(collateral_i * price_i * liquidationThreshold_i) / totalDebt
healthFactor < 1.0
Ликвидатор может погасить до 50% долга (close factor) за одну транзакцию и получить залог с liquidation bonus (5–15% в зависимости от актива). Для ETH-залога bonus 5%, для менее ликвидных активов — выше.
Важный нюанс: при health factor < 0.95 в Aave v3 активируется режим bad debt — ликвидатор может взять весь залог без полного погашения долга. Это сценарий, при котором протокол несёт убытки. Система защиты должна срабатывать задолго до этого порога.
Ценовые манипуляции и oracle lag
Flash crash на Binance не всегда немедленно отражается в Chainlink price feed — медиан из 31 источника обновляется с задержкой, deviation threshold обычно 0.5–1%. В этом окне: реальная цена ETH $1800, oracle ещё показывает $1900. Ликвидации нет. Через 2 блока oracle обновился — $100 разница за секунды, сотни позиций становятся ликвидируемыми одновременно.
Система защиты должна учитывать этот lag: если spot price (DEX TWAP) отклонился от oracle price более чем на 5% — это сигнал к превентивной защите, не дожидаясь oracle update.
Контракт защиты: критичные детали
Access control для автоматических операций
Защитный контракт действует от имени пользователя (добавляет залог, погашает долг). Пользователь должен выдать ему разрешение через approve или использовать ERC-4337 Account Abstraction, где защитный модуль — validating plugin для smart wallet.
Без AA-подхода есть риск: контракт имеет approve на токены пользователя. Если в контракте есть уязвимость — это attack surface для drain. Все access control проходят review на предмет privilege escalation.
Slippage при автоматическом свапе
Если защита требует свапа токена (продать part of collateral → repay debt), slippage tolerance критична. Слишком мягкая (5%) — sandwich атака съест дополнительную часть позиции. Слишком жёсткая (0.1%) — транзакция ревертится при волатильности. Оптимум: динамический slippage через Chainlink volatility feed или fixed 0.5% с retry logic.
Процесс работы
Аналитика (2–3 дня): аудит целевого протокола (Aave v3 / Compound v3 / Morpho), определение доступных protection векторов, анализ liquidation scenarios через fork-симуляцию.
Разработка смарт-контракта (4–6 дней): protection logic, flash loan integration, access control, события для мониторинга.
Off-chain мониторинг (3–4 дня): сервис health factor tracking, integration с Gelato/Chainlink Automation, alerting.
Тестирование (3–4 дня): fork-тесты на Ethereum mainnet с реальными позициями, fuzz-тесты на граничных health factor значениях, симуляция flash crash сценариев.
Деплой и мониторинг (1–2 дня): Foundry script, верификация, настройка Grafana дашборда.
Итого: 1–2 недели в зависимости от количества поддерживаемых протоколов и сложности rebalancing стратегии. Стоимость рассчитывается индивидуально.