Struct SubmitOrderRequest 

pub struct SubmitOrderRequest {

    pub market: Arc<str>,
    pub market_id: MarketId,
    pub account: Arc<str>,
    pub account_id: AccountId,
    pub side: Side,
    pub tif: TimeInForce,
    pub expiry_timestamp: Option<u128>,
    pub reduce_only: bool,
    pub post_only: bool,
    pub order_type: OrderType,
    pub limit_price: Option<String>,
    pub quantity: Option<String>,
    pub client_order_id: Option<Arc<str>>,
    pub conditional: Option<Conditional>,
}

Complete order submission request with support for all order types and advanced features.

This is the primary struct for submitting orders to the matching engine. It supports basic market and limit orders, as well as advanced conditional orders with sophisticated trigger mechanisms, order linking, and risk management features.

Order Types Supported

Basic Orders

• Market Orders: Execute immediately at best available price
• Limit Orders: Execute only at specified price or better

Advanced Orders

• Conditional Orders: Complex orders with trigger conditions
• Time-based Orders: GTT orders with expiry timestamps
• Risk Management Orders: Post-only and reduce-only orders

Field Aliases

Most fields support compact aliases for bandwidth optimization:

• market → "m"
• account → "sa"
• side → "s"
• tif (time_in_force) → "t"
• expiry_timestamp → "e"
• reduce_only → "ro"
• post_only → "po"
• order_type → "ot"
• limit_price → "p"
• client_order_id → "cid"
• conditional → "c"

Required Fields

The following fields must be specified (either explicitly or via builder):

• market: Market identifier
• account: Account identifier
• side: Buy or Sell
• tif: Time in force (GTC, GTT, IOC, FOK)
• order_type: Market or Limit
• quantity: order size — required only when conditional is absent. On a conditional order it must be omitted; the size lives in conditional.quantity (supplying both is rejected, 135)

Conditional Fields

• limit_price: Required for limit orders, forbidden for market orders
• expiry_timestamp: Required for GTT orders
• conditional: Optional for advanced conditional order behavior

Examples

Simple limit buy order

use types::api::submit_order::SubmitOrderRequest;
use types::common::{Side, TimeInForce, OrderType};
use types::core::{AccountId, MarketId};

let order = SubmitOrderRequest {
    market: "0x123".into(),
    market_id: MarketId::from("0x123"),
    account: "0x123".into(),
    account_id: AccountId::from("0x123"),
    side: Side::Buy,
    tif: TimeInForce::Gtc,
    order_type: OrderType::Limit,
    limit_price: Some("50000.00".to_string()),
    quantity: Some("0.1".to_string()),
    expiry_timestamp: None,
    reduce_only: false,
    post_only: false,
    client_order_id: None,
    conditional: None,
};

Using the builder pattern (recommended)

use types::api::submit_order::SubmitOrderRequest;

let order = SubmitOrderRequest::builder()
    .market("0x123")
    .account("0x123")
    .buy()
    .limit_order("50000.00")
    .quantity("0.1")
    .good_till_cancel()
    .build()
    .expect("Failed to build order");

Market order with immediate-or-cancel

use types::api::submit_order::SubmitOrderRequest;

let order = SubmitOrderRequest::builder()
    .market("0x456")
    .account("0x456")
    .sell()
    .market_order()
    .quantity("2.0")
    .immediate_or_cancel()
    .build()
    .expect("Failed to build order");

GTT order with expiry

use types::api::submit_order::SubmitOrderRequest;

let order = SubmitOrderRequest::builder()
    .market("0x789")
    .account("0x789")
    .buy()
    .limit_order("0.00001234")
    .quantity("100000")
    .good_till_time(1747313713)
    .post_only(true)
    .client_order_id("my-doge-order")
    .build()
    .expect("Failed to build order");

Advanced conditional order

use types::api::submit_order::{SubmitOrderRequest, Conditional, Trigger};

let stop_loss = Conditional::builder()
    .falls_below()
    .trigger(Trigger::price("45000.00"))
    .last_trade_price()
    .percentage_of_position_at_trigger("1.0")
    .build()
    .expect("Failed to build conditional");

// no top-level quantity: the conditional carries the size
let order = SubmitOrderRequest::builder()
    .market("0x123")
    .account("0x123")
    .sell()
    .market_order()
    .immediate_or_cancel()
    .conditional(stop_loss)
    .build()
    .expect("Failed to build order");

JSON Examples

Basic limit order (full field names):

{
  "market": "0x5efc5ad00c209baf4c5d77dfd1be18e8b50916e53adbe2142ae1b47af445303c",
  "account": "0xcc6ebf909253ea35314bb28d91321f6415827c01790fba84aaf570c87372850a",
  "side": "Buy",
  "tif": "GTC",
  "order_type": "Limit",
  "limit_price": "50000.00",
  "quantity": "0.1",
  "reduce_only": false,
  "post_only": false
}

Market order with aliases:

{
  "m": "0x5efc5ad00c209baf4c5d77dfd1be18e8b50916e53adbe2142ae1b47af445303c",
  "sa": "0xcc6ebf909253ea35314bb28d91321f6415827c01790fba84aaf570c87372850a",
  "s": "Sell",
  "t": "IOC",
  "ot": "Market",
  "quantity": "2.0",
  "ro": false,
  "po": false
}

GTT order with expiry:

{
  "market": "DOGEBTC",
  "account": "trader789",
  "side": "Buy",
  "tif": "GTT",
  "expiry_timestamp": 1800000000000,
  "order_type": "Limit",
  "limit_price": "0.00001234",
  "quantity": "100000",
  "post_only": true,
  "client_order_id": "my-doge-order"
}

Validation

The request undergoes comprehensive validation including:

• Market existence and validity
• Account authorization
• Price and quantity format and precision
• Order type and price consistency
• Time-in-force and expiry consistency
• Post-only compatibility checks
• Conditional order parameter validation

The builder rejects a request that is internally inconsistent; the rules that need live market state — tick and lot sizes, minimum order value, whether the market exists — are the sequencer’s, and a rejection comes back on the transaction report.

Fields

market: Arc<str>

The market identifier where the order should be placed.

The market’s on-chain object id: a 0x-prefixed 256-bit hex string, not a BASEQUOTE symbol. Anything that does not parse as hex resolves to the zero id and is rejected as an unknown market (102).

Validation

• Cannot be empty
• Must parse as 0x-prefixed hex ([MarketId])
• Must exist in the system
• Must be currently active for trading

Example

• "0x5efc5ad00c209baf4c5d77dfd1be18e8b50916e53adbe2142ae1b47af445303c"

market_id: MarketId

account: Arc<str>

The account identifier that owns this order.

This identifies which trading account the order belongs to and is used for position tracking, balance checks, and order management.

Validation

• Cannot be empty
• Must be authorized to trade in the specified market
• Must have sufficient balance/margin for the order

Format

Account identifiers are typically alphanumeric strings, but the exact format depends on your system’s account management.

account_id: AccountId

side: Side

The order side - whether this is a buy or sell order.

Values

• Buy: Purchase the base asset (pay with quote asset)
• Sell: Sell the base asset (receive quote asset)

Examples

• Buy on BTCUSD: Buy Bitcoin, pay USD
• Sell on ETHUSD: Sell Ethereum, receive USD

Default

Defaults to Side::Unspecified which will cause validation to fail. Must be explicitly set to Buy or Sell.

tif: TimeInForce

Time-in-force specification controlling order lifecycle.

This determines how long the order remains active and under what conditions it should be canceled automatically.

Values

• Gtc (Good Till Cancel): Order remains active until filled or manually canceled
• Gtt (Good Till Time): Order expires at specified timestamp
• Ioc (Immediate or Cancel): Order executes immediately, cancel remainder
• Fok (Fill or Kill): Order executes completely or is canceled entirely

Validation

• GTT orders require expiry_timestamp to be set
• IOC and FOK orders are incompatible with post-only flag

Default

Defaults to TimeInForce::Unspecified which will cause validation to fail.

expiry_timestamp: Option<u128>

Expiry timestamp for GTT (Good Till Time) orders.

When specified, the order will be automatically canceled at this Unix timestamp (milliseconds since epoch) if not already filled.

Required For

• GTT time-in-force orders

Forbidden For

• All other time-in-force types (GTC, IOC, FOK)

Validation

• Must be in the future relative to submission time
• Should not be too far in the future (system-dependent limits)
• Must be a valid Unix timestamp in milliseconds

Format

Unix timestamp in milliseconds (not seconds). For example:

• 1747313713000 represents a specific future timestamp

reduce_only: bool

Whether this order should only reduce existing position size.

When true, the order can only decrease the absolute size of an existing position and cannot increase it or open a new position in the opposite direction.

Behavior

• true: Order will be rejected if it would increase position size
• false: Order can increase, decrease, or reverse positions normally

Use Cases

• Risk management to prevent position size increases
• Automated closing strategies
• Compliance with position limits

Validation

• Compatible with all order types and time-in-force options
• System will check position size before execution

post_only: bool

Whether this order should only add liquidity to the order book.

When true, the order will be rejected if it would execute immediately against existing orders (taking liquidity). The order will only be accepted if it can be placed on the order book as a maker order.

Behavior

• true: Order rejected if it would execute immediately
• false: Order can execute immediately or rest on book

Validation

• Cannot be used with IOC or FOK time-in-force (these require immediate execution)
• Cannot be used with market orders (these always take liquidity)
• Only compatible with limit orders and persisting time-in-force (GTC, GTT)

Benefits

• Often receives lower trading fees (maker rebates)
• Guarantees the order won’t execute at worse price than specified
• Provides predictable execution behavior

order_type: OrderType

The type of order execution behavior.

Values

• Market: Execute immediately at best available price
• Limit: Execute only at specified price or better

Validation

• Limit orders require limit_price to be specified
• Market orders cannot have limit_price specified
• Market orders cannot use post-only flag

Default

Defaults to OrderType::Unspecified which will cause validation to fail.

limit_price: Option<String>

The limit price for limit orders.

Specifies the price at which the order should execute. For buy orders, execution will occur at this price or lower. For sell orders, execution will occur at this price or higher.

Required For

• Limit orders (order_type = OrderType::Limit)

Forbidden For

• Market orders (order_type = OrderType::Market)

Format

• Must be a valid decimal string
• Must be positive (non-zero, non-negative)
• Must conform to market price precision requirements

Validation

• Checked for valid decimal format
• Validated against market tick size requirements
• Must be within reasonable bounds for the market

Examples

• "50000.00" for $50,000 per Bitcoin
• "3500.50" for $3,500.50 per Ethereum
• "0.00001234" for micro-priced assets

quantity: Option<String>

The quantity/size of the order in base asset units.

Specifies how much of the base asset to buy or sell. This is always expressed in terms of the base asset (the first part of the market pair).

Required

On a plain order, always. On a conditional order it must be omitted — the size lives in conditional.quantity, and supplying both is rejected with ConditionalOrderMustNotHaveMainQuantity (135).

Format

• Must be a valid positive decimal string
• Must conform to market quantity precision requirements
• Must meet minimum and maximum size requirements

Validation

• Checked for valid decimal format
• Must be positive (greater than zero)
• Validated against market lot size requirements
• Must be within market minimum and maximum bounds

Examples

• "0.1" to trade 0.1 Bitcoin
• "100" to trade 100 shares
• "1000000" to trade 1 million DOGE

Note

A conditional order does not override this field, it replaces it: leave this None and set conditional.quantity instead. Both set is 135, neither is 136.

client_order_id: Option<Arc<str>>

Optional client-defined identifier for order tracking and linking.

This allows clients to assign their own identifiers to orders for tracking, correlation with internal systems, and creating relationships between orders (such as OCO pairs).

Characteristics

• Must be unique per account (if specified)
• Can be used to link orders together (OCO, bracket orders)
• Useful for order management and tracking
• Returned in order status and execution reports

Format

• Typically alphanumeric strings
• Maximum length depends on system configuration
• Should be meaningful for client-side tracking

Use Cases

• Order correlation with internal trading systems
• Creating parent-child order relationships
• OCO (One-Cancels-Other) order pairs
• Audit trails and reconciliation

Examples

• "trade-123-entry" for entry order identification
• "stop-loss-btc-456" for stop-loss order identification
• "uuid-abc123def456" using UUID for uniqueness

conditional: Option<Conditional>

Optional conditional order specification for advanced order behavior.

When specified, this transforms the order into a conditional order with sophisticated trigger mechanisms, price monitoring, expiration rules, and linking capabilities.

Behavior

• If None: Order behaves as a standard market or limit order
• If Some: Order becomes conditional with trigger-based activation

Features

Conditional orders support:

• Price-based triggers (stop-loss, take-profit)
• Multiple reference prices (last trade, index, mark)
• Time-based expiration with trigger or cancel actions
• Quantity as a fraction (0,1] of the position, at trigger or at submission
• Order-linked activation (dormant until a parent order fills)

Trailing-stop triggers (125) and OCO links (129) are reserved vocabulary the sequencer rejects.

Use Cases

• Stop-loss orders: Automatically sell when price falls
• Take-profit orders: Automatically sell when price rises
• Trailing stops: Dynamic stop prices that follow favorable moves
• Bracket orders: Combined entry with stop-loss and take-profit
• OCO orders: Either-or execution strategies

Validation

When conditional is specified, additional validation applies:

• All conditional fields must be properly configured
• Order linking relationships must be valid
• OCO relationships cannot create cycles
• Quantity specifications must be compatible

Example

use types::api::submit_order::{Conditional, Trigger};

let stop_loss = Some(Conditional::builder()
    .falls_below()
    .trigger(Trigger::price("45000.00"))
    .last_trade_price()
    .build()
    .expect("Failed to build conditional"));

Implementations

impl SubmitOrderRequest

pub fn builder() -> SubmitOrderRequestBuilder

Create a new SubmitOrderRequestBuilder

Trait Implementations

impl Clone for SubmitOrderRequest

fn clone(&self) -> SubmitOrderRequest

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for SubmitOrderRequest

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for SubmitOrderRequest

fn deserialize<__D>( __deserializer: __D, ) -> Result<SubmitOrderRequest, <__D as Deserializer<'de>>::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl From<SubmitOrderRequest> for Command

fn from(value: SubmitOrderRequest) -> Command

Converts to this type from the input type.

impl Serialize for SubmitOrderRequest

fn serialize<__S>( &self, __serializer: __S, ) -> Result<<__S as Serializer>::Ok, <__S as Serializer>::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.