Venue onboarding¶
This page describes the conceptual shape of adding a venue to ONIX. It contains no credentials, no runbook steps, no internal hostnames or deployment topology — those are operational concerns kept outside published documentation.
The intended shape: declarative profile, not bespoke code¶
ONIX's own engineering guidance is explicit that onboarding a venue should normally be declarative profile-and-registry work, followed by conformance testing against the pinned Nautilus wheel — not a venue-specific bypass of the common spine. If a venue needs a change to the gateway, frontend, or shared runtime, the correct response is to find the missing common seam, not to special-case that one venue's path through the system.
Concretely, onboarding a venue that Nautilus already ships an official adapter for means writing
one IntegrationProfile, which declares:
- Adapter binding — which official data/execution factory and config classes the profile
resolves through the reflected adapter registry (see
index.md); a profile never hand-lists factory class names, it resolves them by the venue's own registry entry. - Product families — one
ProductProfileper instrument family the venue serves (e.g. linear perpetuals, spot), each declaring its own subscription and capability behavior. - Native data capabilities per product — which official Nautilus channel kinds the pinned adapter actually delivers for that product, verified against the adapter rather than assumed; an unsupported channel is reported as unsupported, never silently subscribed.
- Subscription policy — message pacing, the subscription ceiling (or an explicit statement that the adapter manages its own connection budget and the spine should not budget for a cap), channel priority order, and which channels are on-demand rather than eagerly subscribed at start.
- External-bar timestamp convention — whether the venue's own candles are stamped at interval
start or close (see
instrument-identity.md). - History pacing — request concurrency, per-request timeout, and drain cadence, tuned against the adapter's own rate limiting.
- Catalog namespace — the subdirectory under the spine root this integration's durable catalog lives in, so two integrations on one host can never interleave data.
A profile is pure policy: constructing one imports no adapter module and touches no live state, so it can be built, tested, and reviewed independently of ever connecting to the venue.
What is deliberately excluded from onboarding¶
Per the backend's own operating rules, no credentials are accessed, no venue connection is made,
and nothing is deployed as part of writing or reviewing a profile — those are separate,
explicitly-authorized steps outside documentation scope. Real venue execution is additionally
structurally unreachable from the public-data path regardless of profile configuration; see
../trading/execution-runtime.md for that boundary.
After the profile: activation is a separate, deliberate step¶
Writing a profile does not deploy a venue. A newly-wired venue normally lands disabled in the
deployment activation roster by default; enabling it is a reviewed, deliberate edit to that
roster, and even an enabled roster entry only controls what a candidate build is composed with —
it is never, by itself, authority to deploy to production. See index.md for the
current activation state of every venue this repository has a profile for, and the sharp
distinction between the development-pin roster and the tracked production record.
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/profile.pybackend@efa38e04:AGENTS.md
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.