9d40f63c4d
90s BTCUSDT-PERP capture on the prod host, public data, dummy creds (factory demands key env vars even for the data client; public endpoints ignore the header). NT internal dispatch p50 0.23ms / p99 3.3ms — inside VIOLET reactor budgets; 77 ticks/s sustained, zero drops. Qualifications: NT owns its (uvloop) event loop -> recommended separate feed process bridging via Zinc/HZ; exchange->cb p50 135ms is network+NTP+throttle, a relative baseline only; PRODGREEN-era launcher API calls no longer exist in 1.219 (FUTURES->USDT_FUTURE) — pin version + API smoke on adoption. Exec-client spike remains keys-blocked; executor decision at the V4 gate. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
# V2e spike findings — NautilusTrader Binance DATA client as VIOLET feed
|
|
|
|
Date: 2026-06-12 · NT 1.219.0 · prod host · public mainnet market data,
|
|
no real credentials · 90 s BTCUSDT-PERP trade+quote capture
|
|
(`spike_report.json`, raw numbers; script `spike_nt_binance_feed.py`).
|
|
|
|
## Verdict: **GO (qualified)** for NT as the alpha-side Binance feed
|
|
|
|
NT's internal dispatch (WS frame → tick object → message bus → strategy
|
|
callback) costs **p50 0.23 ms / p99 3.3 ms** — comfortably inside the
|
|
VIOLET reactor budgets (V0 gate: reaction p99 < 10 ms). Throughput at one
|
|
instrument was 77 ticks/s sustained (847 trades + 6,885 quotes / 90 s)
|
|
with zero drops; build 0.03 s; first tick 1.1 s after start. The Rust WS
|
|
stack is healthy on this host.
|
|
|
|
Qualifications that shape the integration:
|
|
|
|
1. **Loop ownership.** NT installs uvloop and requires a current event
|
|
loop at node construction (py3.12 raises otherwise). The node owns its
|
|
loop. In-process coexistence with the VIOLET reactor means running the
|
|
reactor ON NT's loop — or (recommended) running NT as a separate feed
|
|
process bridging ticks via Zinc/HZ, which preserves VIOLET's loop
|
|
discipline and isolates NT lifecycle issues. Decision belongs at the
|
|
V4 gate per the charter.
|
|
2. **Keys demanded even for data.** The Binance factory builds an HTTP
|
|
client (instrument definitions) with MANDATORY `BINANCE_FUTURES_API_KEY/
|
|
SECRET` env vars. Public endpoints ignore the header, so **dummy values
|
|
work** — but this is undocumented behavior to pin a test on; a real
|
|
read-only key is the clean path if adopted.
|
|
3. **exchange→callback p50 135 ms / p90 827 ms** is dominated by factors
|
|
outside NT: host→Binance network distance, host NTP skew, and Binance's
|
|
own stream throttling on the quote side (the bimodal 135 ms vs 827 ms
|
|
split tracks trades-vs-quotes). Read it as a relative baseline for the
|
|
lead/lag study, not as NT overhead. For exit-pricing purposes the venue
|
|
(BingX) feed remains authoritative — this feed is the ALPHA side.
|
|
4. **API drift is real**: the PRODGREEN-era launcher in-tree uses
|
|
`BinanceAccountType.FUTURES` and config fields that no longer exist in
|
|
1.219 (`USDT_FUTURE` now, no `paper_trading` on data config). Any
|
|
adoption must pin the NT version and carry an API-surface smoke test.
|
|
|
|
## What was NOT tested (out of spike scope)
|
|
Multi-instrument fan-out (the scan universe is ~50 symbols), reconnect
|
|
behavior under network failure, memory growth over hours, NT exec clients
|
|
(the BingX ExecutionClient skeleton remains the V2-deferred,
|
|
keys-blocked item; executor decision at the V4 gate).
|
|
|
|
## Next concrete step if adopted
|
|
Separate `violet_feed_nt` process: NT node + probe-style strategy
|
|
publishing normalized ticks (asset, bid, ask, last, ts_event, mono_ns) to
|
|
a Zinc region / HZ map; VIOLET's VenuePriceFeedPort consumes it like any
|
|
other plane with its own staleness budget.
|