Как работает арбитражный бот: принципы и архитектура

Откуда берётся арбитражная возможность

Криптовалютный рынок фрагментирован. BTC торгуется одновременно на Binance, Bybit, OKX, Kraken и десятках других площадок. Каждая формирует цену независимо — через свой ордербук. Когда цена на одной бирже хотя бы на 0,1–0,3% отличается от другой, возникает арбитражное окно.

Проблема: такие окна живут секунды или миллисекунды. Их моментально закрывают маркетмейкеры и другие арбитражники. Чтобы успеть раньше — нужна скорость на всех уровнях: от получения данных до исполнения ордеров.

Из чего состоит арбитражный бот

1. Модуль сбора данных (Market Data Feed)

Здесь самое первое узкое место. Данные о ценах нужно получать в реальном времени — REST не подходит категорически. Каждый REST-запрос — минимум 50–200 мс. За это время окно закроется.

Правильное решение — WebSocket-соединения к каждой бирже. Биржа сама «пушит» обновления ордербука немедленно. Для топовых пар обновления приходят несколько раз в секунду.

Что важно учитывать:

• Разные биржи дают разный формат данных: full snapshot + incremental updates или только полный ордербук каждый раз. Синхронизация ордербука — отдельная задача.
• При разрыве соединения нужно переподключаться и запрашивать snapshot заново, иначе данные устареют незаметно.
• Для мониторинга 10–15 пар на 5–6 биржах бот держит 50–90 одновременных WebSocket-соединений.

2. Арбитражный движок (Spread Calculator)

Это ядро бота. Он непрерывно сравнивает цены и ищет ситуации, где разница (спред) превышает порог прибыльности с учётом комиссий.

Прибыль = Цена_продажи × (1 - комиссия_B) - Цена_покупки × (1 + комиссия_A) - проскальзывание

На практике нужно учитывать:

• Глубину ордербука: хватит ли ликвидности для вашего объёма?
• Время исполнения: пока ордер летит к бирже, цена уже может измениться (latency risk).
• Позиционный риск: между покупкой и продажей рынок может сдвинуться.

3. Модуль исполнения ордеров (Order Execution)

Когда движок нашёл возможность, нужно одновременно выставить ордер на покупку и продажу. «Одновременно» — ключевое слово. Задержка между ними — позиционный риск.

Решение: отправлять оба ордера параллельно через asyncio (Python) или goroutines (Go). Последовательное исполнение недопустимо.

Также нужна логика обработки частичного исполнения: что делать, если один ордер исполнился, а второй — нет? Бот должен либо отменить первый, либо хеджировать открытую позицию.

4. Риск-менеджмент и мониторинг

Самый недооценённый модуль. Боты без нормального риск-менеджмента теряют деньги не из-за плохой стратегии, а из-за технических сбоев.

• Лимиты на позицию: максимальный объём одной сделки.
• Дневной лимит потерь: если бот потерял X USDT за день — остановился.
• Проверка баланса перед ордером: убедиться, что средства действительно есть.
• Мониторинг пинга: если latency к бирже резко выросла — не торговать.
• Алерты в Telegram: немедленное уведомление о любых аномалиях.

Почему большинство арбитражных ботов не работают

Главная причина — игнорирование косвенных издержек. Начинающие считают только биржевые комиссии (0,1%). Но к ним добавляются:

• Проскальзывание: на неликвидных парах может съедать половину прибыли.
• Время перевода средств: эффективный арбитраж строится на балансах, предварительно размещённых на обеих биржах.
• Rate limits: превысите — получите бан, пропустите возможность.
• Конкуренция: в ликвидных парах маржа 0,05–0,15%. Вы соревнуетесь с командами с co-location серверами.

Стек на практике

Для арбитражных ботов мы используем Python (asyncio, aiohttp, ccxt) для прототипирования и Go или Rust для production-систем. Разница в latency между Python и Go на одинаковой задаче — 3–5 раз в пользу Go.

Базы данных: TimescaleDB или ClickHouse для ордербуков и истории сделок, Redis для быстрого обмена состоянием между компонентами.

Where arbitrage opportunities come from

The crypto market is fragmented. BTC trades simultaneously on Binance, Bybit, OKX, Kraken and dozens of other venues. Each forms prices independently through its own order book. When a price discrepancy of even 0.1–0.3% appears between exchanges, an arbitrage window opens.

The problem: these windows last seconds or milliseconds. Market makers and other arbitrageurs close them instantly. To act first — you need speed at every level: from data reception to order execution.

4 components of an arbitrage bot

1. Market Data Feed: WebSocket connections to every exchange — REST is too slow (50–200ms per request). The exchange pushes order book updates immediately. For 10–15 pairs on 5–6 exchanges, the bot maintains 50–90 simultaneous WebSocket connections.

2. Spread Calculator: continuously compares prices and finds situations where the spread exceeds the profitability threshold after commissions. Must account for order book depth, execution latency and positional risk.

3. Order Execution: both orders (buy and sell) must be sent in parallel — any sequential delay creates positional risk. Must handle partial fills.

4. Risk Management: daily loss limits, per-position size limits, balance checks before orders, latency monitoring and Telegram alerts.

Why most arbitrage bots fail

• Slippage — can eat half the profit on illiquid pairs.
• Transfer time — effective arbitrage requires pre-placed balances on both exchanges.
• Rate limits — exceed them and get banned, missing the opportunity.
• Competition — liquid pair margins are 0.05–0.15%, competing against teams with co-location servers.

Stack in practice

Python (asyncio, ccxt) for prototyping; Go or Rust for production. Go is 3–5x faster than Python on the same task. TimescaleDB/ClickHouse for order book history, Redis for state sharing between components.