Skip to content

Backend and platform overview

VerifiedOwner Backend / platformLast verified backend@efa38e04e2db37a444e9f17100323c2ad4b83647 nautilus@2.0.0rc3

ONIX's backend (repository onix-backend, Python distribution onix-engine) is a thin application and contract layer built around a pinned, unmodified NautilusTrader v2 distribution. It does not re-implement a trading engine. The authority model is deliberate and stated in the repository's own instructions: NautilusTrader owns instruments, market data, aggregation, catalog primitives, the clock, cache, portfolio, accounting, risk, orders, fills, positions, execution and runtime lifecycle. ONIX Python owns product composition (DataActors, runtime hosting, projections), catalog workflows, strategy authoring, screening, optimization, the governed gateway API, and the MCP surface. ONIX Rust crates own performance-sensitive ONIX-specific computation and contract/schema generation — they never link, fork, or reproduce Nautilus's own trading-engine crates.

This section documents that composition as it exists at the pinned commits below, distinguishing throughout between what is verified in code, what is only attested by a tracked production record (and never independently observed live), what is declared intent in the development tree that has not been promoted to production, and what is genuinely unverified at these pins.

The two pins that matter

  • Backend handoff pin: efa38e04e2db37a444e9f17100323c2ad4b83647 (tree 0e7275ae5f0e66a9e6acd04e81837ff1a0565820), the reference used throughout this section unless otherwise noted.
  • Nautilus pin: nautilus-trader 2.0.0rc3, source commit 648970ce64a304d93da0a29320cb6e19b905fa39. See nautilus-boundary.md for the full upstream/extension split.

A second backend commit, f80bc316ca01e9ea68a77ad6fd2ca0efe89ee7ba, is used where the handoff pin lacks a particular source file; both are recorded on every page's front matter.

What "the backend" actually is

At the pinned commit, onix-backend is organized around a small number of cooperating responsibilities, each documented in its own subsection here:

  • Data plane (data/) — the durable Parquet catalog (a thin façade over Nautilus's own ParquetDataCatalog), bar aggregation and derived resolutions, and the ingestion/hydration/coverage machinery that tracks what has actually been subscribed and written.
  • Runtime (runtime/) — how a Nautilus LiveNode is hosted and terminated, engine-status and readiness/liveness surfaces, and the cache/message-bus behavior actually available at this pin.
  • Venues (venues/) — the adapter registry Nautilus ships, the ONIX "profile" seam that wraps a subset of it, instrument identity, and per-venue activation status.
  • Trading (trading/) — strategy authoring (immutable, content-addressed revisions validated in a child process), backtesting through the official BacktestNode, the execution/sandbox boundary, and portfolio/risk surfaces.
  • Screener (screener.md) — the Rust feature-registry screener and its honesty rules for values that cannot currently be trusted.
  • Gateway and schemas (gateway-schemas.md) — the versioned /v2 HTTP/SSE contract and the 58-schema contract set a client vendors.
  • MCP (mcp.md) — the backend's own Model Context Protocol tool surface (a different thing from the native/local MCP host documented under ../native/index.md).

How to read status on these pages

Every page and every material claim below is tagged with one of a fixed set of tokens: verified (present in code at the pin), production-record (attested only by a tracked deployment record, never independently observed live), private-test-stage, target-contract (a declared contract not yet current behavior), upstream (Nautilus's own behavior), extension (an intentional ONIX addition over upstream), retired, quarantined, or unverified. Where a capability is only partially supported, that is called out inline rather than left to be inferred from the page's overall status. The single most load-bearing distinction in this section is between the tracked production record — which currently claims a Bybit-only deployment on a frozen data-plane manifest — and the development tree, whose deploy/activation.json declares a broader, not-yet-promoted composition (Bybit, Hyperliquid ingest-only, Binance ingest-only). See runtime/index.md and venues/index.md for the full distinction, and capability-status.md for the consolidated register.

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:AGENTS.md
  • backend@efa38e04:docs/architecture.md

Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.