Enum TimeInForce 

pub enum TimeInForce {
    Gtt,
    Gtc,
    Ioc,
    Fok,
    Unspecified,
}

Time-in-force instructions that control order lifecycle and execution behavior.

This enum defines how long an order should remain active and under what conditions it should be automatically canceled. Time-in-force rules are fundamental to order management and directly impact execution behavior.

Order Lifetime Categories

Persistent Orders (remain on book)

• GTC: Good Till Cancel - persists until filled or manually canceled
• GTT: Good Till Time - persists until specific expiry timestamp

Immediate Orders (execute now or cancel)

• IOC: Immediate or Cancel - execute available quantity immediately, cancel remainder
• FOK: Fill or Kill - execute complete quantity immediately or cancel entirely

Execution Behavior

Each time-in-force type has distinct matching behavior:

Type	Partial Fills	Rests on Book	Requires Complete Fill
GTC	✓	✓	✗
GTT	✓	✓	✗
IOC	✓	✗	✗
FOK	✗	✗	✓

Usage Examples

Long-term position building (GTC)

use types::common::TimeInForce;

let gtc = TimeInForce::Gtc;
println!("Order persists: {}", gtc.is_persistant()); // true

Time-limited orders (GTT)

use types::common::TimeInForce;

// GTT orders require expiry_timestamp in SubmitOrderRequest
let gtt = TimeInForce::Gtt;
assert!(gtt.is_persistant()); // Also persistent until expiry

Immediate execution strategies (IOC/FOK)

use types::common::TimeInForce;

let ioc = TimeInForce::Ioc; // Partial fills OK
let fok = TimeInForce::Fok; // All or nothing

assert!(!ioc.is_persistant()); // Never rests on book
assert!(!fok.is_persistant()); // Never rests on book

Compatibility with Other Order Features

Post-Only Orders

• Compatible: GTC, GTT (can rest on book)
• Incompatible: IOC, FOK (require immediate execution)

Market Orders

• Compatible: IOC, FOK (immediate execution)
• Rejected: GTC, GTT — a market order may not be persistent, and the pair is refused before it reaches the engine

JSON Representation

Serialized as uppercase abbreviations:

"GTC"  // Good Till Cancel
"GTT"  // Good Till Time
"IOC"  // Immediate or Cancel
"FOK"  // Fill or Kill

Validation Requirements

• GTT orders: Must include valid future expiry_timestamp
• IOC/FOK orders: Cannot use post_only flag
• All types: Must not be Unspecified in valid orders

Variants

Gtt

Good Till Time - order expires at specified timestamp.

GTT orders remain active in the order book until either:

1. They are completely filled through matching
2. They reach their specified expiry timestamp
3. They are manually canceled

Requirements

• Must specify expiry_timestamp in the order request
• Expiry timestamp must be in the future
• Timestamp should account for network latency

Behavior

• Partial fills: Allowed and common
• Rests on book: Yes, until expiry or completion
• Automatic cleanup: Yes, at expiry timestamp

Use Cases

• Orders with specific time constraints
• End-of-session or end-of-day orders
• Campaign-based trading with deadlines
• Risk management with automatic expiry

Example Scenarios

• “Buy 1 BTC at $45,000 if not filled by market close”
• “Sell limit order valid only for next 30 minutes”
• “Stop-loss order expires if not triggered within 24 hours”

Gtc

Good Till Cancel - order persists until manually canceled or filled.

GTC orders are the most common type, remaining active indefinitely until explicit action is taken. They provide maximum flexibility for long-term trading strategies.

Behavior

• Partial fills: Allowed and tracked
• Rests on book: Yes, indefinitely
• Manual management: Requires explicit cancellation

Use Cases

• Long-term position building
• Limit orders at target prices
• Standing offers in low-liquidity markets
• Set-and-forget trading strategies

Management Considerations

• Orders remain active across sessions
• May consume margin/balance indefinitely
• Require active monitoring and management
• Can be affected by corporate actions or market events

Example Scenarios

• “Buy 10 ETH at $2,000 when price drops”
• “Sell limit at $60,000 for profit taking”
• “Standing bid for accumulating position over time”

Ioc

Immediate or Cancel - execute available quantity immediately, cancel remainder.

IOC orders attempt immediate execution against available liquidity. Any portion that cannot be immediately matched is automatically canceled rather than resting on the order book.

Behavior

• Immediate execution: Must execute immediately or be canceled
• Partial fills: Allowed for available liquidity
• No book resting: Unfilled portions are canceled
• Quick cleanup: Automatically resolves to final state

Use Cases

• Market impact testing (“how much can I buy now?”)
• Liquidity sweeping strategies
• Avoiding stale order risks
• High-frequency trading patterns
• Portfolio rebalancing with immediate execution

Execution Examples

• Order: “Buy 5 BTC IOC at $50,000”
• Available: 3 BTC at $50,000 or better
• Result: Buy 3 BTC, cancel remaining 2 BTC

Compatibility

• Cannot use with post_only flag (conflicts with immediate execution)
• Works well with market orders for guaranteed execution attempt
• Suitable for limit orders when partial execution is acceptable

Fok

Fill or Kill - execute complete quantity immediately or cancel entirely.

FOK orders require complete immediate execution of the entire order quantity. If the full amount cannot be matched immediately, the entire order is canceled with no partial execution.

Behavior

• All-or-nothing: Complete fill required or total cancellation
• Immediate execution: Must execute immediately or be canceled
• No partial fills: Either 100% filled or 0% filled
• Atomic operation: Single execution event

Use Cases

• Large block trading where partial fills are problematic
• Arbitrage strategies requiring complete position
• Risk management requiring full hedge execution
• Algorithms that need atomic position changes

Execution Examples

• Order: “Sell 10 ETH FOK at $3,000”
• Scenario A - Available: 12 ETH at $3,000+ → Execute 10 ETH
• Scenario B - Available: 7 ETH at $3,000+ → Cancel entire order

Risk Considerations

• Higher rejection rate than IOC orders
• Requires sufficient liquidity for full execution
• May need price adjustment if frequently rejected
• Market impact assessment should consider full quantity

Compatibility

• Cannot use with post_only flag (conflicts with immediate execution)
• Particularly useful with market orders for guaranteed attempt
• Requires careful price setting for limit orders

Unspecified

Unspecified time-in-force - invalid for actual orders.

This is what serde substitutes when a submitted request omits tif; validation then rejects the order. It is not TimeInForce::default() — #[default] sits on Gtc — and it is not what SubmitOrderRequestBuilder starts from either: the builder holds Option<TimeInForce> and build() reports a missing field.

Behavior

• Always causes order validation to fail
• Never valid for order submission
• Should be replaced with appropriate TIF before submission

Implementations

impl TimeInForce

pub fn is_persistant(&self) -> bool

Trait Implementations

impl Clone for TimeInForce

fn clone(&self) -> TimeInForce

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Copy for TimeInForce

impl Debug for TimeInForce

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

Formats the value using the given formatter.

impl Default for TimeInForce

fn default() -> TimeInForce

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for TimeInForce

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Display for TimeInForce

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

Formats the value using the given formatter.

impl Eq for TimeInForce

impl PartialEq for TimeInForce

fn eq(&self, other: &TimeInForce) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl Serialize for TimeInForce

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.

impl StructuralPartialEq for TimeInForce