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.

Order Types and Lifecycle

Relevant Rust source files

• crates/model/src/orders/mod.rs
• crates/model/src/orders/any.rs
• crates/model/src/orders/builder.rs
• crates/model/src/events/order/mod.rs
• crates/model/src/enums.rs

This page documents the order types supported by NautilusTrader, their lifecycle through the system, and the event-driven flow from order submission to fill. It covers the order state machine, available execution instructions, and how orders interact with the execution and risk engines.

Order Type Overview

NautilusTrader supports a comprehensive set of order types, defined by the OrderType enum. All order types derive from a core model structure, implemented in both Rust and legacy bindings Specific implementations provide specialized logic for price and trigger handling.

Order Type	Class	Description
MARKET	MarketOrder	Executes immediately at best available price
LIMIT	LimitOrder	Rests at specified price or better until matched
STOP_MARKET	StopMarketOrder	Becomes market order when stop price triggered
STOP_LIMIT	StopLimitOrder	Becomes limit order when stop price triggered
MARKET_TO_LIMIT	MarketToLimitOrder	Market order that converts unfilled quantity to limit
MARKET_IF_TOUCHED	MarketIfTouchedOrder	Becomes market order when trigger price reached
LIMIT_IF_TOUCHED	LimitIfTouchedOrder	Becomes limit order when trigger price reached
TRAILING_STOP_MARKET	TrailingStopMarketOrder	Stop that trails price by a fixed or percentage offset
TRAILING_STOP_LIMIT	TrailingStopLimitOrder	Stop-limit that trails price by offset

Nautilus categorizes these types for internal routing and validation logic:

• STOP_ORDER_TYPES: Orders with stop or trigger prices
• LIMIT_ORDER_TYPES: Orders that specify a limit price
• TRIGGERABLE_ORDER_TYPES: Orders that support an intermediate TRIGGERED status

Order State Machine

Rust orders progress through validated state transitions governed by OrderStatus and the concrete order/event logic in nautilus-model.

Transition Logic

Transitions are triggered by OrderEvent subclasses. The state machine ensures that an order cannot move to an invalid state (e.g., from FILLED back to ACCEPTED).

State Definitions

Status	Category	Description
INITIALIZED	Local	Order created via OrderInitialized seed event
EMULATED	Local	Held by OrderEmulator for local triggering
SUBMITTED	In-Flight	Sent to execution client, awaiting venue response
ACCEPTED	Open	Confirmed by venue, working in the book
FILLED	Terminal	Completely executed
DENIED	Terminal	Rejected by local RiskEngine

Order Event Flow

The system uses an event-driven architecture where components communicate via a MessageBus. The ExecutionEngine orchestrates the lifecycle by updating order state and routing commands.

Submission to Fill Sequence

The following diagram maps the logical flow to specific code entities involved in the lifecycle.

A limit-order lifecycle begins with canonical order construction, becomes a SubmitOrder command, passes risk checks, reaches the selected execution client, and advances only when venue reports are applied by ExecutionEngine.

Execution Instructions and Time in Force

Time in Force (TIF)

NautilusTrader supports standard TIF values defined in TimeInForce :

• GTC: Good 'til Canceled.
• IOC: Immediate or Cancel.
• FOK: Fill or Kill.
• GTD: Good 'til Date (requires expire_time ).
• DAY: Valid until the end of the trading day.
• AT_THE_OPEN / AT_THE_CLOSE: Auction-specific instructions.

Execution Flags

• post_only: Ensures the order only provides liquidity; it will be rejected or canceled if it would cross the spread
• reduce_only: Ensures the order only reduces or closes an existing position
• display_qty: Used for iceberg orders to specify the visible quantity on the public order book
• emulation_trigger: Defines the market price trigger for local order emulation (e.g., BID_ASK, LAST)

Position Integration

When an OrderFilled event occurs, the system updates the corresponding Order state, tracking filled_qty, leaves_qty, and avg_px

OrderAny is the sum type over concrete order implementations such as market, limit, stop-market, stop-limit, market-to-limit, trailing-stop, market-if-touched and limit-if-touched orders. Execution logic matches variants without erasing their invariants.

The Order base class maintains a history of events venue order IDs and trade IDs associated with its lifecycle.