hjnormey/siloqy
Public Access
1
0
Fork 0
Code Issues 7 Pull Requests 2 Actions Packages Projects Releases Wiki Activity
Files
f6504ca53b3911f7fcfacdc41e049e377f12dcd0
siloqy/prod/VIOLET_dev/nautilus_spike/FINDINGS.md
Codex 9d40f63c4d 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>
2026-06-13 00:55:39 +02:00

2.9 KiB
Raw Blame History

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.