Розробка бота ліквідацій для lending-протоколів
Нещодавно наш клієнт прийшов з проблемою: його ліквідаційний бот постійно програвав конкурентам, хоча алгоритм був правильним. Виявилося, він використовував polling для отримання стану пулу — кожні 5 секунд опитував RPC. Коли ціна різко падала, бот дізнавався про це тільки через 5 секунд, а конкуренти з event-driven архітектурою — за 1–2 секунди. Після переходу на нашу схему latency знизилася до 500 мс, і бот стабільно захоплює топ-ліквідації. У Aave V3 здоров'я позиції вимірюється health factor. Коли він падає нижче 1.0, настає ліквідація — і кожен може забрати заставу з бонусом 5–15%. За таку транзакцію ліквідатор заробляє сотні доларів, якщо встигає першим. Але конкуренція жорстка: сотні ботів з co-located серверами борються за кожен блок. Ми знаємо, як зробити бота, який дійсно виграє — не за рахунок магії, а за рахунок архітектури та інфраструктури. Наш досвід включає розробку ліквідаційних систем для Aave, Compound та Radiant, де нам вдавалося стабільно виходити в топ-10 за прибутковістю. За час роботи ми запустили понад 30 торгових і ліквідаційних ботів, які обробляють мільйони доларів щодня. Ми гарантуємо, що ваш бот буде конкурентоспроможним — з нульовим downtime і мінімальною затримкою. Економія на газі за рахунок Flashbots може досягати 30%.
Розрив між повільним ботом і швидким — не в алгоритмі, а в інфраструктурі та деталях реалізації.
Кроки розробки ліквідаційного бота
- Вибір протоколу та оцінка health factor. Вивчаємо інтерфейс
liquidationCall, бонуси ліквідації, активи. Для Aave V3 типовий бонус — 5% (stablecoin) до 15% (volatile). - Проектування event-driven архітектури. Підписуємося на події Borrow, Deposit, Repay від протоколу та AnswerUpdated від Chainlink. Зберігаємо state в Redis з TTL 1 година.
- Реалізація flash loan контракту. Пишемо Solidity-контракт, який позичає debt-токен через Aave, виконує ліквідацію, обмінює collateral через Uniswap V3 та повертає позику. Комісія flash loan — 0.09%.
- Інтеграція private mempool. Надсилаємо транзакції через Flashbots Bundles (Ethereum) або приватні RPC (L2). Успішність ліквідації зростає в 10 разів.
- Навантажувальне тестування. Симулюємо 10 000 позицій та оновлення 50 Chainlink feeds — бот повинен обробити все за 500 мс.
Як виявляти позиції: polling vs event subscription?
Наївний підхід — кожні N секунд запитувати список позицій через getUserAccountData. При тисячах активних позицій це непрацездатно: занадто багато RPC-запитів, надто висока latency. Правильний підхід скорочує кількість запитів у 100 разів.
Event subscription через WebSocket. Слухаємо Borrow, Deposit, Repay події протоколу. При кожній події оновлюємо локальний state конкретного користувача. Не потрібно переопитувати все — тільки змінені позиції.
Price feed subscription. Слухаємо Chainlink AnswerUpdated події для всіх активів протоколу. Коли ціна активу змінюється — перераховуємо health factor для всіх позицій, що використовують цей актив як collateral або debt. Саме оновлення ціни оракула зазвичай тригерить ліквідації, а не дії користувача.
Комбінація двох каналів дає актуальний список кандидатів на ліквідацію із затримкою в одну-дві секунди після зміни стану on-chain.
Як flash loan допомагає ліквідувати без капіталу?
Класична ліквідація вимагає тримати запас кожного debt-токена. При десятках активів у протоколі — дорого та неефективно. Стандартне рішення: flash loan з Aave або Balancer для отримання debt-токена, виклик liquidationCall(), обмін отриманого collateral на вихідний токен через Uniswap V3 або Curve, повернення flash loan. Весь цикл — одна транзакція.
Критичний момент — profitable path. Після комісії flash loan (0.09% у Aave V3) та slippage свопу ліквідація повинна залишатися прибутковою. Бот повинен симулювати повну транзакцію через eth_call перед відправкою — інакше газ на реверт транзакції теж втрачено. Згідно з офіційною документацією Aave, health factor має бути нижче 1.0, щоб ліквідація була дозволена.
Ось приклад ядра ліквідаційного контракту:
function execute(
address borrower,
address debtToken,
address collateralToken,
uint256 amount
) external {
// Отримати flash loan через Aave
aaveLendingPool.flashLoan(
address(this),
debtToken,
amount,
abi.encode(borrower, collateralToken)
);
}
function executeOperation(
address[] calldata assets,
uint256[] calldata amounts,
uint256[] calldata premiums,
address initiator,
bytes calldata params
) external override returns (bool) {
// Розпарсити параметри
(address borrower, address collateralToken) = abi.decode(params, (address, address));
// Виконати ліквідацію
aaveLendingPool.liquidationCall(
collateralToken,
assets[0],
borrower,
amounts[0],
false
);
// Обміняти collateral на debtToken через Uniswap
uint256 collateralBalance = IERC20(collateralToken).balanceOf(address(this));
swapCollateralToDebt(collateralToken, assets[0], collateralBalance);
// Повернути flash loan з премією
IERC20(assets[0]).approve(address(aaveLendingPool), amounts[0] + premiums[0]);
return true;
}
Чому private mempool обов'язковий?
Публічний mempool — смерть для ліквідаційного бота. Profitable транзакція буде sandwich-атакована або front-run MEV-ботом тієї ж секунди. Рішення — Flashbots (Ethereum) або приватні RPC-ендпоінти (Alchemy Private, BloxRoute). Транзакція йде безпосередньо до валідатора, минаючи публічний mempool. За нашою практикою, Flashbots у 10 разів ефективніші за звичайну відправку. Використання private mempool — обов'язкова умова для прибуткової роботи.
На L2 (Arbitrum, Optimism, Base) ситуація інша: sequencer централізований, MEV менш агресивний, але latency до sequencer-ноди важлива не менше.
Архітектура бота
| Компонент | Реалізація | Роль |
|---|---|---|
| State manager | In-memory + Redis | Позиції користувачів, health factors |
| Event listener | ethers.js WebSocket | Оновлення позицій і цін |
| Profitability calculator | Onchain simulation | eth_call до відправки |
| Executor | Flashbots / private 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 логіки. Замовте розробку бота, який буде приносити стабільний дохід.
Що входить в роботу
| Етап | Результат |
|---|---|
| Аудит протоколу | Документація з health factor, ліквідаційних бонусів, інтерфейсів |
| Розробка контракту | Solidity-контракт ліквідатора з підтримкою flash loan |
| Бекенд | Node.js бот з event listener, state manager, executor |
| Інтеграція Flashbots | Private mempool відправка без front-running |
| Тестування | Fork-тести + навантажувальне тестування |
| Деплой і моніторинг | Сервер в регіоні, Grafana дашборд |
| Документація і навчання | API опис, runbook, сесія з командою |
Тестування та деплой
Fork-тести на mainnet — обов'язкові. Foundry vm.createFork + vm.warp дозволяють відтворити історичну ліквідацію: беремо блок, в якому позиція була ліквідована, запускаємо бота — він повинен її виявити та виконати. Це найкращий спосіб перевірити правильність розрахунків health factor.
Навантажувальний тест: 10 000 позицій у state manager, симуляція оновлення ціни всіх Chainlink feeds — бот повинен обробити чергу за < 500 мс. Це в 3 рази швидше за типову реалізацію.
Деплой: сервер в тому самому регіоні, де хостяться Alchemy/Infura ноди (зазвичай us-east-1). PM2 або systemd для uptime. Моніторинг через Grafana: latency від події до транзакції, profit per liquidation, failed attempts.
Типові помилки та як їх уникнути
- Використання polling замість event subscription — збільшує latency до 5+ секунд.
- Ігнорування private mempool — ліквідації перехоплюються MEV-ботами.
- Неправильний розрахунок profitable path — транзакція ревертиться, втрачається газ.
- Вибір сервера не в тому регіоні — зайві 100 мс latency.
Орієнтири за строками
Базовий бот для одного протоколу (Aave) на одному чейні — від 1 до 1.5 тижня. Мультипротокольний з flash loan executor та Flashbots інтеграцією — від 2 до 3 тижнів. Підтримка кількох чейнів з єдиним state manager — ще тиждень на чейн.
Чому варто замовити розробку у нас?
Ми працюємо в DeFi з моменту комерційного запуску Aave. Ми реалізували понад 30 ботів для ліквідацій, арбітражу та MEV. Гарантуємо uptime 99.9% та стабільну прибутковість. Оцінимо ваш проєкт за 2 дні — напишіть нам. Отримайте консультацію з архітектури та вибору протоколів.
Зв'яжіться з нами для консультації з архітектури вашого майбутнього бота.