Розробка системи захисту від ліквідації
Позиція на $500k в Aave, health factor падає з 1.8 до 1.05 за 40 хвилин під час flash crash. Користувач спить. Ліквідатор бачить позицію з health factor 1.02 у mempool, відправляє транзакцію з liquidationCall, отримує 5% бонус від колатералю. $25k йде ліквідатору за одну транзакцію.
Системи автоматичного захисту від ліквідації вирішують саме цю ситуацію: моніторинг health factor у real-time, автоматичне поповнення колатералю або часткове погашення боргу до того, як позиція стане вразливою.
Архітектура захисту: три підходи
On-chain автоматизація через Gelato або Chainlink Automation
Найнадійніший підхід для критичних позицій. Smart contract реєструє завдання в 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 реbалансування
Якщо у користувача немає вільних коштів для поповнення колатералю, захист може використовувати flash loan. Алгоритм:
- Позичити flash loan з Aave/Balancer у collateral токен
- Поповнити колатераль у захищаному протоколі
- Позичити debt token під новий, вищий колатераль
- Повернути flash loan з позичених коштів
- Чистий результат: позиція переважена, flash loan повернений, мала комісія протоколу утримана
Це працює тільки якщо цільовий health factor досяжний з поточним LTV та цінами на ринку. Контракт повинен перевірити це перед виконанням — інакше транзакція зареверується після списання газу.
Моніторинг через 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-колатералю бонус 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, оракул все ще показує $1900. Ліквідацій немає. Через 2 блока оракул оновився — $100 різниця за секунди, сотні позицій одночасно стають ліквідовані.
Система захисту повинна враховувати цей lag: якщо spot price (DEX TWAP) відхилився від oracle price більше ніж на 5% — це сигнал для превентивного захисту, не чекаючи оновлення оракула.
Контракт захисту: критичні деталі
Access control для автоматичних операцій
Захисний контракт діє від імені користувача (додає колатераль, погашає борг). Користувач повинен видати дозвіл через approve або використовувати ERC-4337 Account Abstraction, де захисний модуль — validating plugin для smart wallet.
Без AA-підходу є ризик: контракт має approve на токени користувача. Якщо у контракті є уразливість — це attack surface для drain. Весь access control проходить review на privilege escalation.
Slippage при автоматичному своп
Якщо захист вимагає своп токена (продати частину колатералю → погасити борг), slippage tolerance критична. Занадто м'яка (5%) — sandwich атака з'їсть додаткову частину позиції. Занадто жорстка (0.1%) — транзакція зареверується при волатильності. Оптимум: динамічний slippage через Chainlink volatility feed або fixed 0.5% з retry logic.
Процес роботи
Аналітика (2–3 дня): аудит цільового протоколу (Aave v3 / Compound v3 / Morpho), визначення доступних векторів захисту, аналіз ліквідаційних сценаріїв через fork-симуляцію.
Розробка смарт-контракту (4–6 днів): protection logic, flash loan інтеграція, access control, события для моніторингу.
Off-chain моніторинг (3–4 дня): сервіс tracking health factor, інтеграція з Gelato/Chainlink Automation, alerting.
Тестування (3–4 дня): fork-тести на Ethereum mainnet з реальними позиціями, fuzz-тести на граничні значення health factor, симуляція flash crash сценаріїв.
Деплой та моніторинг (1–2 дня): Foundry script, верифікація, налаштування Grafana дашборду.
Итого: 1–2 тижні залежно від кількості підтримуваних протоколів та складності rebalancing стратегії. Вартість розраховується індивідуально.