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.

OrderEmulator and Complex Orders

Relevant Rust source files

crates/execution/src/order_emulator/mod.rs
crates/execution/src/order_emulator/emulator.rs
crates/execution/src/order_manager/manager.rs
crates/execution/src/matching_core/mod.rs

The OrderEmulator component provides local emulation of complex order types. Orders with an emulation trigger (e.g., TriggerType.LAST_PRICE) are held within the Nautilus system boundary and released to venues when trigger conditions are satisfied based on market data updates. This component is critical for supporting advanced order types (like Trailing Stops) on venues that do not natively support them.

Related components: ExecutionEngine handles order routing after release. RiskEngine validates orders before emulation. ExecAlgorithm handles higher-level order spawning and execution logic.

Overview

The OrderEmulator is an Actor subclass that intercepts orders with non-DEFAULT or specific emulation triggers. These orders remain in EMULATED status within the local system until market conditions satisfy their trigger criteria. The emulator maintains per-instrument MatchingCore instances that evaluate trigger conditions on each market data update.

Capabilities:

Stop market, stop limit, market-if-touched, and limit-if-touched order types.
Trailing stop market and trailing stop limit orders.
Three trigger types: DEFAULT, BID_ASK, and LAST_PRICE
Contingent order relationships: OTO (One-Triggers-Other) and OCO (One-Cancels-Other).
Order transformation on trigger (e.g., STOP_MARKET → MARKET).
Modification and cancellation of emulated orders.

Component Architecture

OrderEmulator Component Structure

Strategy intent passing through emulation or algorithm policy before the shared risk and execution boundaries.

Component Responsibilities:

Class	Role	Key Methods
`OrderEmulator`	Actor that manages emulated order lifecycle.	`execute()`, `create_matching_core()`
`OrderManager`	Manages local order state and command routing.	`cache_submit_order_command()`, `pop_submit_order_command()`
`MatchingCore`	Per-instrument order matching and trigger evaluation.	`match_order()`, `add_order()`, `delete_order()`, `iterate()`
`FillModel`	Defines logic for order fill simulation (Backtest).	`is_limit_filled()`, `get_orderbook_for_fill_simulation()`

MatchingCore Engine

The MatchingCore class is the heart of order emulation and backtest matching. It maintains per-instrument order state and market prices.

Book Layout and Priority

The Rust MatchingCore mirrors the matching responsibilities of a venue:

Limit Book: Keyed by limit price for plain LIMIT orders
Stop Book: Keyed by trigger price for STOP_*, *_IF_TOUCHED, and TRAILING_STOP_* orders

Orders are matched in price-time priority (FIFO at the same price). In the Rust implementation, bid limits use iter().rev() (highest price first) and ask limits use iter() (lowest price first)

Trigger Evaluation

Trigger conditions are evaluated in MatchingCore based on market data updates:

Order Side	Stop Trigger Condition	Touch Trigger Condition
BUY	`ask_price >= trigger_price`	`bid_price <= trigger_price`
SELL	`bid_price <= trigger_price`	`ask_price >= trigger_price`

Order Types and Emulation Triggers

The OrderEmulator handles various complex order types by transforming them into base orders once triggers are met.

Order Type	Trigger Mechanism	Transformation on Trigger
`STOP_MARKET`	`is_stop_triggered()`	Released as `MARKET`
`STOP_LIMIT`	`is_stop_triggered()`	Released as `LIMIT`
`MARKET_IF_TOUCHED`	`is_touch_triggered()`	Released as `MARKET`
`LIMIT_IF_TOUCHED`	`is_touch_triggered()`	Released as `LIMIT`
`TRAILING_STOP_MARKET`	`is_stop_triggered()` + dynamic trigger update	Released as `MARKET`

Trailing Stops: Trailing stop orders use the trailing_stop_calculate function to dynamically adjust the trigger price as the market moves in a favorable direction. The calculator supports offsets in Price, BasisPoints, and Ticks

Backtest Fill Modeling

In backtesting, the MatchingCore works with FillModel implementations to determine execution.

Natural Language to Code Entity Space: Fill Models

Fill models belong to simulation and emulation policy: best-price, probabilistic and size-aware variants decide whether modeled liquidity fills an order. They do not replace live venue reports.

FillModel: Provides probabilistic modeling for order fill dynamics including probability of fills (prob_fill_on_limit) and slippage (prob_slippage)
is_limit_filled(): Determines whether a LIMIT order filled based on the configured probability
get_orderbook_for_fill_simulation(): Allows custom fill models to provide their own liquidity simulation by returning a custom OrderBook

Order Lifecycle and Contingency

The OrderEmulator manages the lifecycle of emulated orders, including contingency relationships like OTO and OCO.

OrderEmulated: Published when an order is successfully added to a MatchingCore.
OrderReleased: Published when a trigger condition is met and the order is forwarded to the ExecutionEngine.
Contingency Management: The OrderManager tracks OTO target quantities and cached submit commands to handle complex execution sequences It supports OTO (One-Triggers-Other), OCO (One-Cancels-Other), and OTOCO (One-Triggers-One-Cancels-Other)