Розробка системи захисту від ліквідації DeFi-позицій

Розробка системи захисту від ліквідації

Позиція на $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 рази за часом реакції, оскільки спрацьовує в тому ж блоці, а не із затримкою опитування.

Вузьке місце: вартість Gelato/Chainlink Automation. При кожному виконанні стягується невелика фіксована плата, і при моніторингу кожні 30 секунд щомісячні витрати можуть становити близько $150 на одну позицію. Для позицій із заставою більше $50k це виправдано; для дрібних — ні.

Flash loan-based rebalancing

Якщо у користувача немає вільних коштів для поповнення застави, захист може використовувати flash loan. Алгоритм:

1. Взяти flash loan з Aave/Balancer в collateral token
2. Поповнити заставу в протоколі, що захищається
3. Зайняти debt token під нову, вищу заставу
4. Погасити flash loan з зайнятих коштів
5. Результат: позиція 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 ліквідація можлива коли:

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 при автоматичному свапі

Якщо захист вимагає свапа токена (продати частину застави -> 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 стратегії. Вартість розраховується індивідуально. Отримайте консультацію — ми оцінимо ваш проєкт та запропонуємо оптимальне рішення.

Замовте розробку системи захисту, щоб убезпечити свої кошти від неочікуваних ліквідацій.

Послуги з розробки DeFi-протоколів повного циклу

Ми проектуємо модульні DeFi-протоколи, в яких математика стейблкоїнів, ліквідності та оракулів працює без збоїв. Mango Markets — краш-тест: атакуючий маніпулював spot price через один акаунт, взяв кредит під завищений колатераль і вивів велику суму. Оракул брав ціну з єдиного джерела без TWAP. Не баг у коді — це архітектурне рішення, яке стало вразливістю. Наш досвід показує: будь-який DeFi-протокол — це система ставок на те, що всі компоненти, від розрахунків до економічних стимулів, вибудовані правильно одночасно.

Ми не пишемо код під «якщо все працює, не чіпай». Ми моделюємо стрес-сценарії: каскадні ліквідації, депег, флеш-позики. І тільки після цього — події, які не зламають протокол. Наші послуги з розробки DeFi-протоколів повного циклу охоплюють усі етапи — від архітектури до запуску та підтримки.

Чому оракули є критичним компонентом DeFi?

Більшість великих зломів DeFi починалися з маніпуляції оракулом. Розберемо три шари, які ми використовуємо в кожному проекті.

Spot price як оракул — не варіант. Uniswap v2 spot price можна зсунути flash loan за одну транзакцію. Ціна в кінці блоку — єдине, що потрапляє в state, її і читає оракул. Схема атаки: зайняти через flash loan → купити актив у пул → ціна піднялася → взяти кредит під завищений колатераль → продати актив → повернути flash loan. Одна транзакція.

TWAP як захист. Uniswap v3 observe() усереднює ціну за період (30 хвилин). Маніпуляція вимагає утримувати ціну кілька блоків — це коштує дорого. Але TWAP повільно реагує на легітимні зміни, що відкриває вікно для arbitrage на ліквідації при різких рухах.

Chainlink Price Feeds — агрегація від багатьох data providers з медіаною. Стандарт для lending. Проблема: heartbeat 1–24 години та deviation threshold 0.5%. Якщо ціна не рухається, фід може не оновлюватися добу. У волатильному ринку — lag.

У продакшені ми використовуємо дворівневу перевірку: Chainlink aggregator + Uniswap v3 TWAP як верифікатор. Якщо розбіжність більша за N% — транзакція відхиляється, система ставиться на паузу.

Як захистити DeFi-протокол від атак флеш-позик?

Flash loan перетворює будь-якого користувача на володаря необмеженого капіталу на одну транзакцію. Тому при проектуванні контрактів ми припускаємо: доступ до необмеженого капіталу є у всіх. Це змінює threat model повністю.

Легітимні застосування flash loan — арбітраж, ліквідація, самоліквідація. Але протокол повинен перевіряти, що позика не використовується для маніпуляції: оракул не повинен читати ціну з пулу, який можна зсунути за одну транзакцію. Ми додаємо перевірки на block.timestamp та мінімальну глибину ліквідності.

Як ми забезпечуємо безпеку DeFi-протоколу?

Ми не покладаємося на один шар захисту. Кожен контракт проходить формальну верифікацію математичної моделі, стресове тестування на форку mainnet та аудит щонайменше двома незалежними командами (серед яких сертифіковані аудитори ConsenSys Diligence). Гарантія — багаторічний досвід розробки та супроводу протоколів із сукупним TVL понад $500M.

Ключові компоненти DeFi-архітектури

AMM: від x*y=k до concentrated liquidity

Uniswap v2 використовує x * y = k. LP-токени ERC-20 — кожен пул випускає свій токен пропорційно частці. Проблема: ліквідність розмазана по всій кривій, більша частина не використовується.

Uniswap v3 та позиції ERC-721: concentrated liquidity — LP надає ліквідність у діапазоні [priceLow, priceHigh]. Capital efficiency до 4000x для стабільних пар. Але ERC-721 ламає vault-стратегії під ERC-20. Управління ranges — окрема інженерна задача: позиція виходить з діапазону при русі ціни, перестає заробляти fees, стає single-asset. Протоколи типу Arrakis Finance автоматично rebalance. Якщо будуєте vault поверх v3, потрібен власний range manager або інтеграція з існуючим.

Slippage у v3 розраховується через sqrtPriceX96 — 96-бітна fixed-point математика. Помилки на фронтенді призводять до розбіжності між видимим і фактичним slippage.

Curve для пар з близькими цінами (stablecoin/stablecoin, stETH/ETH) використовує інваріант, що комбінує constant product і constant sum. Менше slippage в діапазоні peg. Контракти на Vyper, код математично щільний, аудитувати складно.

Lending протоколи: collateral, liquidation, bad debt

LTV визначає максимальний кредит під колатераль. Liquidation threshold — рівень ліквідації. Різниця — буфер для liquidator. Типовий приклад: LTV 75%, liquidation threshold 80%, bonus 5%. Якщо ціна падає на 20%+, позиція відкрита до ліквідації.

Каскадні ліквідації: багато позицій ліквідується одночасно → ліквідатори продають колатераль → ціна падає → наступна хвиля. LUNA/UST — класичний каскад.

Якщо колатераль знецінюється швидше ліквідації, протокол отримує bad debt. Aave використовує Safety Module (застейканий AAVE), Compound — reserves. Без backstop bad debt соціалізується через dilution supply-токена або взаємозалік.

Проектування системи ліквідації вимагає моделювання стрес-сценаріїв: падіння єдиного liquidation bot, високий gas, делістинг колатералю.

Yield farming та incentive mechanics

Liquidity mining — роздача токенів управління LP-провайдерам. Проблема mercenary capital: фармери приходять, продають токени, йдуть. TVL фіктивний.

Стійкі механіки: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking з penalty. Ve-модель при неправильній реалізації створює governance concentration. Потрібен timelock на зміни gauge weights та ліміти на votingPower.

Що входить у нашу розробку DeFi-протоколів

• Архітектурна документація: діаграми взаємодії контрактів, стрес-тести ліквідацій, розрахунки оракулів.
• Реалізація на Solidity 0.8.x з OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) та Solmate для gas-optimised base contracts.
• Foundry fork-тести на реальному mainnet (Uniswap, Chainlink, Aave) — тести до деплою покривають всі сценарії. Завдяки Foundry час тестування скорочується на 80% порівняно з Hardhat.
• Аудит: мінімум два незалежних аудитори для TVL від значного рівня. Code4rena або Sherlock для bug bounty.
• Деплой з Gnosis Safe 3/5 multisig + timelock 48–72 години.
• Моніторинг через Tenderly (alerts, симуляції), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
• Підтримка після запуску: оновлення, патчі, апгрейди через proxy.

Наші компетенції та досвід

Ми розробляємо DeFi-протоколи з моменту активного розвитку ринку — за цей час реалізували 30+ проектів із загальним TVL понад $500M. Серед клієнтів — протоколи в топ-20 за TVL на Ethereum, Arbitrum та Base. Команда сертифікованих розробників Solidity, які пройшли аудиторські треки ConsenSys Diligence. Гарантія якості підтверджена багаторічним досвідом та відсутністю інцидентів після запуску.

Терміни

• DEX з AMM (Uniswap v2 fork): 6–10 тижнів
• Lending protocol (Aave-style, один колатераль): 3–5 місяців
• Yield aggregator з кількома стратегіями: 2–4 місяці
• Повноцінний DeFi-протокол з governance: 5–8 місяців включаючи аудит

Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Отримайте консультацію з архітектури DeFi-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.