> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Conditional orders
> Orders that rest off the book until a price condition is met — how they trigger, how they link, and what state they are in at each point.
A conditional order is not on the order book. It sits in a separate store, watching a price, and only becomes a real order when its trigger condition is met. Until then it consumes no queue position and shows no depth to anyone else.
That distinction drives everything else on this page. A resting limit order can be matched at any moment. A conditional order cannot be matched at all — it can only be *converted*, and the conversion happens at a defined point inside block execution.
## Three shapes
The same trigger machinery serves three different intents, and they differ in what they are attached to.
| Shape | Attached to | Typical use |
| -------------------------- | -------------------------------- | ------------------------------------------------------- |
| **Standalone** | Nothing | Enter a position if price breaks a level |
| **Attached to an order** | A specific order you are placing | Set take-profit and stop-loss at the moment you open |
| **Attached to a position** | Your position in a market | Protect a position you already hold, whatever opened it |
The third is the one that behaves least like an order. It is scoped to the position rather than to a quantity, so it follows the position as that position changes size — see [Take-profit and stop-loss](/trading/tp-sl).
## Triggering
Two things decide when a conditional order fires: which price it watches, and where in the block that check happens.
**Which price.** A trigger can watch the mark price or the last traded price. [Mark price](/trading/mark-price) is smoothed and harder to push around, which makes it the safer default for protective orders. Last price reacts faster and is closer to what you see printing, which some strategies want. The choice is per order.
**Where in the block.** Conditional orders are scanned before matching runs, using the marks fixed at the start of the block. An order triggered by this block's price becomes a live order in this block — not the next one. See [Transaction sequencing](/trading/tx-sequencing) for the full priority order.
The trigger watches one of these
Mark pricesmoothed, harder to push — the safer default
Last traded pricefaster, closer to what you see printing
Resting in the trigger storeno queue position, no depth
Condition met?
Converted to a market or limit order
Matched in this same block
Scanned before matching runs, against the marks fixed at the start of the block.
not yet — checked again next block
## Linking
Conditional orders rarely travel alone. Three linkage patterns exist, and each has its own cancellation semantics.
**Take-profit and stop-loss cancel each other.** A protective pair is one-cancels-the-other: when either leg fires, the other is cancelled automatically. You cannot end up flat and still carrying a live stop.
**An attached pair follows its parent order.** If you attach take-profit and stop-loss to an order you are placing, the pair does not become active until the parent fills. If the parent is cancelled before filling, the attached legs go with it.
**A position-scoped pair follows the position.** If the position closes — by your own order, by liquidation, or by deleveraging — the protective orders attached to it are cancelled. They exist to protect something; when that something is gone, so are they.
This is the part integrations most often get wrong. A stop that outlives the position it was protecting will, at the next trigger, open a *new* position in the opposite direction. Linkage is what prevents that, and it is enforced by the protocol rather than by the client that placed the order.
## Order states
A conditional order moves through a defined set of states, and every transition is a protocol event you can observe.
| State | Meaning |
| ------------- | ---------------------------------------------------- |
| **Waiting** | Accepted and watching its trigger price |
| **Triggered** | Condition met; converted and submitted to matching |
| **Filled** | The converted order matched |
| **Cancelled** | Withdrawn by you, or by linkage when a sibling fired |
| **Rejected** | Failed validation, at placement or at conversion |
The state that surprises people is **rejected at conversion**. An order can be accepted, wait for hours, trigger correctly, and still fail — because conditions are re-checked at the moment of conversion, not only at placement. Margin may no longer be sufficient. A reduce-only conditional order may no longer have a position to reduce. The trigger fired; the resulting order did not survive.
## Checks at placement and at conversion
Two different sets of rules apply at two different times.
**At placement**, the protocol checks that the trigger price makes sense in the direction you specified — a stop-loss that would trigger immediately is a mistake, not a strategy — and that the trigger sits within an allowed distance of the current price. Open-order count limits and rate limits also apply here.
**At conversion**, margin adequacy is re-evaluated against your position as it stands at that moment, reduce-only constraints are re-checked, and a conditional market order is subject to the same slippage protection as any market order. See [Market-to-limit](/trading/market-to-limit).
A conditional order is not a guarantee of execution. It is a guarantee that an order will be *submitted* when the condition is met. In a fast move the resulting order may fill well beyond the trigger price, or not at all if it is a limit conversion. Protective orders reduce exposure to gaps; they do not eliminate it.
## Where to go next
The two protective shapes and how each behaves as your position changes.
The price most protective triggers should watch, and why it is smoothed.
Where trigger scanning sits relative to cancels and new orders.
What a conditional order converts into.