Трикутний арбітраж: де алгоритм втрачає прибуток
Трикутний арбітраж виглядає як безризикова операція: алгоритм помічає розбіжність між трьома парами й проходить замкнений цикл у межах одного майданчика.
На папері прибуток рахують за останніми угодами, але зв'язка з трьох пар виконується послідовно — і кожна нога змінює умови для наступної.
Перше джерело втрат — прослизання під час виконання. Поки друга нога доходить до стакана, найкращу ціну вже вибрали сусідні роботи, і ордер проходить за рівнями нижче.
На вузьких парах навіть невеликий обсяг зсуває котирування на десяті частки відсотка, а таких зсувів у циклі три, і вони додаються.
Друге — комісії торгових майданчиків. Їх платять на кожному плечі, плюс спред, плюс переказ коштів між біржами, якщо цикл міжбіржовий. Різниця, яку ловить алгоритм, нерідко зіставна із сумою витрат, тому розрахунок за верхніми котируваннями показує прибуток там, де його немає.
Третє й найнебезпечніше — часткове виконання ордера разом із затримкою відгуку майданчиків. Поки третя нога чекає підтвердження, ціна йде, і половина зв'язки залишається відкритою: замість замкненого циклу ми отримуємо спрямовану позицію, яку ринок може розвернути проти нас.
Далі розбираємо, як це закривається: де ставити фільтри за ліквідністю, як рахувати прибуток з урахуванням витрат на всіх трьох ділянках і що робити з ногами, які не виконалися.
Що дає автоматичний пошук зв'язок у реальному часі
Ручний пошук зв'язок обмежений увагою трейдера: поки рахується один трикутник, ціна в двох інших ногах уже пішла.
Автоматичний пошук зв'язок працює інакше — контур безперервно перебирає трикутники за трьома інструментами, рахує результат з урахуванням комісій, спреду й доступної глибини стакана та відкидає цикли, де витрати з'їдають різницю.
Ключова метрика тут не «скільки зв'язок знайшлося», а частка прибуткових циклів — частка тих, що дійшли до закриття всіх трьох ніг з позитивним підсумком.
Швидкість реакції контуру вирішує, чи дійде сигнал до стакана: між розрахунком і виставленням першої ноги є вікно, у якому ціна змінюється.
Тому три заявки будуються паралельно, а не послідовно, і решта ніг перераховуються одразу за часткового виконання — цикл або закривається повністю, або розбирається з мінімальним залишком.
Окрема частина роботи — урахування лімітів біржі: на Binance частота запитів перераховується динамічно, і темп знижується заздалегідь, а не після блокування.
Контроль ризику на угоду задається до старту: ліміт обсягу на цикл, ліміт на інструмент і на біржу, заборона пересічних трикутників. Якщо одна нога не набралася, спрацьовує правило виходу — розворот у ринок або скасування залишку.
Журнал виконання пише кожну ногу: час відправлення й спрацювання, фактичну ціну, обсяг і причину відмови. За ним видно, де саме втрачається результат — у затримці, у комісії чи в ліквідності.
Режими виконання: порівняння підходів до угод
Автономність контуру — змінна, а не властивість. Один і той самий трикутний арбітраж можна вести в трьох режимах: від спостереження за зв'язками до повного автовиконання. Різниця в тому, хто ухвалює рішення про вхід і скільки перевірок стоїть між сигналом і ордером.
| Режим | Коли підходить | Що обмежує |
|---|---|---|
| Режим моніторингу | Первинна перевірка гіпотези, незнайомі майданчики, тонкі пари | Угоди вручну — реакція запізнюється, вікно розбіжності закривається до входу |
| Напівавтоматичне виконання | Робот рахує зв'язку й готує ордери, людина підтверджує | Підтвердження додає затримку, частина зв'язок не переживає очікування |
| Повне автовиконання | Відпрацьовані сценарії, стабільна ліквідність | Помилка налаштування тиражується без зупинки — потрібні жорсткі ліміти |
Незалежно від режиму контур збираємо з лімітами на позицію: ліміт на обсяг однієї зв'язки, на обсяг за кожним майданчиком і на сумарний обсяг за всіма парами.
У розподіленому контурі вузли моніторингу й виконання рознесені — збій одного майданчика не зупиняє решту зв'язок, а черга сигналів продовжує оброблятися.
Перемикання режимів робимо параметром, а не переписуванням логіки. Ви починаєте зі спостереження, вмикаєте підтвердження угод, потім знімаєте його на сценаріях, які відпрацювали без розбіжностей.
Як будується алгоритм: етапи інженерної роботи
Ціна помилки в арбітражному ланцюжку — не неправильний розрахунок, а нога, що зависла без закриття: прослизання й затримка між майданчиками з'їдають спред швидше, ніж приходить сигнал.
Тому алгоритм збираємо етапами, і кожен етап закінчується артефактом, за яким ухвалюється рішення про перехід далі.
- Аудит торгових майданчиків. Відбираємо біржі з потрібними парами, зіставною ліквідністю й передбачуваними комісіями. Перевіряємо ліміти на виведення, методи поповнення й стабільність потоку котирувань — ланцюжок не повинен упиратися в інфраструктуру майданчика.
- Схема зв'язок. Будуємо граф пар виду A→B→C→A і відсікаємо ланцюжки, де комісії з'їдають спред. Для кожної зв'язки фіксуємо поріг входу й допустиме прослизання.
- Математична модель. Рахуємо розмір позиції з урахуванням комісій тейкера й мейкера, глибини стакана й затримки між майданчиками. Визначаємо, як розподіляється обсяг за ногами й де ставиться стоп.
- Перевірка на історії. Прогін на накопичених даних з реальними комісіями, відмовами й затримками. Дивимося, скільки зв'язок виживає після витрат, і прибираємо хибні сигнали.
- Виконавчий контур. Відправлення ордерів, контроль часткового виконання й логіка аварійного закриття ноги. Окремо прописуємо правила зупинки при розбіжності балансу.
- Запуск на малих обсягах. Робота на реальному ринку з обмеженим розміром позиції: звіряємо фактичні витрати з модельними й правимо пороги входу.
- Передача в експлуатацію. Віддаємо контур з налаштуваннями, оповіщеннями й регламентом зупинки, навчаємо команду замовника.
Послідовність не дає перейти до реальної торгівлі, поки модель не підтверджена витратами ринку.
Що входить у постачання: код, конфігурації, регламенти
Здача проєкту — це не демонстрація вдалої зв'язки на екрані, а комплект, з яким ваші інженери можуть самостійно запускати, супроводжувати й розвивати контур.
Кожен артефакт передаємо в тому вигляді, у якому самі ним користуємося: з описом параметрів, меж застосовності й порядку дій при відхиленнях.
- Вихідний код контуру — модулі збору ринкових даних, розрахунку зв'язок, планування й виставлення заявок, обліку балансів. Репозиторій з історією змін і відтворюваною збіркою, без закритих залежностей, які ви не зможете підтримувати власними силами.
- Файли конфігурації — пороги дохідності, ліміти на розмір однієї позиції й сумарний обсяг відкритих позицій, обмеження за часом очікування відповіді, переліки торгових пар і майданчиків. Розділені за середовищами, щоб тестовий прогін фізично не міг відправити реальну заявку.
- Панель спостереження — активні зв'язки, відхилені сигнали із зазначенням причини відмови, стан каналів отримання даних, затримка виконання й розбіжність між розрахунковим і фактичним результатом угоди.
- Регламент експлуатації — порядок запуску й зупинки, дії при розбіжності балансів, обриві потоку даних або серії відхилених заявок, процедура повернення на попередню версію.
- Права доступу до ключів — схема розподілу ролей: торгові ключі без права виведення коштів, окремі облікові записи для тестового й робочого контурів, ротація й порядок відкликання.
- Опис параметрів і журнал рішень — чому вибрано такий горизонт розрахунку й поріг входу, які гіпотези перевіряли й чому відхилили.
Приймання йде за чек-листом: запускаємо контур на вашій інфраструктурі, проганяємо типові збої й переконуємося, що регламент дозволяє вашій команді відновитися без нас.
Кейс: від ручних угод до автономного контуру
Замовник — команда, яка вела трикутний арбітраж вручну: трейдер тримав перед собою стакани трьох бірж, рахував ланцюжок A→B→C→A у таблиці й встигав зібрати зв'язку тільки тоді, коли розбіжність трималася кілька хвилин.
На 40+ парах ручний обхід займав 40–60 секунд, частина маршрутів не перевірялася взагалі, а розбіжність встигала закритися раніше, ніж ішла заявка. Окремий біль — частково виконані зв'язки: одна нога проходила, дві ні, і позиція висіла в неправильній валюті до ручного розбору.
Зібрали автономний контур: потокові стакани з бірж сходяться в граф маршрутів, розрахунок ураховує комісії, ліміти й прослизання за кожним плечем, заявки йдуть пакетом із жорстким обмеженням за часом.
Перед відправленням контур звіряє ліквідність за всіма ногами — якщо хоча б одна не проходить, зв'язка відкидається до угоди, а не після. Для відсіювання битих котирувань підключили CoinGecko як незалежне джерело звірки курсів.
Що змінилося за перший місяць: час від виявлення розбіжності до заявки — 1–2 секунди замість 40–60, частка виконаних зв'язок зросла з 55% до 88% завдяки відсіюванню неліквідних маршрутів, клас відмов «зависла нога» не повторився жодного разу.
Ручні зв'язки залишили тільки як контрольний режим для перевірки нових маршрутів — основний потік іде автономно.
Чим трикутний арбітраж відрізняється від міжбіржового
Трикутний арбітраж замикається всередині одного майданчика: три ноги — A→B, B→C, C→A — виконуються в його ж стакані, розрахунок іде в єдиній обліковій одиниці біржі. Актив не залишає контур майданчика: між ногами немає блокчейн-переказу, тільки ордери.
Міжбіржова зв'язка влаштована принципово інакше. Одну ногу закривають на першій біржі, другу — на другій, а між ними позицію потрібно фізично перенести. Цей перенос і є джерелом усіх відмінностей — за ризиком, швидкістю й вартістю.
Він же породжує ризик переказу коштів: поки актив іде мережею, його немає ні в торговому балансі, ні в управлінні.
Зарахування залежить від завантаження мережі, кількості підтверджень і внутрішніх правил майданчика на приймання, а мережева комісія списується з кожної такої операції.
Швидкість закриття зв'язки відрізняється з тієї ж причини. Усередині майданчика три ноги йдуть майже одночасно, вікно вимірюється секундами, розбіжність курсів закривається на одному балансі.
При переносі вікно задає не трейдер, а мережа: за час очікування спред схлопується, і зв'язка закривається вже за іншими цінами.
Тому міжбіржову схему будують не на переказі під кожну угоду, а на заздалегідь підготовлених балансах на обох майданчиках — тоді перенос іде у фон.
Трикутний такої підготовки не потребує, але жорсткіший до глибини стакана й рівня комісій, а міжбіржовий варіант чутливий саме до вартості й часу переказу.
Технічні сумніви перед початком робіт
Перед стартом обговорюємо не тільки логіку пошуку трикутників, а й поведінку системи в момент збою. Нижче — питання, які ставлять найчастіше: стійкість до навантаження, ліміти майданчиків і захист ключів доступу.
Що відбувається при сплеску волатильності або обриві зв'язку з майданчиком?
Потік котирувань іде через чергу з обмеженням одночасних запитів, ордери відправляються ідемпотентно — повтор не створює дубль.
При розриві з'єднання стратегія переходить у пасивний режим: позиції звіряються з фактичними балансами й історією угод перед відновленням, а розбіжність зупиняє торгівлю замість «наздоганяння» ринку.
Як система реагує на зміну правил майданчика?
Комісії, крок ціни й мінімальний розмір ордера читаються з конфігурації майданчика, а не зашиті в код. Якщо правила змістилися, трикутник перестає бути прибутковим — розрахунок перераховується до постановки ордера, а сигнали з неактуальними параметрами відкидаються.
Як влаштований захист ключів доступу?
Ключі лежать у захищеному сховищі секретів, видаються окремо на кожен майданчик і стратегію та ротуються за розкладом. Право на виведення в торгових ключів вимкнено, доступ обмежений списком дозволених адрес — витік не дає доступу до балансу.
Хто зупиняє торгівлю і як ураховуються ліміти на виведення?
Є ручний стоп і автоматичні тригери: серія відмов майданчика, аномальний спред, просідання понад поріг, втрата зв'язку довше заданого вікна.
Ліміти на виведення враховуються в резерві: система не відправить актив, якщо це порушить добове обмеження майданчика або залишить стратегію без оборотних коштів.
Обговоримо задачу і повернемося з планом робіт
Щоб стартувати за трикутним арбітражем, потрібна узгоджена картина задачі: біржі й пари в периметрі, обмеження за обсягом позиції й хто на стороні замовника приймає результат. Нижче — що потрібно від вас і як виглядає перший крок.
- Постановка задачі: перелік бірж, торгових пар і контурів, допустиме просідання, ліміти на розмір позиції й кількість одночасних угод.
- Доступи й дані: ключі з правами лише на читання й торгівлю, без виведення коштів; доступ до потоків котирувань і історії угод.
- Модель витрат: комісії за рівнями обсягу, спред і глибина стакана за кожною парою — від них залежить поріг входу в угоду.
- Інфраструктура: де розміщується виконавчий контур, які канали зв'язку й вимоги до затримки виконання.
- План робіт: розбір задачі, прототип на історичних даних, тестовий контур, виведення в робочий режим, супровід.
- Оцінка строків: за етапами, з точками звірки після прототипу й після тестового прогону.
- Порядок узгодження: відповідальний за приймання, критерії готовності, правила зупинки й відкату при відхиленні від розрахункової дохідності.
Опишіть задачу й поточну інфраструктуру — повернемося з оцінкою строків і планом робіт за етапами.
