Venue integrations¶
ONIX distinguishes three separate, easily-conflated facts about a venue: whether Nautilus ships an official adapter for it, whether ONIX has written a profile wrapping that adapter, and whether a given deployment has actually activated it. All three are verified independently below.
What Nautilus ships (upstream)¶
venues.registry derives the integration list by reflection over the pinned wheel's
nautilus_trader.adapters package — it never hand-lists factory names — and asserts the derived
set equals an explicitly maintained expectation, so an upstream addition or removal is visible
rather than silently absorbed. At this pin, the pinned wheel ships 19 official integrations,
each classified VENUE (has both a data and an execution factory), DATA_PROVIDER (data only), or
SIMULATED_EXECUTION (execution only — matched by exactly one integration, sandbox, Nautilus's
own simulated-execution adapter):
architect_ax, betfair, binance, bitmex, blockchain, bybit, coinbase, databento,
deribit, derive, dydx, hyperliquid, interactive_brokers, kraken, lighter, okx,
polymarket, sandbox, tardis. This list is upstream — it says only what Nautilus ships, not
what ONIX runs.
sandbox is not a venue. It is the one integration this reflection classifies
SIMULATED_EXECUTION (an execution factory only, no data factory) — Nautilus's own
simulated-execution adapter, not a real venue profile. Counting it in "19 upstream venue
integrations" without this distinction overstates real-venue breadth by one; ONIX's own registry
already separates it by kind rather than by a hand-maintained exclusion list, and this page does
too. Eighteen of the nineteen are VENUE or DATA_PROVIDER integrations against a real exchange
or data source.
Tested versus merely present: a fourth dimension¶
Having a profile (below) proves policy exists; it does not prove the profile has ever been exercised against the adapter it wraps. This documentation adds one more column for exactly the four venues this repository activates in any roster — configured/tested/deployed/observed are different claims, and only the first two are things a documentation pass over source can verify at all:
| Venue | Dedicated conformance/integration tests at this pin (non-exhaustive, by filename) |
|---|---|
| Bybit | test_bybit_adapter_authority.py, test_bybit_authority_repair_gateway.py, test_stage1_bybit_channel_suppression.py |
| Binance | test_binance_discovery_preflight.py, test_binance_history_deep.py, test_binance_history_floor.py, test_binance_profiles_wire.py, test_binance_stream_capacity.py, test_venues_profile_binance.py, test_spine_binance_deep_continuation.py, test_spine_binance_paged_floor.py, test_internal_1m_binance_routing.py |
| Hyperliquid | test_hyperliquid_backtest_boundary.py, test_hyperliquid_confirmation.py, test_hyperliquid_one_ip_live_gate.py, test_hyperliquid_patched_runtime.py, test_internal_1m_hyperliquid_ack.py |
| Interactive Brokers | test_ibkr_config.py, test_ibkr_contract.py, test_ibkr_execution.py, test_ibkr_execution_admission.py, test_ibkr_execution_gate.py, test_ibkr_execution_readiness.py, test_ibkr_operator_strategy.py, test_ibkr_preview.py, test_ibkr_roster.py, test_ibkr_search.py, test_ibkr_session.py, test_gateway_v2_ibkr.py |
Every other upstream integration in the list above (Betfair, Bitmex, Blockchain, Coinbase,
Databento, Deribit, Derive, dYdX, Kraken, Lighter, OKX, Polymarket, Tardis, Architect AX) has an
ONIX profile source file (see below) but no dedicated conformance test suite found in this
repository at the pin — configured (a profile exists), not tested. This documentation does not
claim a passing test file proves live venue conformance either: a test run against a real venue
connection is a separate, explicit operational action outside documentation scope (see
onboarding.md); these are unit/integration tests against the pinned adapter and
recorded fixtures, not live-venue conformance receipts.
The ONIX profile seam¶
An IntegrationProfile is the one typed seam between ONIX's venue-agnostic market-spine runtime
and one pinned Nautilus adapter integration: it declares which adapter factory/config the profile
resolves through the registry above, subscription policy and priority, native data capabilities
per product (honestly False when the pinned adapter cannot deliver a channel — never
subscribed-and-silent), external-bar timestamp convention, history pagination policy, and a
deterministic instrument-to-shard assignment for splitting a large universe across processes.
Constructing a profile imports no adapter module and owns no runtime state — it is pure policy,
safe to construct from any thread. Profile source files exist for the majority of the upstream
adapter list above; see instrument-identity.md for the identity fields
every profile shares and onboarding.md for what writing one involves.
Having a profile is necessary but not sufficient for a venue to run: a profile is policy, not activation.
Activation status: production record versus development intent¶
This is the most important distinction on this page. A venue can be present in Nautilus, have an ONIX profile, be listed in the development deployment roster, and still not be part of the tracked production deployment — all four are different claims.
| Venue | Upstream adapter | ONIX profile | Development-pin roster (deploy/activation.json) |
Tracked production record |
|---|---|---|---|---|
| Bybit | yes | yes | enabled, gateway core | yes — the only venue in the tracked CURRENT_PRODUCTION record |
| Hyperliquid | yes | yes | enabled — ingest-only market data; execution explicitly disabled | not present in the tracked production record |
| Binance | yes | yes | enabled — ingest-only, gated on operator-supplied history-boundary parameters before the unit will start | not present in the tracked production record |
| Interactive Brokers | yes | yes | disabled (enabled: false); a preview-only unit is bundled but not part of the active roster |
not present in the tracked production record |
| All other upstream adapters (Betfair, Bitmex, Blockchain, Coinbase, Databento, Deribit, Derive, dYdX, Kraken, Lighter, OKX, Polymarket, Tardis, Architect AX) | yes | source exists for each | not declared in the activation roster | not present |
Read carefully: the development-pin deploy/activation.json is not a production manifest. It
declares which integrations a candidate build is composed with — the file's own comment states
explicitly that an enabled entry there "controls artifact composition only and is never authority
to deploy production." The tracked CURRENT_PRODUCTION feature-state record
(feature-state/rc3-data-plane-frozen-current-production.yaml) is the only source this
documentation treats as describing what is actually deployed, and it names five production units,
all serving Bybit, with no Hyperliquid or Binance unit among them. (production-record only; the
live host was never independently observed while writing this documentation.)
Even within the development roster, Hyperliquid and Binance are activated for market data
ingestion only — Hyperliquid's entry states execution is explicitly disabled, and Binance's unit
refuses to start until an operator supplies specific candidate-sealed boundary parameters. Neither
represents a claim of live trading capability on either venue. See
../trading/execution-runtime.md for the separate, structural
reason no venue process in this fleet can register a real execution client at all, regardless of
activation status.
Related pages¶
instrument-identity.md— how an instrument is identified across venues, and the identity-in-transition caveats that follow from the manifest versioning above.onboarding.md— what bringing a new venue online involves conceptually.
Evidence and source pins for this page
Verified. Current behaviour, confirmed in source at the pinned commit.
Verified on against the following immutable sources:
backend@efa38e04:python/src/onix_engine/venues/registry.pybackend@efa38e04:deploy/activation.jsonbackend@efa38e04:feature-state/rc3-data-plane-frozen-current-production.yamlbackend@efa38e04:python/tests/test_bybit_adapter_authority.py
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.