Розробка бота ліквідацій для кредитних протоколів
На Aave V3 позиція йде в ліквідацію, коли health factor падає нижче 1.0. У цей момент будь-хто може викликати liquidationCall() та отримати liquidation bonus — від 5% до 15% від розміру закладу залежно від активу. На крупних протоколах за одну транзакцію ліквідатор може заробити десятки тисяч доларів. За право бути першим конкурують сотні ботів з co-located серверами та оптимізованим газом.
Розрив між повільним ботом та швидким — не в алгоритмі, а в інфраструктурі та деталях реалізації.
Де конкурують ліквідаційні боти
Обнаруження позицій: polling vs event subscription
Наївний підхід — кожні N секунд запитувати список позицій через getUserAccountData. При тисячах активних позицій це неприйнятно: замало RPC-запитів, замало висока latency.
Правильний підхід — комбінація двох каналів:
Event subscription через WebSocket. Слухаємо Borrow, Deposit, `Repay» события протоколу. При кожній события обновляємо локальний state конкретного користувача. Не потрібно переопитувати все — тільки змінені позиції.
Price feed subscription. Слухаємо Chainlink AnswerUpdated события для всіх активів протоколу. Коли ціна активу змінюється — перераховуємо health factor для всіх позицій, що використовують цей актив як collateral або debt. Саме обновлення ціни oracle зазвичай триггерить ліквідації, а не дії користувача.
Комбінація двох каналів дає актуальний список кандидатів на ліквідацію з затримкою в одну-дві секунди після зміни стану on-chain.
Flash loan для ліквідації без капіталу
Класична ліквідація потребує тримати запас кожного debt-токену. При десятках активів у протоколі — дорого та неефективно. Стандартне рішення: flash loan із Aave або Balancer для отримання debt-токену, виклик liquidationCall(), обмін отриманого collateral на вихідний токен через Uniswap V3 або Curve, повернення flash loan. Весь цикл — одна транзакція.
Критичний момент — profitable path. Після flash loan fee (0.09% в Aave V3) та swap slippage/fee ліквідація повинна залишатись прибутковою. Бот повинен моделювати повну транзакцію через eth_call перед відправкою — інакше газ на revert транзакції теж потеря.
MEV та приватний mempool
Публічний mempool — смерть для ліквідаційного бота. Прибуткова транзакція буде sandwich-атакована або front-run MEV-ботом у ту ж секунду. Рішення — Flashbots Bundles (Ethereum) або приватні RPC-endpoints (Alchemy Private, BloxRoute). Транзакція йде напрямки валідатору, минаючи публічний mempool.
На L2 (Arbitrum, Optimism, Base) ситуація інша: sequencer централізований, MEV менш агресивний, але latency до sequencer-ноди важлива не менше.
Архітектура бота
| Компонент | Реалізація | Роль |
|---|---|---|
| State manager | In-memory + Redis | Позиції користувачів, health factors |
| Event listener | ethers.js WebSocket | Обновлення позицій та цін |
| Profitability calculator | On-chain simulation | eth_call до відправки |
| Executor | Flashbots / приватний RPC | Відправка без front-run |
| Flash loan handler | Solidity контракт | Атомарна ліквідація |
Liquidation контракт деплоїться окремо. Бот викликає його execute() функцію, передаючи параметри: адреса позичальника, debt token, collateral token, сума. Контракт виконує flash loan → ліквідація → swap → повернення. Прибуток залишається на контракті, бот періодично виводить.
Підтримка кількох протоколів
Aave V3, Compound V3 (Comet), Venus на BSC, Radiant — кожен має свій інтерфейс liquidationCall та свою логіку health factor. Використовуємо adapter-паттерн: загальний інтерфейс ILiquidator з реалізаціями під кожен протокол. Додати новий протокол = написати новий adapter без зміни core логіки.
Тестування та деплой
Fork-тесты на mainnet — обов'язкові. Foundry vm.createFork + vm.warp дозволяють відтворити історичну ліквідацію: беремо блок, в якому позиція була ліквідирована, запускаємо бота — він повинен її обнаружити та виконати. Це найкращий способ перевірити правильність розрахунків health factor.
Нагрузочний тест: 10 000 позицій у state manager, моделювання обновлення ціни всіх Chainlink feeds — бот повинен обробити чергу за < 500ms.
Деплой: сервер у тому ж регіоні, де хостяться Alchemy/Infura ноди (зазвичай us-east-1). PM2 або systemd для uptime. Моніторинг через Grafana: latency від события до транзакції, profit per liquidation, failed attempts.
Орієнтири по срокам
Базовий бот для одного протоколу (Aave) на одному чейні — 1-1.5 тижня. Мультипротокольний з flash loan executor та Flashbots інтеграцією — 2-3 тижні. Підтримка кількох чейнів з единим state manager — ще тиждень на чейн.