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