Conditional Orders
A conditional order is an order that waits for a specific condition before it can affect trading. The condition is usually based on market price, but it can also be tied to order status, risk rules, or another instruction in a larger order chain. Until the trigger is met, the order may exist as a stored instruction rather than as visible executable liquidity. This distinction matters because an inactive conditional order should not always be counted as current order book depth. In crypto market data systems, especially systems reconstructing Level 4 order book state, the timing of activation is part of the state logic. A stop market order, for example, may become a market order only after the stop price is reached. A stop limit order may become a limit order only after its stop condition is satisfied. A take profit order may wait for a favorable price before submitting an executable instruction. Bracket and parent/child workflows can also include contingent child orders that are created, activated, canceled, or replaced based on what happens to a parent order. For developers, the main point is to separate the conditional instruction from the active order book event that changes executable depth.
Why It Matters
Conditional orders affect how trading systems represent intent, risk controls, and future liquidity. In L4 order book reconstruction, they matter because contingent child instructions may not contribute to executable depth until they are triggered or activated.
How do conditional orders work in crypto trading?
A conditional order starts with a rule that must be evaluated before the order can trade. The rule often compares a trigger price with the latest traded price, mark price, index price, or another venue-specific reference price. When the condition becomes true, the trading system activates the order according to its configured type. That activated order may then enter the book as a limit order, execute as a market order, or create another child instruction. If the trigger condition is never met, the order may remain inactive until it expires or is canceled. This means the order lifecycle includes both the waiting phase and the active execution phase.
Why do conditional orders matter for L4 order book reconstruction?
L4 data can include order-level events that describe creation, changes, cancellations, and relationships between instructions. Conditional orders add complexity because not every recorded instruction is immediately part of executable market depth. A reconstruction engine needs to know when an instruction is inactive, when it is activated, and what book event results from that activation. If inactive conditional orders are treated as normal resting orders, reconstructed depth can be overstated. If triggered child orders are missed, the book can be understated or sequenced incorrectly. This is why conditional logic is usually handled as part of the market data state machine rather than as a simple price-level update.
What are common examples of conditional orders?
A stop market order becomes a market order when its stop trigger is reached. A stop limit order becomes a limit order after the trigger condition is satisfied, using a specified limit price. A take profit order is designed to activate when price reaches a favorable target. A bracket order can attach related exit instructions, such as a stop loss and take profit, to an entry order. One-cancels-the-other behavior can cancel a remaining instruction when the paired instruction is triggered or filled. These examples show why conditional order handling often requires both order-state tracking and relationship tracking.
Real-World Example
A trader buys a crypto perpetual contract and attaches two conditional child instructions: a stop loss below the entry price and a take profit above it. Before either trigger is reached, those child instructions describe future actions but may not appear as executable depth in the live book. If the market trades up to the take profit trigger, the take profit instruction activates and may enter or execute against the book, while the stop loss instruction may be canceled depending on the bracket logic.
Conditional Orders and Market Data API
CoinAPI Market Data API helps developers work with normalized crypto market data across exchanges and trading venues. For systems that reconstruct order books or replay market activity, consistent order events and timestamps are important for deciding when conditional instructions become active. This is especially relevant when analyzing L4-style data, parent/child relationships, and venue-specific order lifecycle behavior.