Разработка бота ликвидаций для 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 typical bonus — 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 перед отправкой — иначе gas на реверт транзакции тоже потеря. Согласно официальной документации 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. За 5 лет мы реализовали более 30 ботов для ликвидаций, арбитража и MEV. Гарантируем uptime 99.9% и стабильную прибыльность. Оценим ваш проект за 2 дня — напишите нам. Получите консультацию по архитектуре и выбору протоколов.

Свяжитесь с нами для консультации по архитектуре вашего будущего бота.