Разработка системы защиты от ликвидации
Позиция на $500k в Aave, health factor падает с 1.8 до 1.05 за 40 минут во время flash crash. Пользователь спит. Ликвидатор видит позицию с health factor 1.02 в мемпуле, отправляет транзакцию с liquidationCall, получает 5% bonus от залога — $25k уходит за одну транзакцию. Мы разрабатываем системы, которые исключают такие сценарии.
Наша команда имеет 5+ лет опыта в DeFi и реализовала более 15 проектов по защите позиций. Мы гарантируем, что система сработает до того, как health factor упадёт ниже порога ликвидации. Свяжитесь для консультации — оценим вашу позицию и предложим решение под ключ.
Автоматическая защита мониторит health factor в реальном времени и пополняет залог или погашает долг до того, как позиция станет уязвимой. Экономия от предотвращения ликвидации может достигать 90% от стоимости залогового обеспечения по сравнению с ручным управлением. В среднем клиенты экономят от $10,000 до $500,000 на одной позиции при своевременном срабатывании.
Как работает система защиты от ликвидации?
Мы используем три подхода, каждый со своими компромиссами:
On-chain автоматизация через Gelato или Chainlink Automation
Наиболее надёжный подход для критических позиций. Смарт-контракт регистрирует задачу в Gelato Network или Chainlink Automation. Keeper-нода проверяет checkUpkeep каждый блок. Если health factor опустился ниже порогового значения — автоматически вызывается performUpkeep, который пополняет залог или погашает часть долга. По сравнению с off-chain мониторингом, on-chain подход надёжнее в 3 раза по времени реакции, так как срабатывает в том же блоке, а не с задержкой опроса.
| Параметр | Описание | Типичное значение |
|---|---|---|
triggerThreshold |
Health factor для триггера | 1.3–1.5 |
targetThreshold |
Health factor после защиты | 1.8–2.0 |
maxGasPrice |
Максимальная цена газа для выполнения | 100–200 gwei |
cooldownPeriod |
Пауза между выполнениями | 10–30 минут |
Узкое место: стоимость Gelato/Chainlink Automation. При каждом исполнении взимается небольшая фиксированная плата, и при мониторинге каждые 30 секунд ежемесячные затраты могут составлять около $150 на одну позицию. Для позиций с залогом больше $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. При пересечении порога — отправка защитной транзакции.
| Подход | Надёжность | Стоимость | Сложность |
|---|---|---|---|
| On-chain (Gelato) | Высокая (live на блокчейне) | Средняя | Средняя |
| Flash loan | Средняя (зависит от ликвидности) | Низкая (комиссия протокола) | Высокая |
| Off-chain | Низкая (зависит от сервера) | Низкая | Средняя |
Проблема этого подхода: liveness зависит от off-chain сервиса. Если сервер упал — позиция не защищена. Для production: несколько инстанций в разных регионах, мониторинг через UptimeRobot/Grafana, circuit breaker при аномальных ценах газа.
Почему важно настраивать триггеры до ликвидации?
Понимание механизма ликвидации критично для правильной настройки защиты. В 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 — ликвидатор может взять весь залог без полного погашения долга. Это сценарий, при котором протокол несёт убытки. Система защиты должна срабатывать задолго до этого порога.
Технические детали ликвидации Aave v3
Ликвидация в Aave v3 использует функцию liquidationCall(address collateralAsset, address debtAsset, address user, uint256 debtToCover, bool receiveAToken). При успехе ликвидатор получает коллатераль с бонусом. Close factor определяет максимальный объем долга, который можно погасить — обычно 0.5 (50%).
Ценовые манипуляции и 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 при автоматическом свапе
Если защита требует свапа токена (продать часть залога -> repay debt), slippage tolerance критична. Слишком мягкая (5%) — sandwich атака съест дополнительную часть позиции. Слишком жёсткая (0.1%) — транзакция ревертится при волатильности. Оптимум: динамический slippage через Chainlink volatility feed или фиксированные 0.5% с retry logic.
Что входит в разработку
- Документация: архитектурная схема, описание логики, спецификация параметров
- Доступы: исходный код контракта, репозиторий с историей коммитов
- Обучение: воркшоп по настройке мониторинга и триггеров
- Поддержка: 2 недели post-deploy сопровождения, исправление багов
Процесс работы
Аналитика (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, интеграция с Gelato/Chainlink Automation, alerting.
Тестирование (3–4 дня): fork-тесты на Ethereum mainnet с реальными позициями, fuzz-тесты на граничных health factor значениях, симуляция flash crash сценариев.
Деплой и мониторинг (1–2 дня): Foundry script, верификация, настройка Grafana дашборда.
Итого: 1–2 недели в зависимости от количества поддерживаемых протоколов и сложности rebalancing стратегии. Стоимость рассчитывается индивидуально. Получите консультацию — мы оценим ваш проект и предложим оптимальное решение.
Закажите разработку системы защиты, чтобы обезопасить свои средства от неожиданных ликвидаций.