NAUTILUS / RUST source 3eb18933
Pages

Adapter scope: this page covers only the native nautilus-interactive-brokers crate.

Interactive Brokers Adapter

nautilus-interactive-brokers integrates IB Gateway or Trader Workstation with Nautilus market-data and execution contracts. The crate is native Rust and contains data and execution clients, factories, configuration, instrument resolution, protocol mapping, and runnable LiveNode examples.

Interactive Brokers execution path showing outbound commands and inbound venue reports across the Nautilus risk, execution, cache and portfolio boundaries.

The frozen crate is intentionally publish = false. Consume it from the same pinned Nautilus repository revision as the other runtime crates.

Feature surface

Feature Effect
execution Enables nautilus-execution and nautilus-network; enabled by default
examples Enables nautilus-live/node and strategy example support
gateway Enables Docker-based IB Gateway support through Bollard

Source: crates/adapters/interactive_brokers/Cargo.toml.

Factory composition

The adapter exposes:

  • InteractiveBrokersDataClientFactory
  • InteractiveBrokersExecutionClientFactory
  • Data and execution configuration types
  • Instrument-provider and symbology logic
  • Live market-data and execution clients

LiveNodeBuilder invokes the factories during build. The data client is registered with DataEngine. The execution client is wrapped as LiveExecutionClient and registered with ExecutionEngine.

Source: crates/adapters/interactive_brokers/src/factories.rs.

Instrument resolution

IB uses contracts, conids, exchanges, currencies, security types, and provider-specific metadata to identify instruments. The adapter’s instrument provider resolves those definitions into Nautilus InstrumentAny values and canonical InstrumentId identifiers before market data or execution state is processed.

Instrument resolution must complete before execution reconciliation depends on those identifiers. The live-node startup sequence therefore connects and flushes data/instrument state before execution clients.

Market data

The data client manages IB subscriptions and converts provider events into Nautilus model types. Provider request identifiers and subscription state remain inside the adapter. Downstream strategies and services consume canonical quotes, trades, bars, and instruments rather than ibapi response types.

The native data example is:

cargo run --example ib-data-tester --package nautilus-interactive-brokers --features examples

Source: crates/adapters/interactive_brokers/examples/node_data_tester.rs.

Execution

The execution client handles submission, modification, cancellation, reports, and provider connectivity. Nautilus ExecutionEngine owns command routing and state transitions; the adapter translates between IB protocol messages and Nautilus reports.

Startup reconciliation, external-order discovery, in-flight checks, missing-order handling, and portfolio convergence are coordinated by the live execution engine. Do not create a second IB-specific order state machine outside this path.

The native execution example is:

cargo run --example ib-exec-tester --package nautilus-interactive-brokers --features examples

Source: crates/adapters/interactive_brokers/examples/node_exec_tester.rs.

Gateway and connection identity

IB permits multiple client connections distinguished by client ID. Account, host, port, and client identity must be configured deliberately, especially when TWS, Gateway, and other tools share a session. Live tests should use a paper account and a unique client ID.

The optional gateway feature can manage a containerized IB Gateway, but process supervision and authentication state remain deployment concerns. A running container is not proof that the brokerage session is authenticated or reconciled.

Operational evidence

Before enabling orders, prove:

  1. Gateway/TWS authentication survives the intended restart policy.
  2. Instrument lookup and market-data subscriptions succeed.
  3. Execution reconciliation matches the paper account.
  4. An order can be submitted, observed, and canceled through ExecutionEngine.
  5. Restart with an existing open order does not duplicate or lose state.
  6. Disconnect and reconnect produce bounded, observable behavior.