What are Supported Order Types?

Introduction

Supported order types are the set of trading instructions an exchange will accept and execute. That sounds like a menu item, but it is really part of the exchange’s core design: it determines how much control a trader has over price, timing, visibility, and automation when sending an order into the market.

The important puzzle is this: two exchanges can list the same asset and still feel very different to trade on. The reason is not only fees or liquidity. It is also whether the venue lets you say, in effect, “buy now at whatever price is available,” or “buy only at this price,” or “buy if the market breaks above this level,” or “rest on the book but do not take liquidity,” or “show only part of my size.” An exchange that supports only market and limit orders is offering a much simpler execution language than one that also supports stop, iceberg, pegged, post-only, IOC, FOK, or contingent order lists.

That is why supported order types matter to both beginners and advanced traders. A newer user may mostly care about placing a straightforward trade without surprises. A more active trader may care about reducing slippage, avoiding partial fills, hiding size, automating exits, or controlling whether an order adds or removes liquidity. The exchange’s supported order types are the practical boundary between what a trader wants to express and what the matching engine can actually do.

What is an order type and how does it control execution?

At first principles, every order answers the same basic question: *under what conditions should this trade happen? * Supported order types are just different ways of specifying those conditions.

The simplest contrast is between a market order and a limit order. A market order says execution matters more than price: fill as much as possible immediately at the best available prices. A limit order says price matters more than immediacy: execute only at a specified price or better. That tradeoff (certainty of execution versus certainty of price) is the foundation on which most other order types are built.

From there, exchanges add more conditions. A stop order adds a trigger: do nothing unless the market reaches a specified level, then activate. A stop-limit order adds both a trigger and a limit price, so activation does not mean accepting any price. A trailing stop changes the trigger dynamically as the market moves in a favorable direction. A post-only order adds a liquidity condition: place this order only if it will rest on the book rather than execute immediately as a taker. An iceberg or reserve order adds a visibility rule: expose only part of the total size to the public book while keeping the rest hidden.

Seen this way, “supported order types” is not mainly a list of names. It is the set of execution rules the exchange is prepared to interpret. In FIX, the standard messaging language widely used for order entry, this is represented through fields such as OrdType for the order’s execution model, TimeInForce for how long it remains active, and StopPx for the trigger price on stop-style orders. The exchange may also require additional fields depending on the chosen type. A stop or stop-limit order, for example, requires a stop price; a pegged order requires peg instructions; a limit order requires a limit price.

How do exchanges implement order types under the hood?

At the user-facing level, an exchange UI may present a clean dropdown: Market, Limit, Stop, Take Profit, Trailing Stop, Post Only. Underneath, the exchange has to map those choices into message fields, validation checks, and matching-engine behavior.

The mechanism usually has three layers. The first layer is order definition: what conditions must be present for this order to make sense? A limit order needs a price. A stop order needs a trigger. A trailing order needs a trail distance or delta. A good-till-date order needs an expiry time. If the required fields are missing or inconsistent, the order is rejected before it ever reaches the book.

The second layer is lifecycle logic. Some orders go directly to the order book. Some execute immediately against existing resting liquidity. Some wait off-book until triggered. Some may be repriced, hidden, routed, or canceled depending on venue rules. FIX specifications make this explicit: a new order is submitted with NewOrderSingle, modifications are attempted with OrderCancelReplaceRequest, cancellations with OrderCancelRequest, and resulting state changes are reported back through execution reports. Importantly, a cancel or replace is not magic. It succeeds only if the exchange can still pull the order back from its current state.

The third layer is priority and interaction with the book. Exchanges do not just accept orders; they rank them. A venue may prioritize by price first, then displayed orders over non-displayed orders, then time within the same priority level. That means order type support is inseparable from matching rules. A reserve order is useful because it hides size, but that hidden portion may lose some priority relative to displayed liquidity. A midpoint or pegged order may seek better pricing, but some venues restrict it in locked or crossed markets. A post-only order protects maker status, but it may be rejected if it would match immediately.

A concrete example makes this clearer. Imagine a trader wants to buy a volatile asset but only if momentum confirms. On an exchange that supports stop orders, the trader can place a buy stop with a trigger above the current market. Until the trigger is reached, nothing rests on the book as executable liquidity. Once the market trades at that trigger, the exchange activates the order. If it is a stop-market order, it now behaves like a market order and consumes available offers, which means execution is likely but the final price may be worse than the trigger in a fast move. If it is a stop-limit order, the exchange activates a limit order instead. That protects against paying above a chosen price, but now execution is no longer guaranteed. The mechanism is simple: the order type is changing when the order becomes active and what kind of order it becomes after activation.

Why do exchanges offer different order-type selections?

No exchange supports every conceivable order type in every market. That is not an oversight; it follows from tradeoffs in product design, market structure, and operational complexity.

A retail-focused venue may emphasize a smaller, safer surface area: market, limit, and a few conditional orders. That reduces user error and simplifies the interface. More advanced venues, especially those serving active traders or institutional flow, tend to support a richer execution language because their users care about queue position, maker-taker economics, hidden size, routing behavior, and automated entry or exit logic.

There is also a technical cost to every added order type. Supporting a pegged order is not just adding a label in the UI. The exchange must define what the order pegs to, how it reprices when the reference changes, what happens in crossed markets, how price protection works, and how the order’s state is reported back to clients. Supporting contingent lists such as OCO, OTO, or OTOCO means maintaining relationships between multiple orders and enforcing rules about when one order activates or cancels another.

The evidence across exchanges makes this variation concrete. Kraken documents support for market, limit, stop-loss, stop-loss-limit, take-profit, take-profit-limit, trailing-stop, and trailing-stop-limit orders. Binance Spot supports market, limit, stop, stop-limit, pegged orders, and contingent order lists, while also expressing post-only behavior as a limit order with a specific execution instruction. Coinbase documents market, limit, stop-limit, IOC/FOK variants, and attached take-profit/stop-loss configurations. NASDAQ and Cboe-style equities venues go further into session-specific, cross, midpoint, reserve, routed, and pegged behaviors because their market structure is more fragmented and their users often need finer execution control.

How does Time-in-Force change an order's behavior?

A common misunderstanding is to think of order type and time in force as separate choices. Formally they are different, but in practical trading they work together to define what the order really is.

An order that rests until canceled behaves very differently from one that must execute now or disappear. In FIX, TimeInForce encodes this dimension: Day, IOC, FOK, GTC, GTD, and exchange-specific variants. The same limit price with a different time-in-force produces a meaningfully different instruction. A limit order with GTC is passive and patient. A limit order with IOC is aggressive but price-constrained: it takes what is immediately available at the limit price or better, then cancels the rest. A limit order with FOK is stricter still: either the entire size is available immediately within the limit, or nothing happens.

This is why venue-specific support matters. Some exchanges support only a few time-in-force options. Others add market-hours-only, system-hours, cross-session, or custom expiry behaviors. NASDAQ, for example, documents distinct handling for market-hours versus system-hours orders and special encodings for cross-related instructions. Bitstamp supports IOC, FOK, MOC, and GTD, with the caveat that GTD orders expire at midnight UTC. Those details sound operational, but they change execution outcomes.

When should you use advanced orders like post-only, pegged, or iceberg?

Advanced order types are best understood as tools for controlling one of three things: execution certainty, price discipline, or market footprint. Most specialized orders are some combination of those levers.

If you care most about execution certainty, you use orders that trade quickly: market, IOC, or in some cases FOK. If you care most about price discipline, you use limit, stop-limit, take-profit-limit, or pegged instructions that define acceptable price bounds. If you care about footprint, you use post-only, reserve, hidden, midpoint, or iceberg-style orders to control how visible your interest is and how it interacts with queue priority.

This is where supported order types start to separate casual trading from execution strategy. A long-term investor making occasional trades may need little beyond market and limit orders. A market maker, arbitrageur, or larger trader may depend on post-only orders to avoid taker fees, iceberg orders to reduce information leakage, or pegged orders to follow the inside market without constant manual repricing. The exchange’s product is useful to different users precisely because it lets them express different priorities in the same matching system.

In some exchange architectures, advanced order handling also interacts with custody and settlement design. For example, Cube Exchange uses a 2-of-3 Threshold Signature Scheme for decentralized settlement: the user, Cube Exchange, and an independent Guardian Network each hold one key share, no full private key is ever assembled in one place, and any two shares are required to authorize a settlement. That is not itself an order type, but it shows how execution features and settlement architecture can be separated: an exchange can offer sophisticated trading instructions while still designing settlement so that asset control is not concentrated in a single private key.

What are the trade-offs of using more advanced order types?

The benefit of broader order-type support is precision. The cost is that users must understand the conditions they are specifying and the edge cases that follow.

A stop-market order can protect against hesitation, but in a gapping market it may execute far from the trigger. A stop-limit order protects against runaway execution prices, but it may fail to fill when protection is needed most. A post-only order avoids taking liquidity, but it can be rejected rather than executed. A reserve order hides size, but the hidden portion may receive worse priority than displayed size. A pegged order adapts automatically, but only according to the venue’s peg rules, which may differ meaningfully across exchanges.

That is why “supported” matters as much as the order name itself. Two venues may both say they support a trailing stop, a midpoint order, or a post-only instruction, yet differ on trigger reference, session availability, allowed products, or rejection behavior. Even in standardized interfaces like FIX, the broad concepts are shared while specific implementations remain venue-dependent.

Conclusion

Supported order types are the exchange’s vocabulary for execution. They define how precisely a trader can express intent about price, time, visibility, and triggers; and therefore shape who the exchange is really built for.

The simplest way to remember it is this: an exchange is not just a place to trade an asset; it is a system for interpreting trading instructions. The richer and more carefully designed those instructions are, the more control traders have; but the more they need to understand the mechanics behind each choice.

Which order types should I know before trading?

Know the core order types you’ll use and where to set them on Cube. Key types to understand before trading are market, limit, stop-limit (stop + limit), IOC/FOK (time-in-force variants), post-only (maker-only), and pegged/iceberg variants for visibility control. On Cube, you pick the order type and any trigger/TIF fields in the market order ticket and submit directly from your funded account.

1. Fund your Cube account with fiat or a supported crypto transfer (for example, deposit USD via bank or USDC from an external wallet).
2. Open the market for the asset you want to trade and open the order ticket. Select the order type from the Order Type dropdown (Market, Limit, Stop-Limit, Post-Only, Pegged, Iceberg) and set Time-in-Force if applicable (GTC, IOC, FOK).
3. Enter the size and required pricing fields: a limit price for limit orders, stop and limit prices for stop-limit, and trail/delta for trailing stops; enable post-only or hidden/iceberg flags when you want maker or reduced visibility behavior.
4. Review the estimated fill, maker/taker fee indicator, and any fee rebates or execution constraints, then submit the order.