Bybit добавил полный стакан фьючерсов в API: как правильно синхронизировать данные

Материал

11 августа 2026 года Bybit отметил в официальном журнале изменений поддержку фьючерсов в Full Depth Orderbook — отдельно для REST API и публичного WebSocket. Новый контур охватывает spot, linear и inverse категории, включая USDT- и USDC-контракты и inverse-контракты. Опционы в документации full-depth интерфейса не заявлены.

Главное изменение для аналитических систем — доступ к снимку глубиной до 10 000 ценовых уровней на каждой стороне и к delta-only потоку полного стакана. Это не означает, что можно один раз запросить REST и затем безусловно применять все WebSocket-сообщения. Официальная процедура требует сначала начать буферизацию дельт, затем получить достаточно свежий снимок и сопоставить версии по seq и u.

Что изменилось

Full-depth интерфейс появился для spot 16 июля 2026 года. В записи от 11 августа Bybit добавил формулировку Support Futures к REST-методу Get Full Depth Orderbook и WebSocket-каналу Full Orderbook.

Проверенная конфигурация выглядит так:

Страницы методов не описывают специальный платный план или отдельное разрешение аккаунта для full-depth доступа. Однако это не отменяет общие IP- и WebSocket-лимиты, региональные домены и условия доступа Bybit. В документации общих лимитов указаны, в частности, 600 HTTP-запросов за пять секунд на IP по умолчанию, не более 500 WebSocket-соединений за пять минут и не более 1 000 market-data соединений на IP с раздельным учетом по рынкам. Работать на границе лимитов Bybit не рекомендует.

• REST: GET /v5/market/full_orderbook;
• категории REST: spot, linear, inverse;
• максимальный REST-снимок: до 10 000 уровней заявок на покупку и до 10 000 уровней заявок на продажу;
• WebSocket topic: orderbook.full.{symbol};
• категории потока: spot, USDT contracts, USDC contracts и inverse contracts;
• частота публикации дельт: 200 мс;
• тип WebSocket-сообщений: только delta;
• начального snapshot в этом WebSocket-канале нет;
• RPI-заявки в REST и WebSocket full-depth данных не включаются.

Что такое full-depth order book

Стакан — упорядоченный набор лимитных заявок на покупку и продажу:

Full depth здесь означает более глубокое представление, чем стандартный REST orderbook на 1 000 уровней для контрактов. Но слово full не следует понимать как математически неограниченную полноту. REST возвращает не более 10 000 уровней с каждой стороны. Bybit прямо предупреждает: уровни за пределами начального snapshot неизвестны, пока они не появятся в дельтах; даже после этого их состояние может быть неполным.

Поэтому метрики ликвидности должны содержать границу наблюдения. Нельзя считать отсутствие уровня за пределами снимка доказательством отсутствия заявки на бирже.

• bids — заявки покупателей, обычно от более высокой цены к более низкой;
• asks — заявки продавцов, от более низкой цены к более высокой;
• price level — цена и совокупный доступный объем на ней;
• snapshot — полное состояние известной части стакана на конкретной версии;
• delta — изменения отдельных уровней после этой версии.

REST + WebSocket: правильная модель синхронизации

Упрощенная схема «сначала REST, потом подключить WebSocket» оставляет окно гонки: между формированием снимка и подпиской можно пропустить изменения. Официальная процедура Bybit строится иначе:

Открыть WebSocket и подписаться

↓

Буферизовать delta-сообщения

↓

Запросить REST full-depth snapshot

↓

Сопоставить snapshot и буфер по seq + u

↓

Инициализировать локальный стакан

↓

Применить оставшиеся дельты

↓

Проверять непрерывность u

В snapshot и delta присутствуют два разных идентификатора:

После подписки клиент записывает seq и u первой буферизованной дельты. Если u в буфере разрывается, буфер очищается и сбор начинается заново. Если seq уменьшился, такое сообщение отбрасывается.

Затем клиент получает REST-снимок. Если seq снимка меньше seq первой дельты, REST-запрос повторяется, пока снимок не станет достаточно свежим. Дельты с seq меньше snapshot отбрасываются. Если seq равны, а u расходятся, нужно снова запросить снимок. Инициализация завершается только после совпадения подходящих seq и u.

• seq — версия matching engine. Она монотонно растет, но соседние сообщения одного символа не обязаны иметь последовательные значения;
• u — update ID. В рамках сессии он должен увеличиваться на единицу и используется для обнаружения пропуска событий.

Какие данные нужно хранить

Минимальная событийная модель может включать:

Поля received_at, source, connection_id и snapshot_hash — внутренние поля потребителя, а не поля Bybit. Их нужно маркировать отдельно, чтобы не выдавать собственную телеметрию за данные биржи.

Для хранения цен и объемов нельзя использовать обычный binary float без контроля точности. API передает их строками; безопаснее преобразовывать в decimal или целые значения в минимальном шаге цены/количества.

• symbol — символ инструмента;
• category — spot, linear или inverse;
• side — bid или ask;
• price — цена как точное десятичное значение;
• size — объем как точное десятичное значение;
• seq — версия matching engine;
• u — последовательный update ID;
• cts — время matching engine в миллисекундах;
• ts — время генерации сообщения системой Bybit;
• received_at — собственное монотонное/UTC-время получения;
• source — REST snapshot или WebSocket delta;
• connection_id — идентификатор соединения;
• snapshot_hash — хеш нормализованного снимка при необходимости аудита;
• parser_version — версия декодера и логики обновления.

Как применять дельты

Для каждой записи [price, size] действует три базовых правила:

Порядок bids и asks после обновления должен оставаться детерминированным. Для быстрых расчетов можно использовать сбалансированное дерево или другую отсортированную структуру, но исходную строковую точность цены и размера желательно сохранять отдельно от вычислительного представления.

Каждая вычисленная метрика должна быть привязана к версии локального стакана. Иначе spread, imbalance и оценка проскальзывания могут оказаться рассчитанными из уровней разных моментов времени.

• уровня еще нет, а size > 0 — вставить;
• уровень существует, а size > 0 — заменить объем;
• size = 0 — удалить уровень.

Что делать при разрыве последовательности

Если новый u больше локального u + 1, одно или несколько сообщений пропущены. Официальная инструкция требует:

Если входящий u меньше текущего локального u, сообщение игнорируется как устаревшее. Если u = 1, это сигнал переинициализации, а не обычная следующая дельта.

Bybit перечисляет несколько сценариев u = 1: перезапуск сервиса, делистинг символа, состояние перед pre-market auction, переход к непрерывным торгам, изменение lot/tick configuration. Реакция зависит от REST-снимка: стакан может быть очищен, помечен NO_BOOK или заново инициализирован.

Важно: искать пропуск по seq + 1 неправильно. Документация прямо говорит, что seq не обязан быть последовательным. Непрерывность событий проверяется по u.

• отбросить локальный стакан;
• очистить или заново сформировать буфер;
• повторить полную процедуру синхронизации;
• не публиковать метрики до восстановления согласованного состояния.

Какие метрики можно построить

После надежной синхронизации full-depth поток позволяет рассчитывать:

Эти результаты требуют дополнительных оговорок. RPI-заявки отсутствуют в API, snapshot ограничен 10 000 уровнями на сторону, а локальный стакан временно недостоверен при разрыве последовательности. Метрика должна не только иметь числовое значение, но и статус качества: SYNCED, RESYNCING, NO_BOOK, STALE или DEGRADED.

• bid/ask spread и mid-price;
• совокупную глубину в пределах ±0,1% и ±0,5% от mid-price;
• дисбаланс объемов покупателей и продавцов;
• оценку проскальзывания для заданного размера заявки;
• профиль накопленной глубины;
• тепловую карту ликвидности по времени и расстоянию от mid-price;
• скорость добавления, изменения и удаления уровней;
• расхождение spot и соответствующего perpetual/futures стакана;
• задержку received_at - cts как операционную метрику канала.

Как это подходит RURChain

Bybit full-depth — источник вторичной рыночной аналитики. Он может поддерживать исследования ликвидности, сравнительные панели, тестовые коннекторы и developer-примеры RURChain. Он не является официальным российским регуляторным или налоговым источником.

Это особенно важно рядом с материалом о котировках ФНС. Биржевой стакан отвечает на вопрос о доступной ликвидности и заявках сейчас. Набор ФНС связан с установленным налоговым определением и опубликованными историческими строками. Один источник нельзя незаметно подменять другим.

До подключения в production RURChain потребуются проверка условий использования и региональной доступности, нагрузочные тесты, фикстуры snapshot/delta, сценарии всех u = 1, хранение состояния качества, лимиты ретенции и четкое отделение market analytics от официальной доказательной базы.

Материал предназначен для информационных и технических целей и не является инвестиционной рекомендацией.

Первичные источники

• Bybit — V5 API changelog (https://bybit-exchange.github.io/docs/changelog/v5)
• Bybit — Get Full Depth Orderbook (https://bybit-exchange.github.io/docs/v5/market/full-ob)
• Bybit — WebSocket Full Orderbook (https://bybit-exchange.github.io/docs/v5/websocket/public/full-ob)
• Bybit — Rate Limit Rules (https://bybit-exchange.github.io/docs/v5/rate-limit)

Связанные материалы

• Как DigitalRUR отслеживает изменения законодательства (https://digitalrur.ru/ru/updates/kak-rurchain-otslezhivaet-izmeneniya-zakonodatelstva/)
• Источники и методология DigitalRUR (https://digitalrur.ru/ru/legal/sources-and-methodology/)