NAUTILUS / RUST source 3eb18933
Pages

Rust adaptation: the native runtime is LiveNode, assembled by LiveNodeBuilder.

TradingNode Architecture

LiveNode is the owning native process boundary for live data and execution. It embeds a NautilusKernel, registers provider clients through factories, and drives startup, reconciliation, event processing, and shutdown in a single-threaded runtime owner.

Kernel graph

NautilusKernel::new_with_dependencies constructs:

  • Cache and message bus
  • Portfolio
  • Risk engine
  • Execution engine and manager
  • Order emulator
  • Data engine
  • Trader, actors, strategies, and execution algorithms

LiveNodeBuilder supplies configuration, provider factories, strategies, optional event-store construction, and runtime dependencies before the kernel is built.

LiveNodeBuilder composing Databento and Interactive Brokers client factories into NautilusKernel, then starting data, cache, execution and reconciliation in dependency order.

Sources: crates/system/src/kernel.rs, crates/live/src/node/builder.rs, crates/live/src/node/mod.rs.

Provider registration

Data factories create provider clients and wrap them in data-engine adapters. Execution factories create provider execution clients and wrap them in LiveExecutionClient before registration with the execution engine.

For the selected stack:

  • DatabentoDataClientFactory supplies live market data.
  • InteractiveBrokersDataClientFactory supplies IB market data when required.
  • InteractiveBrokersExecutionClientFactory supplies IB order and report handling.

Startup ordering

The node starts in dependency order:

  1. Open optional event-store state and construct the kernel.
  2. Connect data clients.
  3. Receive and flush instruments and pending data into the cache.
  4. Connect execution clients.
  5. Perform startup reconciliation when enabled.
  6. Initialize portfolio state.
  7. Start actors, strategies, and the live runner.

This ordering allows execution and portfolio components to resolve instruments already present in the cache.

Live event loop

The runner multiplexes data events, execution events, trading commands, timers, signals, and shutdown. Engine state is held behind single-threaded ownership patterns; arbitrary cross-thread access is not part of the contract.

Provider networking may run asynchronously, but callbacks into kernel components must remain bounded. A database writer or slow browser must not block this owner.

Execution reconciliation

The execution engine and manager reconcile external venue state with cache and portfolio state. Behaviors include mass-status collection, external-order discovery, missing-order generation, report deduplication, in-flight status checks, and periodic order or position consistency checks.

Interactive Brokers order-command and venue-report paths through the Nautilus risk, execution, cache and portfolio components.

Interactive Brokers implements the provider side of those data and execution contracts. Anthera should not create a second order, fill, position, or account state machine around it.

Shutdown

Graceful shutdown stops strategies and actors, drains residual work, disconnects clients, closes optional event-store state, and waits for configured cancellation bounds. Forced process termination may leave an unsealed event-store run, which recovery logic must inspect on the next boot.

Service boundary

LiveNode is a trading kernel, not a multi-user web gateway. Authentication, entitlements, browser subscriptions, slow-consumer handling, and historical query APIs belong outside the node. The gateway may project canonical Nautilus values, but it must not mutate kernel ownership or expose provider credentials.