Почему торговый бот на Arbitrum теряет прибыль в DEX
Бот, который в тестах показывает ровную доходность, в реальном пуле Arbitrum нередко работает в минус — и дело не в ошибке стратегии. Между сигналом и исполнением сделки проходит время, за которое цена успевает уйти. Торговый бот в DEX на Arbitrum теряет именно на этом разрыве, и причины потерь раскладываются на четыре измеримые точки.
Первая — опережение сделок сторонними участниками. Заявка на доли секунды попадает в публичную очередь необработанных транзакций, её видят другие и успевают поставить свою сделку перед ней: цена в пуле сдвигается, а бот исполняется по худшей. Вторая — потери на проскальзывании: когда объём позиции сопоставим с глубиной пула, каждый следующий ордер в маршруте забирает ликвидность дороже, и расчётная доходность съедается уже на входе в позицию и на выходе из неё.
Третья точка — задержка реакции на цену и обрывы связи с сетью. Если узел отвечает с запозданием, котировка в момент подписи транзакции уже устарела, а после разрыва канала бот возвращается к работе с открытой позицией и устаревшим представлением о балансе. Четвёртая — неудачные транзакции: условие исполнения изменилось между оценкой и отправкой, сделка не проходит, но её стоимость списывается, а повторная отправка без учёта нового состояния пула даёт дубли и лишние позиции.
Все четыре точки измеряются одинаково — долей сделок, где фактическая цена исполнения отличается от ожидаемой. Ниже разбираем, как это закрывается: логикой маршрутизации ордера, отправкой транзакций в обход публичной очереди и жёстким контролем проскальзывания на каждой сделке.
Измеримый результат: прибыль на сделку и устойчивость к сбоям
Отсчёт идёт от замера до внедрения: медианное время от сигнала до попадания ордера в блок, доля отклонённых сделок за сутки, поведение при недоступности узла, максимальная просадка по одной позиции. Те же метрики снимаются после — на сопоставимой волатильности рынка, иначе сравнение ничего не доказывает.
Скорость исполнения ордера в сети Arbitrum перестаёт зависеть от единственного маршрута: заявка уходит в несколько источников ликвидности, комиссия пересчитывается перед отправкой, а отклонённая транзакция собирается заново по актуальной цене. Доля отклонённых сделок падает за счёт повторных попыток и проверки состояния пула до подписи — в журнале остаются единичные случаи с разобранной причиной.
Устойчивость к сбоям узла держится на резервных подключениях: бот опрашивает несколько независимых источников, при расхождении данных берёт подтверждённое большинством значение и переключается без остановки стратегии. Позиции сохраняются на диск, поэтому время восстановления бота измеряется секундами, а не ручным разбором открытых ордеров.
Контроль риска на сделку задаётся явными лимитами: доля депозита на позицию, число одновременных входов, предел убытка за сессию и аварийная остановка при выходе за них. Здесь метрика — максимальная просадка: до внедрения её сдерживал оператор, после — правило, срабатывающее раньше него. Все пять величин видны в панели метрик, поэтому результат подтверждается данными, а не ощущением, что бот стал работать лучше.
Варианты стратегий: арбитраж, маркет-мейкинг, снайпинг
Стратегия определяет не только логику сигналов, но и архитектуру бота: как он читает состояние пула, как отправляет транзакции и где выставляются защиты. Арбитражные схемы в DEX живут на расхождении цены, маркет-мейкинг — на потоке сделок, снайпинг новых пулов — на скорости входа. Ниже — сравнение по условиям применения и по тому, что каждый подход реально ограничивает.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Арбитраж между пулами | Одна пара торгуется в двух пулах или внутри сети и на внешней площадке с устойчивым расхождением цены | Прибыль забирает тот, кто попал в блок первым; нужна приватная отправка транзакций и корректный расчёт проскальзывания сразу на обеих ногах |
| Маркет-мейкинг | Пул с предсказуемым потоком, бот держит двусторонние котировки и пересчитывает их по спреду | Риск накопить одностороннюю позицию при резком движении; требуются лимиты на размер позиции и пауза при волатильности |
| Снайпинг новых пулов | Ликвидность только добавлена, цена ещё не выровнена относительно рынка | Высокая конкуренция за первый блок, риск токенов с запретом на продажу; жёсткий контроль газа и лимит по проскальзыванию |
Выбор пары и пула часто важнее самой стратегии. Смотрим на глубину пула, размер комиссии, число активных поставщиков ликвидности и то, насколько цена внутри пула отклоняется от внешней. Лимиты по проскальзыванию считаем не константой, а функцией от размера ордера к глубине — на тонком пуле первая же крупная сделка съедает всю прибыль.
Защита от MEV строится поверх любой из трёх схем: приватный канал отправки, разделение сигнала и исполнения, отмена заявки, если состояние пула изменилось до включения в блок. Стратегии комбинируются, но тогда растёт сложность — у каждой нужны свои метрики и свой порог остановки.
Этапы работы: аудит сценария, схема, запуск, надзор
Разработка торгового бота для DEX на Arbitrum начинается со сценария, а не с кода: что считаем прибылью, на каких парах работаем, какой размер позиции держим и как ведём себя при проскальзывании. Ниже — этапы разработки бота, где каждый шаг закрывается проверяемым артефактом, а не отчётом о проделанной работе.
- Разбор сценария. Фиксируем пулы и пары, пороги входа и выхода, лимиты на сделку и на день, поведение при резком движении цены.
- Проектирование схемы. Разводим потоки: получение цен, хранение ключей, отправка транзакций, учёт позиций. Отдельно — резервный путь, если основной узел сети недоступен.
- Сборка. Модули расчёта, исполнения и логирования изолируем: отказ одного не останавливает остальные.
- Проверка на тестовом контуре. Прогон на копии состояния сети и на исторических данных — расхождение между расчётной и фактической сделкой видно до выхода в основную сеть.
- Калибровка защиты от MEV. Выбираем способ отправки транзакций, минимальный выход и предел комиссии, при котором сделка остаётся выгодной.
- Запуск на малом объёме. Первые дни бот торгует долей от целевого размера позиции: исполнение проверяется на живых блоках без полной ставки.
- Передача под надзор. Отдаём регламент остановки торговли — при каком расхождении учёта, серии отказов или отклонении цены бот встаёт сам и кто возвращает его в работу.
Дальше идёт сопровождение: сверка учёта с историей сети, разбор отклонений и правки порогов по фактическим данным.
Что передаём: исходный код, схемы, ключи, регламенты
Мы передаём не «работающий скрипт на сервере», а полный контур: код, схему взаимодействия с сетью, политики доступа и регламенты, по которым систему можно развивать своей командой или отдать другому подрядчику без обратной разработки. По каждому пункту ниже — отдельный артефакт, который остаётся у вас.
- Исходный код бота — хранилище с историей изменений, разбитое на модули расчёта маршрута, подписи сделок и контроля риска; сборка воспроизводится на чистом окружении одной командой, без скрытых зависимостей.
- Схема архитектуры — как бот читает состояние пулов, где принимает решение, где подписывает и где отправляет транзакцию в Arbitrum; отмечены внешние сервисы, точки отказа и границы доверия.
- Управление ключами и правами — роли разделены: ключ исполнения сделок лежит отдельно от ключа вывода средств, лимиты и допуски заданы на уровне политики, а не в коде.
- Наблюдаемость и оповещения — метрики исполнения, доля отклонённых и отменённых транзакций, панель состояния и сигналы в согласованный канал при выходе за пороги; отдельно фиксируются случаи невыгодного исполнения в пуле.
- Инструкции по аварийной остановке — пошаговый порядок: как остановить торговлю, отозвать выданные боту права, вывести средства и кто принимает это решение.
- Регламенты эксплуатации — обновление параметров стратегий, ротация ключей и разбор инцидентов по заранее описанному сценарию.
Кейс: как убрали потери от опережения сделок
Торговый бот для пулов на Arbitrum держал узкий спред и переставлял котировки каждые несколько блоков. Заявки уходили в публичный мемпул обычной транзакцией, и часть прибыли забирали сэндвич-атаки: чужой бот встраивался до и после нашей сделки и сдвигал цену исполнения в свою пользу.
Что было до
На замерах перед стартой работ доля сделок, закрытых хуже расчётной цены, держалась около четверти от общего числа. Один и тот же класс отказов повторялся ежедневно: опережение, невыгодное исполнение, пересчёт стратегии на ходу. Часть позиций приходилось перекрывать обратным ордером, и на волатильности бот терял больше, чем зарабатывал на спреде.
Что изменили
Отправку ордеров перевели в приватные каналы доставки, где транзакция попадает к валидатору минуя публичный мемпул. Крупные заявки разбили на части с разнесением по времени, а обновление котировок привязали к состоянию пула, а не к фиксированному интервалу. Логику защиты вынесли отдельным слоем — стратегия перестала зависеть от того, как именно исполняется ордер.
После переезда доля невыгодных исполнений упала с 24% до 3%, разброс между расчётной и фактической ценой сделки сократился примерно втрое. Класс отказов «опережение и сэндвич» перестал повторяться: за период наблюдения не зафиксировано ни одного случая встраивания чужого бота в нашу сделку. Заказчик подтверждает, что доходность стратегии стала предсказуемой на отрезке в несколько недель, а не скакала от недели к неделе.
Что делать, если бот уже работает и теряет на опережении?
Бот теряет на опережении, когда его заявка попадает в публичный пул и становится видна чужим стратегиям: они поднимают цену перед исполнением или забирают ликвидность первыми. Диагностику начинают с трёх метрик — доля сделок, отменённых из-за расхождения цены, разрыв между расчётной и фактической ценой исполнения и время от сигнала до включения в блок. Если разрыв растёт вместе с загрузкой сети, дело не в логике стратегии, а в том, как заявка доходит до блока.
Первое, что усиливают, — слой доставки. Вместо публичного пула заявка уходит в частные каналы отправки, которые передают её напрямую составителям блоков; в Arbitrum такой слой доступен у нескольких поставщиков инфраструктуры. Настраивают два-три независимых канала с балансировкой между ними: если один перестаёт принимать заявки, бот продолжает работать по резервному, а не встаёт. Приоритет исполнения задают отдельно под каждую стратегию — чтобы быстрый вход не вытеснял арбитраж в том же блоке.
Ядро переписывать не нужно. Расчётные модули, оценка риска, работа с пулами ликвидности остаются как есть — меняется транспорт заявки и правила приоритета. Это доработка существующего бота, а не новая сборка: сохраняются проверенные стратегии, накопленная статистика исполнения и выставленные лимиты.
Результат замеряем на тех же метриках: доля заявок, исполненных по цене не хуже расчётной, время до включения в блок, доля отказов при пиковой загрузке сети. Именно они, а не доходность отдельной сделки, показывают, что опережение закрыто.
Технические сомнения: ликвидность, комиссии, простои
Перед стартом обычно задают одни и те же пять вопросов — не про стратегию, а про поведение бота при росте комиссий, изоляции ключа или падении процесса прямо в момент сделки. Ниже — предметные ответы.
Как бот ведёт себя при росте комиссий сети?
Перед отправкой прогноз комиссии сверяется с ожидаемым спредом: если стоимость газа съедает прибыль, ордер не уходит. На пиках активности стратегия не превращается из прибыльной в убыточную по факту.
Где хранятся ключи и кто имеет к ним доступ?
Подпись вынесена в изолированный процесс: закрытый ключ не покидает его и не попадает ни в логи, ни в файлы конфигурации. Торговая логика передаёт только параметры сделки — права бота не дают доступа к средствам.
Что происходит после сбоя или перезапуска?
Состояние позиций и незакрытых заявок фиксируется до отправки транзакции, поэтому после перезапуска бот сверяет свой журнал с балансом в сети и не дублирует сделки. Открытые позиции доводятся до целевого состояния либо закрываются по заданному правилу.
Как ограничиваете проскальзывание?
В параметрах транзакции стоит жёсткий предел проскальзывания: при худшей цене сделка отменяется, а не исполняется. Объём распределяется по нескольким пулам, поэтому просадка ликвидности в одном не перекашивает цену исполнения.
Что защищает от опережающих сделок в очереди?
Отправка идёт по приватному каналу до сборщика блоков, где транзакция не видна до включения в блок. Дополнительно ограничиваем время жизни заявки, чтобы зависший ордер не исполнился на невыгодных условиях.
Обсудим задачу: вернёмся с оценкой и планом запуска
Чтобы вернуться с оценкой и планом запуска, а не с общими формулировками, нам нужен ваш сценарий торговли в измеримом виде. Ниже — входные данные от заказчика, по которым мы считаем объём работ, называем сроки и порядок этапов.
Бот для DEX на Arbitrum мы собираем вокруг трёх вещей: логика стратегии, исполнение сделок и защита от MEV. Поэтому и сбор данных начинается со стратегии, а не с кода.
- торговые пары и пулы, где планируется работа, с оценкой текущей ликвидности;
- логика входа и выхода: какое событие считаем сигналом, с какой периодичностью проверяем состояние рынка;
- ограничения по риску: максимальный размер позиции, допустимое проскальзывание, поведение при резком движении цены;
- режим работы: только расчёт и сигналы или автоматическое исполнение сделок;
- требования к защите: приватная отправка транзакций, лимиты на комиссию, отмена зависших операций;
- доступы: адрес кошелька для исполнения, аппаратный подписант или ключи, права на инфраструктуру;
- ожидаемая нагрузка: сколько сделок в сутки и сколько пулов одновременно в работе.
Когда картина сходится, мы разбиваем работу на этапы и по каждому называем срок и точку проверки результата — от прототипа стратегии на исторических данных до запуска с мониторингом. Опишите задачу в этом объёме, и мы вернёмся с оценкой и планом запуска.
