Orders

NautilusTrader provides a common model for order types, execution instructions, and contingency relationships across trading venues.

Overview

All order types derive from two fundamentals: Market and Limit orders. Market orders seek immediate execution at the best available price. Non‑marketable Limit orders rest in the order book at a specified price until matched, while marketable Limit orders can take liquidity.

NautilusTrader supports nine order types (the OrderType enum values), summarized under Order types with a dedicated guide for each.

Terminology

• An order is aggressive if its type is MARKET or it executes as a marketable order and takes liquidity.
• An order is passive if it rests without taking liquidity.
• An order is active local if it remains within the local system boundary in one of these non‑terminal statuses:
  • INITIALIZED
  • EMULATED
  • RELEASED
• An order is in-flight when at one of the following statuses:
  • SUBMITTED
  • PENDING_UPDATE
  • PENDING_CANCEL
• An order is open when at one of the following (non-terminal) statuses:
  • ACCEPTED
  • TRIGGERED
  • PENDING_UPDATE
  • PENDING_CANCEL
  • PARTIALLY_FILLED
• An order is closed when at one of the following (terminal) statuses:
  • DENIED
  • REJECTED
  • CANCELED
  • EXPIRED
  • FILLED
  • VOIDED

Order state flow

The following diagram illustrates the order lifecycle and primary state transitions:

Order status definitions

Execution instructions

Execution instructions specify conditions and restrictions on how a venue processes an order. Support varies by venue and adapter.

Time in force

Time in force specifies how long an order remains active before any unfilled quantity is canceled.

• GTC (Good Till Cancel): The order remains active until canceled by the trader or the venue.
• IOC (Immediate or Cancel / Fill and Kill): The order executes immediately, with any unfilled portion canceled.
• FOK (Fill or Kill): The order executes immediately in full or not at all.
• GTD (Good Till Date): The order remains active until a specified expiration date and time.
• DAY (Good for session/day): The order remains active until the end of the current trading session.
• AT_THE_OPEN (OPG): The order is only active at the open of the trading session.
• AT_THE_CLOSE: The order is only active at the close of the trading session.

Expire time

Use expire_time with GTD to specify when the order expires and leaves the venue's order book or order management system.

Post-only

An order marked post_only may provide liquidity but must not take it. A venue normally rejects or cancels the order if it would execute immediately. Market makers can use this instruction to target maker fees.

Reduce-only

An order marked reduce_only may reduce an existing position but must not increase exposure or open a position while flat. Exact behavior varies by venue.

The Nautilus SimulatedExchange applies these rules:

• It cancels the order when the associated position becomes flat.
• It reduces the order quantity as the associated position shrinks.

Display quantity

The display_qty specifies how much of an order is visible on the limit order book. An order with a smaller displayed quantity than its total quantity is commonly called an iceberg order. A display quantity of zero makes the order hidden when the venue supports that behavior.

Trigger type

The trigger type, also known as a trigger method, specifies the market price used to trigger a conditional order.

• NO_TRIGGER: Indicates that no trigger is specified; invalid for an order that requires one.
• DEFAULT: Uses the venue's default trigger type.
• LAST_PRICE: Uses the last traded price.
• BID_ASK: Uses the ask for BUY orders and the bid for SELL orders.
• DOUBLE_LAST: Requires two consecutive matching last prices.
• DOUBLE_BID_ASK: Requires two consecutive matching bid or ask prices, based on the order side.
• LAST_OR_BID_ASK: Uses either the last price or the side‑appropriate bid or ask.
• MID_POINT: Uses the midpoint between the bid and ask.
• MARK_PRICE: Uses the venue's mark price for the instrument.
• INDEX_PRICE: Uses the venue's index price for the instrument.

Trailing offset type

The trailing offset type specifies how a trailing order calculates its trigger offset from the applicable market price.

• NO_TRAILING_OFFSET: Indicates that no offset is specified; invalid for a trailing order.
• PRICE: Uses a price difference.
• BASIS_POINTS: Uses a percentage difference in basis points, where 100 basis points equals 1%.
• TICKS: Uses a number of ticks.
• PRICE_TIER: Uses a venue‑specific price tier.

Contingent orders

Contingency relationships can hold child orders until a parent activates or fills, cancel linked orders, or reduce their quantities. See Advanced orders for the available models and their constraints.

Order factory

Use the built‑in OrderFactory to create orders. Each Python Strategy exposes one as self.order_factory; the Rust strategy API exposes it through self.order(). The factory assigns the trader and strategy IDs, generates client order and initialization IDs when needed, records the initial timestamp, and applies defaults for the selected order type.

The examples in these guides create orders from a Strategy context.

See the OrderFactory API reference for further details.

Order types

NautilusTrader supports the following order types. Each links to a dedicated guide with a code example; optional parameters are marked with a comment showing the default value.

FIX OrdType mapping

Each type maps to the nearest FIX 5.0 SP2 OrdType <40> value, where the protocol defines one:

† FIX defines no dedicated OrdType for Limit-If-Touched; it is commonly sent as 4 (Stop Limit) with a favorable trigger. Trailing stops likewise have no dedicated value and are modeled as 3/4 plus trailing peg fields.

Advanced orders

Orders can be grouped into lists and linked with contingency relationships (OTO, OCO, OUO), and bracket orders attach take-profit and stop-loss children to an entry. See the Advanced orders guide for order lists, contingency types, validation rules, and brackets.

Emulated orders

NautilusTrader can locally emulate order types that a venue does not natively support, using only MARKET and LIMIT orders for actual execution. See the Emulated orders guide for the emulation lifecycle, supported types, querying, and best practices.

Related guides

• Events - Order events, position events, and handler dispatch.
• Execution - Order execution and fill handling.
• Positions - Positions created from order fills.
• Strategies - Order management from strategies.