VIOLET V2e: Nautilus Binance data-client spike — GO (qualified)

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>
This commit is contained in:
Codex
2026-06-13 00:55:39 +02:00
parent fefb18626e
commit 9d40f63c4d
3 changed files with 244 additions and 0 deletions

View File

@@ -0,0 +1,51 @@
# 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: hostBinance 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.