Getting started¶
This page is an orientation, not an installation guide. ONIX is a private system; there is no public sign-up, no public package to install, and no public API endpoint. What follows is the map you need to read the rest of this site efficiently.
The five pieces¶
flowchart TB
subgraph Clients
W["Web product<br/>charts · dashboard · screener · strategies"]
M["macOS client<br/>+ local MCP host"]
I["iOS client<br/>private / test stage"]
end
G["Gateway / BFF<br/>schema-pinned transport"]
subgraph Backend["ONIX backend"]
D["Data plane<br/>ingestion · catalog · aggregation"]
T["Trading<br/>strategies · backtests · execution · risk"]
S["Screener engine"]
X["Backend MCP surface"]
end
N["NautilusTrader 2.0.0rc3<br/>upstream runtime"]
W --> G
M --> G
I --> G
G --> D
G --> T
G --> S
G --> X
D --> N
T --> N-
The backend owns everything factual about markets: what data exists, how it is stored, how bars are derived, what a backtest did, and what an execution subsystem is permitted to do. It is built on NautilusTrader at a pinned version. Start at backend overview.
-
The gateway is the schema-pinned boundary between clients and the backend. Clients do not talk to the trading runtime directly. See gateway and schemas for the backend-owned contract and gateway and realtime for how the web client consumes it.
-
The web product is the primary surface: charting and datafeed, a modular dashboard, the screener, and strategy and backtesting workflows. Start at product overview.
-
The native clients are a macOS application, which additionally hosts a local MCP server, and an iOS application. Both are private and test-stage. Start at native clients.
-
The MCP surfaces let an AI agent read from and, in bounded ways, act on ONIX. There are two of them with very different trust characteristics. Start at MCP overview.
How the pieces are pinned to each other¶
ONIX components are not loosely coupled by convention; they are pinned by content. The frontend carries an executable pin file that names the exact backend release it accepts, together with the schema set and its hash. A frontend build that does not match its declared backend contract is a build error, not a runtime surprise.
This matters when reading the documentation: a claim about client behaviour is only meaningful relative to the contract version the client was pinned to. Every page names its pins in the status strip for exactly this reason.
The specific commits, trees and hashes used throughout this site are listed on versions and source pins.
Reading paths¶
Pick the row that matches your question.
| If you want to know… | Read, in order |
|---|---|
| What ONIX is and what it refuses to claim | Home → status model → support and scope |
| Who owns which fact | System boundaries → authority model |
| How market data gets in and is stored | Data plane → ingestion → catalog → aggregation |
| What the chart is actually showing | Charting and datafeed → aggregation |
| What a backtest result means | Backtesting → strategy authoring |
| Where the execution safety boundary is | Execution runtime → portfolio and risk |
| Which venues are actually live | Venue integrations → venue capability matrix → runtime and deployment |
| How the screener works | Screener surface → screener engine |
| What an AI agent can do to ONIX | MCP overview → safety and scope → backend MCP |
| Whether you can rely on a statement | Status model → the badge on the page in question |
Three things to internalise first¶
Backend is authority. If a client and the backend disagree about a market fact, the backend is right and the client has a bug. Documentation follows the same rule: a product page never redefines a backend concept, it links to it.
Upstream is referenced, not copied. NautilusTrader owns a large amount of behaviour that ONIX uses unchanged. This site links to upstream documentation for that behaviour and documents only the boundary and the extensions. See NautilusTrader boundary.
Absence is reported, not padded. Where evidence was not available at the
pinned commits, pages say Unverified and record the open question rather than
inventing a plausible answer. That is a feature of this documentation, and the
capability register collects those gaps in one
place.
Contributing¶
If you have access to the source repositories and want to correct or extend a page, start with how to contribute and documentation standards. Every change must carry evidence; that requirement is enforced by the build, not by review alone.
Evidence and source pins for this page
Verified. Current behaviour, confirmed in source at the pinned commit.
Verified on against the following immutable sources:
frontend@99f49dae:scripts/engine-pin.mjsfrontend@99f49dae:contracts/vendor/onix-engine/contract-manifest.jsonbackend@efa38e04:docs/handoff/contract-manifest.json
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.