Rust adaptation: the native BacktestNode in crates/backtest/src/node.rs is the orchestration surface documented here.

BacktestNode and High-Level API

BacktestNode coordinates configured backtest runs over the Rust engine, model, data, portfolio, risk, execution, and trading crates. It provides a higher-level lifecycle around BacktestEngine while preserving deterministic event-time processing.

Configuration model

crates/backtest/src/config.rs contains the native run configuration:

• BacktestEngineConfig controls kernel and engine behavior.
• BacktestDataConfig identifies catalog-backed data, type, instrument, time range, filtering, and optional streaming settings.
• Venue configurations define account type, OMS behavior, starting balances, routing, latency, fees, and matching behavior.
• Strategy and execution-algorithm configurations identify the components loaded into a run.

Every run should pin its input configuration and source-data identity so that results can be reproduced.

Build and run lifecycle

A node performs these broad phases:

1. Validate run and data configuration.
2. Construct the backtest engine and kernel components.
3. Register venues, instruments, strategies, and execution algorithms.
4. Load or stream data into deterministic time order.
5. Run the engine until exhaustion or the requested boundary.
6. Collect portfolio, execution, and analyzer results.
7. Dispose per-run state before the next run.

Sources: crates/backtest/src/node.rs, crates/backtest/src/engine.rs, crates/backtest/src/config.rs.

Data loading

Backtests accept canonical Nautilus data such as QuoteTick, TradeTick, Bar, order-book updates, and custom data. BacktestDataConfig can describe catalog slices. When the streaming feature is enabled, persistence-backed iteration avoids materializing the complete dataset at once.

Data must be ordered by initialization timestamp according to the engine’s deterministic contract. Provider data should be decoded into nautilus-model values before it enters the simulation.

Venue simulation

Each simulated venue owns matching, latency, fee, account, and OMS behavior. SimulatedExchange and its matching engines process orders against the configured market-data stream. The same strategy-facing order and event types used by live trading are retained, but exchange behavior is simulated rather than sent to an external client.

Strategies and results

Rust strategies implement the lifecycle and callbacks documented in Strategy Implementation. The node registers them before execution. Portfolio state and analyzers are read after the run to obtain balances, positions, PnL, fills, and performance statistics.

Determinism boundary

A repeatable backtest requires more than the same strategy code:

• Pin crate revision and feature set.
• Pin data files or catalog object versions.
• Record configuration, seed, precision mode, and instrument definitions.
• Avoid wall-clock or uncontrolled external I/O in strategy logic.
• Compare ordered events and resulting state, not only the final PnL.

Live parity

The native backtest and live nodes share model, strategy, portfolio, risk, and execution concepts. They do not share every operational behavior: live clients reconnect and reconcile external state, while the backtest engine owns simulated venue state. Parity should be proven with common fixtures and strategy assertions rather than assumed from type names.