Розробка бота ліквідацій для lending-протоколів

Розробка бота ліквідацій для 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%.

Розрив між повільним ботом і швидким — не в алгоритмі, а в інфраструктурі та деталях реалізації.

Кроки розробки ліквідаційного бота

1. Вибір протоколу та оцінка health factor. Вивчаємо інтерфейс liquidationCall, бонуси ліквідації, активи. Для Aave V3 типовий бонус — 5% (stablecoin) до 15% (volatile).
2. Проектування event-driven архітектури. Підписуємося на події Borrow, Deposit, Repay від протоколу та AnswerUpdated від Chainlink. Зберігаємо state в Redis з TTL 1 година.
3. Реалізація flash loan контракту. Пишемо Solidity-контракт, який позичає debt-токен через Aave, виконує ліквідацію, обмінює collateral через Uniswap V3 та повертає позику. Комісія flash loan — 0.09%.
4. Інтеграція private mempool. Надсилаємо транзакції через Flashbots Bundles (Ethereum) або приватні RPC (L2). Успішність ліквідації зростає в 10 разів.
5. Навантажувальне тестування. Симулюємо 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-ноди важлива не менше.

Архітектура бота

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

Зв'яжіться з нами для консультації з архітектури вашого майбутнього бота.