Я протестировал 40 криптобирж алгоритмами. Вот о чём обычно не говорят
Как выбрать биржу для алгоритмической торговли: latency, matching engine и реальная ликвидность
Вступление
Я несколько лет занимаюсь алгоритмической торговлей и за это время прогнал через свои алгоритмы десятки криптобирж.
Я подключал биржи к своим ботам, торговал через API и проверял то, что действительно важно алгоритмическому трейдеру: стаканы, latency, WebSocket, исполнение ордеров, ликвидность, ошибки и поведение рынка в момент реальной сделки.
В результате я протестировал около 40 бирж.
И оказалось, что биржа, которая выглядит отлично на CoinMarketCap, в рекламе обещает миллиарды объема и показывает красивый глубокий стакан, совсем не обязательно является хорошей биржей для алгоритмической торговли.
Иногда всё наоборот.
О чем здесь не будет
Я не хочу делать очередной криптоканал, где автор показывает красивый PnL, рассказывает про «секретный сигнал» и продает курс о том, как заработать миллион.
И я не собираюсь раскрывать собственный торговый edge, хочу поделиться с комьюнити наблюдениями которые кому-то сэкономят время, а кому-то деньги
Чтобы было дальше понятно, немного о инфраструктуре и терминах как работают биржи и торговые боты
Как устроена моя инфраструктура

Real-time market data (Rust) → Redis → стратегии → транзакционный слой / историческое хранилище
Это позволяет отделить быстрый контур принятия решений от аналитики и долгосрочного хранения данных.
Как работает биржа: от стакана до исполнения
Чтобы понимать алгоритмическую торговлю, недостаточно знать API биржи. Нужно понимать, что происходит между вашим кодом и реальным исполнением заявки.
Упрощенно вся система выглядит так:
Биржа → публикация рыночных данных → ваш сборщик данных → аналитика и принятие решения → отправка заявки → matching engine биржи → подтверждение исполнения.
А теперь о самом интересном, дерево метрик системы, для наглядности опишу все что есть, но далее сфокусируемся на том, что важно в плане выбора биржи, т.к. остальное в целом решаемо
Группа | Метрика | Что измеряет | Где измеряется | Кто отвечает | Для чего важна |
|---|---|---|---|---|---|
0. E2E — главный контур | Market Event → Order in Book | От момента формирования рыночного события до попадания твоей заявки в книгу | Вся цепочка | Вся система | Главная метрика скорости |
Market Event → Fill | От события рынка до фактического исполнения | Вся цепочка | Вся система + рынок | Реальная скорость реакции | |
Market Event → Ack | От события до подтверждения заявки | Вся цепочка | Вся система + биржа | Контроль задержки | |
E2E p50 / p95 / p99 | Распределение полного времени | Вся цепочка | Вся система | Хвосты часто важнее медианы | |
E2E jitter | Разброс полного времени | Вся цепочка | Вся система | Стабильность | |
1. Market Data — биржа | Book generation latency | Изменение рынка → сформированный book state | Market Data Engine | Биржа | Скорость формирования данных |
Snapshot generation | Время формирования snapshot | Market Data Engine | Биржа | Качество первичного состояния | |
Delta generation | Время формирования delta update | Market Data Engine | Биржа | Скорость обновлений | |
Book publish latency | Book state → публикация WS | Market Data Engine | Биржа | Свежесть данных | |
Update frequency | Количество обновлений/sec | WS | Биржа | Частота «дыхания» рынка | |
Sequence continuity | Пропущенные sequence | WS | Биржа + collector | Целостность книги | |
Data timestamp accuracy | Насколько timestamp соответствует реальному событию | WS | Биржа | Расчет реального age | |
Quote persistence | Время жизни уровня | Order book | Биржа / MM | Качество ликвидности | |
Order book age | Возраст книги при получении | WS → твой collector | Твоя система + биржа | Понимание stale data | |
2. Network — биржа ↔ сервер | Endpoint latency | Сервер → endpoint биржи | Network | Infra | Базовая задержка |
Application latency | Реальное сообщение WS/API → получение | App layer | Infra + биржа | Важнее ping | |
Jitter | Разброс network latency | Network | Infra | Предсказуемость | |
Packet loss | Потеря пакетов | Network | Infra / провайдер | Потери данных | |
Packet reorder | Переупорядочивание | Network | Network | Целостность потока | |
Retransmission | Повторная передача | Network | Network | Причина хвостов | |
Connection stability | Разрывы WS/TCP | Network | Infra + биржа | Надежность | |
Reconnect time | Время восстановления | Client | Твоя система + биржа | Recovery | |
3. Rust WS / Data Ingest | Socket → process | NIC → приложение | WS worker | Твой Rust | Накладные расходы |
Parse latency | Message → internal struct | WS worker | Rust | Эффективность parser | |
Normalize latency | Raw → unified format | WS worker | Rust | Скорость нормализации | |
Book update latency | Receive → готовый L2 book | WS worker | Rust | Критично для сигнала | |
Queueing delay | Ожидание обработки сообщения | WS worker | Rust / OS | Понимание bottleneck | |
CPU scheduling delay | Ожидание CPU | OS | Infra | Tail latency | |
Drop rate | Потерянные сообщения внутри collector | WS worker | Rust | Качество данных | |
Redis write latency | Collector → Redis | Rust/Redis | Infra | Скорость доставки стратегии | |
WS → Redis ready | Сообщение биржи → готовая книга | Collector | Твой Rust | Ключевая внутренняя метрика | |
4. Redis / Real-time layer | Read latency | Redis → strategy | Redis | Infra | Скорость чтения |
Write latency | Collector → Redis | Redis | Infra | Скорость записи | |
Pub/Sub latency | Event → subscriber | Redis | Infra | Передача события | |
Queue depth | Размер очереди | Redis | Infra | Нагрузка | |
Key freshness | Возраст данных в Redis | Redis | Infra | Актуальность | |
Memory usage | Использование RAM | Redis | Infra | Ресурсный контроль | |
Evictions | Вытеснение ключей | Redis | Infra | Риск потери данных | |
Contention | Конкуренция за ресурсы | Redis | Infra | Tail latency | |
5. Analytics / Feature Engine | Redis → processing | Получение данных → начало обработки | Python | Твой код | Внутренняя latency |
Feature calculation | Расчет признаков | Strategy | Python | Стоимость аналитики | |
Spread calculation | Расчет арбитражной разницы | Strategy | Python | Скорость сигнала | |
Liquidity calculation | Расчет доступного объема | Strategy | Python | Качество входа | |
Funding calculation | Расчет funding edge | Strategy | Python | Funding strategies | |
Market freshness | Возраст книги при обработке | Strategy | Твой код | Защита от stale signal | |
Decision Age | Возраст данных в момент решения | Strategy | Твой код | Очень важная KPI | |
6. Strategy / Decision | Signal generation latency | Features → signal | Strategy | Твой код | Скорость алгоритма |
Decision latency | Получение данных → решение | Strategy | Твой код | Основной CPU budget | |
Risk-check latency | Signal → risk decision | Risk | Твой код | Безопасность | |
Position check latency | Проверка текущих позиций | Risk/DB | Твой код | Защита стратегии | |
Opportunity lifetime | Сколько живет edge | Market | Рынок | Сопоставление с E2E | |
Signal decay | Как быстро исчезает edge | Strategy | Research | Качество стратегии | |
7. Order Construction / Execution | Order construction | Signal → объект заявки | Execution | Твой код | Внутренняя скорость |
Serialization | Object → payload | Execution | Твой код | CPU overhead | |
Signing latency | Формирование подписи | Execution | Твой код | CPU overhead | |
Queueing delay | Decision → отправка | Execution | Твой код | Скрытая latency | |
Decision → Wire | Решение → пакет ушел в сеть | Execution | Твой код | Очень важная KPI | |
Cancel latency | Решение → cancel отправлен | Execution | Твой код | Управление ордером | |
Retry latency | Ошибка → повтор | Execution | Твой код | Recovery | |
8. Outbound Network | Client → endpoint | Сервер → API gateway | Network | Infra | Скорость отправки |
TLS overhead | Установление/переиспользование TLS | Network | Infra + client | Важно для новых соединений | |
TCP connect latency | Создание соединения | Network | Infra | Не должно быть в hot path | |
Connection reuse | Persistent connection | Client | Execution | Снижение latency | |
Retransmission | Повтор отправки | Network | Infra | Tail latency | |
9. Exchange Gateway | Gateway → Matching Engine | API gateway → matching | Биржа | Биржа | Внутренний bottleneck |
Order validation latency | Проверка параметров | Биржа | Биржа | Скорость принятия | |
Exchange risk-check latency | Margin/risk | Биржа | Биржа | Скорость исполнения | |
Matching latency | Order → matching decision | Биржа | Matching Engine | Ключевой показатель | |
Queue-entry latency | Matching → очередь книги | Биржа | Matching Engine | Особенно важен для limit | |
Ack latency | Request → acknowledgment | Биржа | Биржа + network | Мониторинг | |
Reject latency | Request → reject | Биржа | Биржа | Диагностика | |
10. Order Book / Limit Execution | Time-to-Book | Send → заявка реально появилась в книге | Биржа | Биржа | Ключевая лимитная KPI |
Queue position | Позиция заявки | Matching Engine | Биржа / косвенно | Вероятность fill | |
Time-to-first-fill | Order → первый fill | Execution | Рынок | Скорость исполнения | |
Time-to-full-fill | Order → полный fill | Execution | Рынок | Реальная исполнимость | |
Fill probability | Вероятность исполнения | Execution | Рынок | Ключевая KPI | |
Partial fill ratio | Доля частичных исполнений | Execution | Рынок | Качество | |
Cancel-to-fill ratio | Отмены / fills | Execution | Стратегия | Эффективность | |
Displayed / Executable Liquidity | Видимый объем vs реально исполнимый | Book + fills | Биржа + твои данные | Твоя ключевая метрика | |
Fill Ratio | Исполненный объем / заявленный объем | Fills | Твоя аналитика | Качество книги | |
Slippage | Ожидаемая → реальная цена | Execution | Рынок | Стоимость исполнения | |
Adverse selection | Цена после fill | Market data | Strategy / research | Качество maker fill | |
Queue decay | Исчезновение очереди перед тобой | Order book | Рынок | Модель fill | |
11. Data Quality | Message loss | Потеря market-data сообщений | WS | Биржа + collector | Корректность данных |
Duplicate rate | Дубликаты сообщений | WS | Collector | Качество feed | |
Out-of-order rate | Сообщения не по порядку | WS | Collector | Корректность книги | |
Stale rate | Доля устаревших сообщений | WS | Collector | Сигналы | |
Book reconstruction errors | Ошибки восстановления L2 | Collector | Rust | Корректность | |
Snapshot/delta mismatch | Несогласованность snapshot и delta | Collector | Rust + exchange | Критичная ошибка | |
12. Infrastructure | CPU utilization | Загрузка CPU | Server | Infra | Capacity |
Memory utilization | RAM | Server | Infra | Capacity | |
Disk I/O | Нагрузка диска | Server | Infra | PostgreSQL | |
Network utilization | Нагрузка интерфейса | Server | Infra | Capacity | |
Process restart rate | Перезапуски | OS | Infra | Надежность | |
Uptime | Доступность компонентов | Infra | Infra | SLA | |
p99 resource latency | Хвосты ресурсов | Infra | Infra | HFT | |
13. Database / History | Insert latency | Write → PostgreSQL | DB | Infra | Историческое хранение |
Query latency | SQL query | PostgreSQL | Infra | Research | |
Commit latency | Transaction commit | DB | Infra | Transactional layer | |
WAL latency | Write-ahead log | PostgreSQL | DB | Надежность | |
Replication lag | Primary → replica | DB | Infra | Аналитика | |
Storage growth | Рост данных | DB | Infra | Capacity | |
14. Reliability / Operations | Error rate | Ошибки API/WS/execution | Все компоненты | Все | Надежность |
Timeout rate | Таймауты | API/WS | Infra + exchange | Потеря возможностей | |
Reject rate | Доля rejected orders | Execution | Биржа | Торговая доступность | |
Rate-limit hit rate | Доля упора в лимиты | API | Биржа + client | Capacity | |
Disconnect rate | Разрывы | WS | Infra + exchange | Market data | |
Recovery time | Сбой → нормальная работа | Infra | Infra | Resilience | |
15. Market / Trading Quality | Spread | Bid/ask spread | Book | Рынок | Возможность арбитража |
Depth | Объем на уровнях | L2 | Рынок | Capacity | |
Real liquidity | Исполнимый объем | Fills + L2 | Рынок | Самая важная практическая метрика | |
Volatility | Изменчивость | Market | Рынок | Risk | |
Funding | Funding rate | Exchange | Рынок | Funding arb | |
Price divergence | Расхождение бирж | Market | Strategy | Arb signal | |
Opportunity frequency | Возможности / sec | Market | Strategy | Capacity | |
Opportunity lifetime | Время жизни возможности | Market | Strategy | Сопоставление с E2E | |
Edge decay | Потеря edge за время | Market | Strategy | HFT/arb | |
16. Итоговые KPI платформы | Book Age at Decision | Возраст книги при принятии решения | E2E | Твоя команда | Один из главных KPI |
Decision → Wire | Решение → отправка заявки | E2E | Твоя команда | Hot path | |
Exchange Ack | Отправка → подтверждение | E2E | Биржа + сеть | Execution | |
Time-to-Book | Отправка → заявка в книге | E2E | Биржа | Limit execution | |
Fill Ratio | Исполнено / доступно | E2E | Твоя аналитика | Реальная ликвидность | |
E2E p99 | 99-й перцентиль полного пути | E2E | Вся система | HFT readiness | |
Opportunity-to-Fill | Найден edge → реальный fill | E2E | Вся система | Самая практичная KPI | |
Missed Opportunity Rate | Возможность была, но не исполнились | E2E | Вся система | Потерянный edge | |
Execution Quality | Ожидаемое исполнение → реальное | E2E | Вся система | Реальный PnL | |
Data Reliability Score | Качество данных источника | Data layer | Твоя команда | Выбор биржи | |
Exchange Reliability Score | Сводная оценка биржи | Все слои | Твоя команда | Рейтинг площадок |
За несколько лет у меня накопилась довольно большая система метрик - от latency и качества WebSocket до обработки данных, исполнения ордеров, стабильности API и поведения стакана. Каждая из них важна: когда что-то ломается, именно они позволяют быстро найти, на каком участке возникла проблема.
Но если отбросить всё второстепенное и говорить именно о выборе биржи, я бы выделил два фактора, которые определяют практически всё остальное:
1. Как работает matching engine.
Насколько быстро биржа принимает, проверяет и сопоставляет заявку с книгой, насколько стабильно работает очередь и насколько предсказуемо происходит исполнение.
2. Насколько реальна ликвидность, которую показывает биржа.
Если в стакане отображается $10 000, для алгоритма важно не то, что эти $10 000 видны на экране, а сколько из них действительно можно исполнить.
Всё остальное - latency до endpoint, скорость обработки данных, Redis, Python, оптимизация стратегии, тюнинг параметров — можно итерационно улучшать. Но если у биржи плохой matching engine или нереальная ликвидность, никакой тюнинг на твоей стороне это не исправит.
Поэтому мой первый вопрос при подключении новой биржи сегодня звучит не «какой у неё объем?», а всего два: как она исполняет заявки и можно ли доверять её стакану.
Тест новой биржи
Я проверяю биржу в два этапа.
1. Скорость исполнения.
Ставлю лимитную заявку в глубину стакана и измеряю время от отправки заявки до её появления в книге:
Order → Book Latency
Если p95 ≤ 50 мс, можно переходить дальше. Если задержка уже здесь высокая или нестабильная - биржу обычно можно сразу отбраковать.
2. Реальная ликвидность.
Дальше ставлю небольшие реальные заявки и сравниваю объём, который биржа показывает в стакане, с объёмом, который действительно исполняется:
Fill Ratio = Executed Volume / Displayed Volume
Прогоняю 50+ заявок на разных монетах и уровнях. Это стоит копейки относительно времени, которое можно потратить на интеграцию неподходящей биржи.
И отдельно обязательно проверяю возраст стакана в момент принятия решения. Даже идеальные 20 мс до биржи бесполезны, если алгоритм работает с книгой, которой уже 300 мс.
Выводы
Много написано, но к сути и ценности статьи, вот список бирж которые на 31.07 доступны в РФ и их ряд ключевых метрики (сервер у меня в Сингапуре, можно понять почему где-то latency больше)
Я специально оставил только несколько показателей, которые, на мой взгляд, лучше всего описывают практическую пригодность биржи для алгоритмической торговли:
RTT p50 / p95 — сетевой round-trip до endpoint;
Delta p50 / p95 — задержка обновления данных стакана;
Fill Ratio — доля фактически исполненного объёма от общего объёма отправленных заявок на тестируемый уровень;
Биржа | RTT p50 | RTT p95 | Delta p50 | Delta p95 | Fill Ratio |
|---|---|---|---|---|---|
Bybit | 9 ms | 16 ms | 9 ms | 61 ms | 92.8% |
HTX | 149 ms | 371 ms | 42 ms | 84 ms | 82.5% |
Bitget | 78 ms | 190 ms | 38 ms | 78 ms | 78.0% |
GateIO | 164 ms | 745 ms | 36 ms | 78 ms | 78.0% |
Binance | 77 ms | 81 ms | 42 ms | 127 ms | 92.3% |
OKX | 160 ms | 380 ms | 32 ms | 86 ms | 71.1% |
KuCoin | 156 ms | 191 ms | 42 ms | 87 ms | 64.0% |
BloFin | 25 ms | 147 ms | 69 ms | 132 ms | 53.0% |
MEXC | 235 ms | 341 ms | 38 ms | 62 ms | 55.9% |
Phemex* | 12 ms | 16 ms | 0 ms | 7 ms | 54.7% |
На самом деле говорить о том, что если низкий RTT и будет высокий fill нельзя, как и обратное
Работать можно с каждой из этих бирж, но со своими особенностями, расскажу постепенно
Результаты относятся к моей инфраструктуре, выбранной выборке и периоду тестирования; это не универсальная оценка работы биржи во всех условиях
И небольшой disclaimer от автора: это мой первый выход в публичное поле, поэтому буду рад конструктивной критике 🙂
Ничего продавать не собираюсь — хочу просто делиться тем, что сам исследую и строю. Если тема интересна, буду рад собрать небольшое сообщество людей, с которыми можно обсуждать идеи, данные и эксперименты.
ByLab: https://t.me/bylabdata