Home >> Support Board

Support Board

Date/Time: Sat, 18 Jul 2026 23:21:05 +0000

How to Post a Message for Support

[Programming Help] - Binance - Market Depth Data (Level 2)

View Count: 476

[2026-05-31 12:19:08] #1 [Go To First Post]
User537545 - Posts: 4
Hi there, I have read Cryptocurrency / Bitcoin Data and Trading Services and am aware that market depth is "Not provided for Binance symbols". Currently I can only see the Level 1 on the bid side and ask side for any Binance symbol. I just watched a YouTube Video of VerilloTrading though (https://www.youtube.com/watch?v=Gldk81rWZ5U) and there it seemed as if he had DOM data for DOGEUSDT_PERP_BINANCE (image attached). Is it somehow possible to unlock DOM (Level 2) data for Binance symbols? I saw that you provide this kind of data for Bitfinex symbols and wondered why since the volume on the exchange is much lower than on Binance. It would make much more sense to support market depth data on Binance symbols. If it is not possible to unlock the data, would it be possible for me to get the market depth data through the Binance API and integrate it myself into Sierra Chart? Do you have any customers who did that already?


Verillo Trading; Binance Market Depth.png / V - Attached On 2026-05-31 12:10:13 UTC - Size: 4.19 MB - 48 views Attachment Deleted.

[2026-05-31 21:01:13] #2 [Go To First Post]
Sierra_Chart Engineering - Posts: 24268
No, we removed market depth data for Binance because it is too much data to process and support: Is it somehow possible to unlock DOM (Level 2) data for Binance symbols? would it be possible for me to get the market depth data through the Binance API and integrate it myself into Sierra Chart? Yes this is possible but you have to develop a DTC Protocol compatible server and provide Sierra Chart, the bid and ask, Trade and market depth data completely. Not just market depth data. And then you can use the DTC client in Sierra Chart to connect to your server: Data and Trading Communications (DTC) Protocol Test Client Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2026-05-31 21:01:38

[2026-06-04 19:32:55] #3 [Go To First Post]
User537545 - Posts: 4
Thank you for the clarification, that makes complete sense. Since I am not a programmer I have built a DTC Bridge to the Binance API using Claude Opus 4.7. I have used your entire DTC documentation as well as the Binance API documentation. Live data and historical data is now streaming to a separate Sierra Chart installation, but I have some open questions: 1. Historical tick data download takes ~5-15 minutes for 24 hours of high-volume futures data (e.g. BTCUSDT-PERP, ~2-3M trades/day). The pipeline is: Binance public archive (.zip) → in-process decompression → JSON DTC messages via TCP loopback → SC client. I use uvloop and orjson on the bridge side; observed throughput is roughly 3000-5000 records/sec sustained. Is there a recommended page size, message batching strategy, or server-side pacing pattern that maximises SC's ingest rate? Is the bottleneck typically the JSON parsing in SC, the .scid disk write (flushed every 5s by default), or socket throughput? 2. How much "HISTORICAL_PRICE_DATA_RECORD_RESPONSE" messages can the SC-client reliably process per second using JSON-encoding? Is there a recommended page size or server-side pacing strategy to prevent SC from being overwhelmed? 3. During long-running historical data streams (e.g. several minutes of streaming HISTORICAL_PRICE_DATA_RECORD_RESPONSE messages for millions of tick records), does the SC client still enforce the heartbeat timeout (typically 2.5× HeartbeatIntervalInSeconds)? Should the server interleave HEARTBEAT messages between historical records, or is the steady flow of records sufficient to be treated as a "keep-alive"? If interleaved heartbeats are recommended, what's the optimal frequency that won't cause re-ordering issues with the historical stream?" 4. When the server streams HISTORICAL_PRICE_DATA_RECORD_RESPONSE messages, does SC perform any validation before writing to .scid? Specifically: (a) are records with StartDateTime strictly less than the last written record's timestamp silently dropped, kept, or do they overwrite? (b) Are duplicate timestamps (e.g. two records with identical StartDateTime) merged, kept side-by-side, or rejected? 5. Sierra Chart is using NTFS compression but since I am running the application on an iMac with M3 chip using CrossOver is there an alternative compression method that I can use to compress the .scid files? Currently I am receiving the errors '...Windows error code 50: request not supported'. Is this expected because CrossOver/Wine's NTFS layer on top of APFS does not support FSCTL_SET_COMPRESSION? Is there a built-in alternative within SC itself (e.g. zlib/zstd compression of records inside the .scid file, independent of the host filesystem)? 6. Is it supported by the Sierra Chart DTC client to set HISTORICAL_PRICE_DATA_REQUEST.UseZLibCompression=1 with JSON encoding instead of Binary encoding and can a measurable throughput gain be expected on a loopback connection (127.0.0.1), or does the additional CPU overhead for Deflate/Inflate tend to slow down the overall throughput? Are there any official benchmarks or recommendations regarding the data distance or bandwidth at which compression becomes worthwhile? If JSON+zlib is not officially supported, is there a tracking issue or planned improvement? We chose JSON encoding for the bridge to keep the implementation portable and debuggable; switching to Binary encoding would add significant complexity. Knowing whether compression is a viable optimisation path with JSON or not would help me prioritise." 7. If the DTC bridge crashes in the middle of a historical data stream, what happens during reconnection? Does SC resend requests starting from the last written .scid record (with StartDateTime = last_time + 1 µs), or is the entire range requested again? How many incomplete or duplicated records can the server deliver without corrupting the .scid file? 8. Sierra Chart sometimes sends Symbol="BTCUSD_PERP"+Exchange=“BINANCE” in the DTC-MARKET_DATA_REQUEST, and sometimes Symbol=""+Exchange=“BTCUSD-BINANCE”, and sometimes a combination of the two. Are there official documents describing SC's canonical symbol naming for crypto perpetuals (USD-M vs COIN-M), so that DTC server implementers can match SC's expectation deterministically? Or is the server expected to accept any naming variant the user types in their chart definitions, and resolve to the correct underlying instrument via exchangeInfo / symbol metadata? 9. If the "Intraday Data Storage Time Unit" is set to 1 tick and the user opens a daily chart for the same symbol, does SC aggregate the data on the fly from the .scid file, or does it retrieve the daily bars separately? If it retrieves them separately, does it then read both files (.scid for updates, .dly for daily data), or is one given priority over the other? 10. HISTORICAL_PRICE_DATA_TICK_RECORD_RESPONSE (804) does not contain fields for the bid price and ask price at the time of the trade — only AtBidOrAsk (direction), Price, and Volume. To allow server implementers to obtain bid/ask data per trade in the .scid format (for studies that use s_IntradayRecord.High as Ask and s_IntradayRecord.Low as Bid), the only option is the workaround described in the section “Providing Bid Volume and Ask Volume” using HISTORICAL_PRICE_DATA_RECORD_RESPONSE (803) with NumTrades=1. Is the limitation of TICK_RECORD_RESPONSE intentional? What exactly does SC write to s_IntradayRecord.High and s_IntradayRecord.Low when the server uses TICK_RECORD_RESPONSE (which does not provide these values)? My observation was that the fields are apparently populated with the live BBO current at the time of processing, which leads to records with Close < Low or Close > High in historical downloads. I have now switched to RECORD_RESPONSE with NumTrades=1 as the workaround, and the .scid records are clean (Close always within [Low, High], 0% bad records over 30 days). For confirmation: is this RECORD_RESPONSE-with-NumTrades=1 approach the long-term-supported convention for per-trade tick data with bid/ask context, or is it considered a transitional pattern until TICK_RECORD_RESPONSE gets BidPrice/AskPrice fields? Your documentation regarding the DTC protocol message structures is excellent. However, for server implementers there's no end-to-end reference: the 'DTC Protocol Test Client' is available for verifying messages, but no reference SERVER implementation exists that demonstrates best practices end-to-end (logon handshake → encoding negotiation → market data subscription lifecycle → historical streaming with backpressure → graceful shutdown). Do you have a reference DTC server implementation (in any language) I could study? Or could you point to an existing 3rd-party server known to implement the protocol correctly that I could use as a reference? I really appreciate your support. Date Time Of Last Edit: 2026-06-04 19:39:45

[2026-06-17 15:08:49] #4 [Go To First Post]
Sierra_Chart Engineering - Posts: 24268
We do not see how this would even reliably create code: Binance API using Claude Opus 4.7. Using JSON encoding is a mistake for historical data or any market data. We do not recommend that. It is inefficient. 1, 2. These have no relevancy at all. Just send data as fast as possible. 3. Should the server interleave HEARTBEAT messages between historical records, or is the steady flow of records sufficient to be treated as a "keep-alive"? You do not need to send heartbeats, if historical records are being transmitted. 4. The records are written as they are received. 5. We are working on a new file format that has its own compression. 6. Yes it should be supported: Is it supported by the Sierra Chart DTC client to set HISTORICAL_PRICE_DATA_REQUEST.UseZLibCompression=1 with JSON encoding instead of Binary encoding and can a measurable throughput gain be expected on a loopback connection (127.0.0.1), or does the additional CPU overhead for Deflate/Inflate tend to slow down the overall throughput? 7. Does SC resend requests starting from the last written .scid record (with StartDateTime = last_time Yes this is correct. 8. Sierra Chart should only ever be setting the Symbol field. Not the Exchange. Although this may depend if you have set this: DTC.s_LogonResponse.SymbolExchangeDelimiter Which we would not recommend doing. 9. Daily chart data bars are always completely separate and do not involve Intraday data files. For confirmation: is this RECORD_RESPONSE-with-NumTrades=1 approach the long-term-supported convention for per-trade tick data with bid/ask context, Yes. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing

[2026-06-18 07:48:49] #5 [Go To First Post]
Sierra_Chart Engineering - Posts: 24268
Also here is the information for the DTC Protocol Server in Sierra Chart which you can use for testing: Data and Trading Communications (DTC) Protocol Server Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing

[2026-06-25 20:04:54] #6 [Go To First Post]
User537545 - Posts: 4
Yeah it has been a lot of trial and error with Claude but it seems to work. Surely not perfect but what choice do I have when SC does not provide market depth data beyond level 1? (: In a perfect world SC would at least provide the first 10 DOM levels in the live data path (historical DOM not required). Big thank you for your insightful reply. I had already switched to binary encoding for the historical data download what solved the performance issue. After what you said regarding JSON I also switched to the binary encoding for the live data. That all seems to work. I also switched to only setting the Symbol, not the Exchange and that also works well, thank you. Will this new file format with its own compression be available anytime soon? A few new questions emerged while building the DTC server: 1. When the DTC feed sends individual trades (Type 146, one per exchange fill), SC appears to merge consecutive same-price/same-side fills into a single T&S record with summed volume. Is there a setting that controls this (store every individual trade vs. merged), e.g. for studies that rely on per-fill trade counts? 2. On the dedicated historical connection (port 11098 model), the first backfill of a high-volume symbol (~600k tick records) sometimes hits an SC-side "download timed out", after which SC retries and resumes from the last written record. Is there a configurable timeout for an Intraday historical data request, and/or a recommended server-side pattern to avoid the timeout on very large first requests? 3. Does SC store Intraday/T&S trade prices as 32-bit float, or is higher precision available (e.g. scaled-integer storage via a price/tick multiplier)? I send trade prices via MARKET_DATA_UPDATE_TRADE_WITH_UNBUNDLED_INDICATOR_2 (Type 146, which carries Price as float32). For high-priced instruments (e.g. BTC ~60–100k) float32 rounds sub-tick — is that the storage limit on SC's side too, or is there a way to preserve full precision?

To post a message in this thread, you need to log in with your Sierra Chart account: