Відзначимо: коли ETH падає на 15% за годину, сотні позицій одночасно перетинають поріг ліквідації. Перший ліквідатор, який викликав absorb, забирає дисконтовані колатеральні активи. Другий — нічого. Це конкурентне середовище з мілісекундами: ліквідації Compound ловлять MEV-боти з прямими підключеннями до builder'ів і кастомними Rust-імплементаціями. Наша команда, яка має понад 7 років досвіду в DeFi і розробила понад 40 торгових та ліквідаційних ботів, будує рішення, яке працює в цьому середовищі. Середній прибуток на одну успішну ліквідацію становить $150–250, а економія на газі порівняно з наївним підходом сягає 35–45%.
Compound v3: новий підхід до ліквідацій
Відповідно до документації Compound v3 (Comet), ліквідація відбувається у два кроки: absorb і buyCollateral.
Compound v3 (Comet) кардинально відрізняється від v2 за моделлю ліквідацій. У v2 був liquidateBorrow — ліквідатор погашає борг за позичальника й отримує його колатераль з бонусом 8–15%. У v3 введена двохкрокова модель: absorb і buyCollateral. Profit на ліквідації у v3 надходить від арбітражу між ціною покупки у Comet та ринковою ціною. Бот повинен атомарно: викликати buyCollateral, продати отриманий актив на DEX, повернути base token. Flash loan з Aave або Uniswap v3 для фінансування — стандартний патерн.
Як визначити неспроможні позиції в реальному часі?
Позиція неспроможна, коли borrowing capacity нижче боргу. Compound v3 надає isLiquidatable(address account) та getBorrowableOf(…). Для моніторингу сотень тисяч позицій полінг кожної через eth_call — непрактично. Ефективний підхід — event-based моніторинг: слухаємо Supply, Withdraw, Transfer події від Comet, оновлюємо локальну копію станів. Коли ціна колатералю падає (подія Chainlink AnswerUpdated) — перераховуємо health factor для позицій з цим колатералем. Структура даних — sorted set у Redis за health factor, що дозволяє за O(log n) знаходити найближчі до ліквідації позиції.
| Параметр | Naive | Optimized |
|---|---|---|
| Виявлення | Polling кожні 12 сек | WebSocket + event-based (в 3 рази швидше) |
| Submission | Public mempool | Flashbots bundle |
| Gas price | Фіксований | Dynamic (80th percentile + boost) |
| Execution | EOA транзакція | Контракт-ліквідатор (1 tx) |
Архітектура бота
Моніторинг позицій
Детальніше про моніторинг
Два рівня: The Graph subgraph для історичних даних, WebSocket підписка через ethers.js provider.on або viem watchContractEvent для реального часу. Subgraph оновлюється із затримкою в 1–3 блоки — для конкурентних ліквідацій цього достатньо. Chainlink price feeds — через AggregatorV3Interface з перевіркою updatedAt (staleness check).
Smart contract ліквідатора
Атомарна ліквідація через flash loan:
contract CompoundLiquidator { function liquidate( address comet, address[] calldata accounts, address collateralAsset, uint baseAmount, address flashLoanPool // Uniswap v3 pool ) external { // 1. Flash loan base token з Uniswap v3 // 2. absorb(address(this), accounts) // 3. buyCollateral(collateralAsset, minOut, baseAmount, address(this)) // 4. Своп колатераля -> base token через DEX // 5. Повернення flash loan + fee // 6. Profit йде на msg.sender або treasury } } Критична деталь: absorb і buyCollateral — це два окремих виклики. Між ними інший бот може купити колатераль. Потрібно або перевіряти доступний колатераль перед покупкою (quoteCollateral), або прийняти, що в рідкісних випадках транзакція ревертується.
Profitability фільтр
Не кожна ліквідована позиція прибуткова. Перед відправкою транзакції розраховуємо: profit = buyCollateralValue * (1 - storeFrontPriceFactor) - flashLoanFee - gasCost - swapSlippage
Якщо profit < threshold (зазвичай $50–100 з урахуванням ризику) — пропускаємо.
Як ми будуємо ефективного бота?
- Аналіз архітектури Compound v3 та розгортання тестового середовища (Goerli/Sepolia).
- Розробка event-based моніторингу з Redis та health factor calculator.
- Реалізація смарт-контракту ліквідатора з flash loan.
- Комплексне тестування на форку mainnet.
- Деплой та налаштування моніторингу (алерти, логи).
- Документація та передача вихідного коду.
Атомарність викликів критична
Роздільні виклики absorb і buyCollateral створюють вікно для фронтраннінгу. Інший MEV-бот може помітити подію Absorb та перехопити покупку колатераля. Атомарність в одній транзакції (через контракт-агрегатор) усуває цей ризик.
Типові помилки та їх вирішення
| Помилка | Рішення |
|---|---|
| Ігнорування cooldown після absorb | Логіка retry з backoff |
| Неправильний розрахунок мінімального виходу | Динамічний розрахунок на основі oracle price з 1–2% buffer |
| Не перевіряються резерви протоколу | Перевірка getReserves() перед відправкою |
| Відсутність атомарності | Використання контракту-агрегатора для одного виклику |
Що входить у розробку?
- Повний аудит моделі ліквідацій та написання смарт-контракту ліквідатора (Solidity, з тестами на Foundry).
- Моніторинг-сервіс на TypeScript або Rust з event-based підпискою та Redis.
- Інтеграція з Flashbots для приватного мемпулу.
- Тестування на форку mainnet і dry-run в основній мережі.
- Розгортання та налаштування алертів (Telegram, Slack).
- Документація та передача вихідного коду з поясненнями.
- Підтримка протягом 1 місяця після запуску.
Орієнтири за термінами та вартістю
Базовий бот для Compound v3 на одному чейні — 2.5–3 тижні. Мультипротокольний бот (Compound + Aave + Euler) з MEV-оптимізацією — 6–8 тижнів. Реалізація для Arbitrum/Base додає 1 тиждень на кожен чейн. Вартість розраховується індивідуально; ми надаємо оцінку проєкту під ключ за 2 дні.
Зв'яжіться з нами для попередньої оцінки вашого проєкту — отримайте конкурентну перевагу на ринку ліквідацій. Ми гарантуємо якість та дотримання термінів. Отримайте консультацію з налаштування MEV-бота.