NAUTILUS / RUST source 3eb18933
Pages
9.8 native-rust DeepWiki source ↗

Contributing and Extending Rust Crates

Relevant Rust source files

  • CONTRIBUTING.md
  • ADAPTERS.md
  • ROADMAP.md
  • docs/developer_guide/rust.md
  • docs/developer_guide/adapters.md
  • crates/common/src/factories/client.rs
  • crates/live/src/node/builder.rs

Discuss material changes before implementation, work from develop, keep the change focused, include tests, and follow the contributor agreement and review process described in CONTRIBUTING.md. New integrations require prior approval because an adapter creates an ongoing protocol, operations, and support commitment.

Extension seams

Nautilus exposes explicit Rust seams for actors, strategies, indicators, data clients, execution clients, cache databases, message-bus backings, event stores, codecs, and plugins. Use the narrowest existing seam. Do not fork model semantics or engine lifecycle to add a provider.

For a data adapter:

  1. map provider symbology into InstrumentId and InstrumentAny;
  2. decode provider payloads into canonical market-data values;
  3. implement the Nautilus data-client contract;
  4. provide a DataClientFactory for live-node composition;
  5. test fixtures, reconnect/resume, subscriptions, and error mapping.

For an execution adapter, additionally map order commands, acknowledgements, fills, rejects, cancels, account state, and reconciliation reports through the execution-client contract. Client and venue identifiers must remain stable across reconnect and recovery.

The Databento and Interactive Brokers crates are the selected examples in this edition. Their source shows provider-specific translation and native LiveNode composition without introducing a second domain model.

Evidence for a contribution

Include focused unit tests, an integration test for every crossed boundary, failure-path coverage, and benchmarks for performance claims. Live tests should use documented sandbox/paper environments and isolated credentials. Documentation must name feature flags, platform constraints, and unsupported behavior.

Run repository formatting, Clippy, test, security, and generated-artifact checks before opening a pull request. Keep unrelated cleanup out of the same change so reviewers can evaluate the behavioral contract.