This is a question about server-side behaviour of the USDⓈ-M Futures WebSocket endpoints, not a bug in this SDK. I am filing it here because there is no issue tracker for the USDⓈ-M Futures API itself (binance-spot-api-docs has issues disabled and is spot-only), and because a comparable server-side report was answered in this org before — binance/binance-public-data#472. Happy to move it if there is a better place.
Cross-posted from the developer forum, where it has had no staff reply so far:
https://dev.binance.vision/t/usd-m-inter-endpoint-skew-between-public-and-market-under-load-after-the-base-url-split/38008
Context
After the base URL split (Important WebSocket Change Notice, legacy endpoints decommissioned 2026-04-23), order book streams and trade/price streams are served from different endpoints:
| endpoint |
streams |
/public |
<symbol>@bookTicker, !bookTicker, <symbol>@depth, <symbol>@depth<levels> |
/market |
<symbol>@aggTrade, <symbol>@markPrice, <symbol>@kline_<interval>, ticker / miniTicker, @forceOrder |
Consumers that need the book and the tape to correspond must therefore hold two connections, with independent network paths, buffering and reconnect cycles. This is not a request to revert the split — we understand it was introduced for stability and traffic isolation under sustained load.
What we observe
During periods of high volatility the two endpoints drift apart: the book state and the trade tape stop corresponding to each other. Reported skew during these episodes is roughly 500 ms to 2000 ms, compared to single-digit milliseconds under normal conditions. The drift recovers on its own once activity normalises, though recovery has occasionally taken noticeably longer than usual.
For reference, a previously reported inter-stream skew measurement (pre-split, combined connection) showed a median around 1 ms with p99 around 70 ms. What we see now is one to two orders of magnitude beyond that, and it correlates with load rather than being a constant offset.
To be upfront about the evidence level: the figures above are operator observations across independent setups, not a controlled measurement — raw logs were not retained. Structured measurements are being collected and will be posted in the forum thread as they arrive. We are raising it now because the pattern is consistent across separate deployments and appeared after the split.
Why reordering by T does not resolve this
Buffering events and reordering them by the exchange-side T field is the correct approach for small inter-stream skew, and it works well at the single-digit millisecond scale. At skew in the hundreds of milliseconds to seconds, the required buffer window exceeds the decision horizon for latency-sensitive strategies, which makes the correct method unusable in practice. This is a magnitude problem, not a methodology problem.
Questions
- After the split, is there an expected or intended bound on skew between
/public and /market for the same symbol, particularly under load? The change notice states no such bound and is marked "Excerpt" — is one documented anywhere else?
- Does Binance monitor publication skew between the two endpoints internally? If so, do internal figures show widening during volatility spikes?
- The split notice states the change improves stability and operational isolation. Does isolation here mean the two endpoints may be throttled or queued independently under load, so that one can lag the other by a large margin?
- Is there a recommended client-side approach for consumers that need book and trade data to correspond, beyond buffering and sorting by
T?
Note for anyone reproducing this
If you measure skew through an SDK rather than a raw socket, rule out the client first: binance/binance-connector-rust#92 was a client-side unordered-message bug, fixed in v48.0.1. Where possible, measure local receive time minus T on a raw connection, and report market/symbol, the region you connect from, whether the connection is direct or proxied, the UTC time of the episode, and whether it recovered on its own.
This is a question about server-side behaviour of the USDⓈ-M Futures WebSocket endpoints, not a bug in this SDK. I am filing it here because there is no issue tracker for the USDⓈ-M Futures API itself (
binance-spot-api-docshas issues disabled and is spot-only), and because a comparable server-side report was answered in this org before — binance/binance-public-data#472. Happy to move it if there is a better place.Cross-posted from the developer forum, where it has had no staff reply so far:
https://dev.binance.vision/t/usd-m-inter-endpoint-skew-between-public-and-market-under-load-after-the-base-url-split/38008
Context
After the base URL split (Important WebSocket Change Notice, legacy endpoints decommissioned 2026-04-23), order book streams and trade/price streams are served from different endpoints:
/public<symbol>@bookTicker,!bookTicker,<symbol>@depth,<symbol>@depth<levels>/market<symbol>@aggTrade,<symbol>@markPrice,<symbol>@kline_<interval>, ticker / miniTicker,@forceOrderConsumers that need the book and the tape to correspond must therefore hold two connections, with independent network paths, buffering and reconnect cycles. This is not a request to revert the split — we understand it was introduced for stability and traffic isolation under sustained load.
What we observe
During periods of high volatility the two endpoints drift apart: the book state and the trade tape stop corresponding to each other. Reported skew during these episodes is roughly 500 ms to 2000 ms, compared to single-digit milliseconds under normal conditions. The drift recovers on its own once activity normalises, though recovery has occasionally taken noticeably longer than usual.
For reference, a previously reported inter-stream skew measurement (pre-split, combined connection) showed a median around 1 ms with p99 around 70 ms. What we see now is one to two orders of magnitude beyond that, and it correlates with load rather than being a constant offset.
To be upfront about the evidence level: the figures above are operator observations across independent setups, not a controlled measurement — raw logs were not retained. Structured measurements are being collected and will be posted in the forum thread as they arrive. We are raising it now because the pattern is consistent across separate deployments and appeared after the split.
Why reordering by
Tdoes not resolve thisBuffering events and reordering them by the exchange-side
Tfield is the correct approach for small inter-stream skew, and it works well at the single-digit millisecond scale. At skew in the hundreds of milliseconds to seconds, the required buffer window exceeds the decision horizon for latency-sensitive strategies, which makes the correct method unusable in practice. This is a magnitude problem, not a methodology problem.Questions
/publicand/marketfor the same symbol, particularly under load? The change notice states no such bound and is marked "Excerpt" — is one documented anywhere else?T?Note for anyone reproducing this
If you measure skew through an SDK rather than a raw socket, rule out the client first: binance/binance-connector-rust#92 was a client-side unordered-message bug, fixed in v48.0.1. Where possible, measure local receive time minus
Ton a raw connection, and report market/symbol, the region you connect from, whether the connection is direct or proxied, the UTC time of the episode, and whether it recovered on its own.