Розробка системи захисту від ліквідації
Позиція на $500k в Aave, health factor падає з 1.8 до 1.05 за 40 хвилин під час flash crash. Користувач спить. Ліквідатор бачить позицію з health factor 1.02 в мемпулі, відправляє транзакцію з liquidationCall, отримує 5% бонус від застави — $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 з зайнятих коштів
- Результат: позиція 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 сценаріїв через 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 стратегії. Вартість розраховується індивідуально. Отримайте консультацію — ми оцінимо ваш проєкт та запропонуємо оптимальне рішення.
Замовте розробку системи захисту, щоб убезпечити свої кошти від неочікуваних ліквідацій.