Rust edition: this page follows the live DeepWiki structure but treats the current Rust crates as implementation authority. Non-Rust surfaces are identified at their boundary and are not presented as Rust APIs.

Glossary

Relevant Rust source files

• crates/risk/src/lib.rs
• crates/persistence/src/lib.rs

This glossary defines codebase-specific terms, jargon, and domain concepts used throughout NautilusTrader. It serves as a technical reference for onboarding engineers to understand the mapping between high-level trading concepts and their specific implementations in the Rust hybrid architecture.

System Architecture Terms

NautilusKernel

The central dependency injection container and orchestration object. It is responsible for initializing and holding references to core engines (Data, Execution, Risk) and infrastructure components (MessageBus, Cache, Clock).

• Implementation: NautilusKernel in
• Role: Acts as the "glue" that allows components to discover each other during the build phase of a TradingNode or BacktestNode.

MessageBus

The event-driven communication backbone of the platform. It supports a pub/sub pattern for distributing market data, order events, and system commands across components.

• Implementation: MessageBus defined in
• Data Flow: Uses topic-based routing to ensure that components like the ExecutionEngine only receive relevant TradingCommand messages. Recent improvements include correlation_id propagation for request tracing
• Serialization: Supports SBE and Cap'n Proto encodings for Rust-native publishers

Actor

A specialized component capable of publishing and subscribing to the MessageBus. Most user-defined logic, including strategies and data processors, inherits from this class.

• Implementation: Actor base class logic and DataActorCore in
• Lifecycle: Follows the standard component state machine (PRE_INITIALIZED → READY → RUNNING → STOPPED → DISPOSED).
• Rust Plugins: Actors can now be loaded as separately compiled Rust cdylibs via the PluginActor trait and the nautilus_plugin! macro

Component State Machine

A formal finite state machine (FSM) that governs the lifecycle of all major system entities.

State	Description
PRE_INITIALIZED	The initial state upon instantiation.
READY	Component has been wired with dependencies and is ready to start.
RUNNING	The component is actively processing events.
STOPPED	The component has been gracefully shut down.
DISPOSED	Resources have been released.

• Implementation: ComponentState enum in

---

Trading & Domain Concepts

OMS Type (Order Management System)

Determines how the ExecutionEngine tracks and aggregates positions for a strategy.

• HEDGING: Each trade can create a distinct position; multiple positions can exist for the same instrument simultaneously.
• NETTING: All trades for an instrument are collapsed into a single net position. The position ID naming convention is typically {instrument_id}-{strategy_id}.
• Position Snapshots: The system supports netting OMS position snapshotting for state recovery.

Fixed-Point Precision

NautilusTrader avoids floating-point errors by using fixed-point arithmetic for prices, quantities, and money.

1. Standard Precision: 64-bit integers with 9 decimal places.
2. High-Precision Mode: 128-bit integers with 16 decimal places (unavailable on Windows)

• Implementation: Managed via Price and Quantity types in nautilus-model. Recent updates added checked mantissa/exponent constructors

Instrument

A financial contract or asset that can be traded. Nautilus supports a wide hierarchy including CurrencyPair, Equity, Futures, Option, and BettingInstrument.

• New Types: CryptoFuturesSpread and CryptoOptionSpread have been added to mirror contract sizing for combos
• Symbology: InstrumentId serves as the unique identifier across the system.
• Lookup: The system provides typed errors for missing lookups: CurrencyLookupError, InstrumentLookupError, and OrderLookupError

Order Emulator

A local component that simulates exchange behavior for conditional orders (like Stop-Loss or Trailing-Stops) that are not natively supported by a specific venue's API. It utilizes the MatchingCore for deterministic trigger logic.

Natural Language to Code Entity Mapping

The following diagram bridges domain concepts to their specific class implementations within the codebase.

Domain to Code Entity Space

---

Execution & Simulation Terms

MatchingCore

The low-level Rust-based matching logic used by both the BacktestEngine and the OrderEmulator. It handles the deterministic matching of orders against price updates.

FillModel

A set of rules used during backtesting to determine how (and if) an order is filled based on available market data (e.g., DefaultFillModel, TwoTierFillModel, SizeAwareFillModel). Recent additions include the ProbabilityPriceFeeModel

Execution Pipeline

The sequence of events from a strategy issuing a SubmitOrder command to the final OrderFilled event.

Order Execution Data Flow

---

Event Sourcing & Event Store

EventStore

The durable authority for state-affecting history. It captures commands, events, and venue reports flowing across the MessageBus.

• BusCaptureAdapter: Subscribes to the bus and forwards messages to the EventStoreWriter
• RedbBackend: An embedded key-value store used for high-performance local persistence
• Sequence (seq): A monotonically increasing identifier for every entry in the store, providing total ordering.
• Run & Entry: A "run" represents a single execution lifecycle (start to stop). An "entry" is a single serialized message with metadata
• High-watermark: The highest sequence number successfully persisted to the backend.
• Verifier: A utility to check the integrity of the event store, identifying gaps or index drift
• Format Change: The event_store format was updated in v1.230, requiring regeneration of old stores

---

Technical abbreviations and selected-adapter jargon

Abbreviation	Full Term	Context	Code Pointer
FFI	Foreign Function Interface	Optional ABI boundary outside the native Rust API documented in this edition.
DBN	Databento Binary Encoding	High-performance market data format.
PnL	Profit and Loss	Portfolio performance tracking.
MSRV	Minimum Supported Rust Version	Build system requirement (1.97.0 at the pinned revision).
DST	Deterministic Simulation Testing	Validation of system state under simulation.
ABI	Application Binary Interface	Versioning for the plugin system to ensure host/plugin compatibility.

bon::Builder Config Pattern

A Rust crate (bon) used for generating type-safe, ergonomic builders for complex configuration objects.

• Implementation: Used extensively for configuration design where Option means semantic absence and strict unknown-field rejection is enforced

RecordFlag (F_LAST / F_SNAPSHOT)

Flags used in data streams to signal event boundaries and snapshot state.

• F_LAST: Marks the final delta in a logical group
• F_SNAPSHOT: Marks deltas belonging to a full book snapshot

Plugin System

The nautilus-plugin crate allows loading separately compiled Rust shared libraries (cdylibs) at runtime.

• PluginManifest: Defines the metadata and entry points for a plugin.
• ABI Versioning: Hardened to reject manifest ABI mismatches