Crypto Exchange Order Types: Which Ones Your Platform Needs

Table of Contents

• Why Order Types Are a Product Decision
• The Core Four: Market, Limit, Stop-Loss and Stop-Limit
• Time-in-Force: GTC, GTD, IOC and FOK
• Advanced Order Types: Take-Profit, Trailing Stop and OCO
• Maker Tools: Post-Only, Iceberg and Hidden Orders
• Execution Algorithms and Derivatives-Only Orders
• Where Each Order Type Lives in the Engine
• Risk and Abuse Considerations
• Which Order Types to Ship at Each Stage
• Exposing Order Types Through the API and the Order Ticket
• Frequently Asked Questions
• Bottom Line and Next Steps

Why Order Types Are a Product Decision

Ask ten founders which crypto exchange order types their platform should support and most will answer “all of them.” That answer costs money. Every order type you add is a feature to build, a code path in the matching engine to test, a UI control to explain, an API field to document and a new way for a trader to lose money and blame you.

The better question is which traders you want and what each of them needs to execute their strategy. Retail spot traders need four or five order types. Active swing traders want conditional exits. Market makers will not quote on your book without post-only. Institutional desks expect execution algorithms and will test your self-trade prevention before they fund an account.

This guide is a set of order types explained for exchange operators rather than traders. For each type we cover what it does, who uses it, where it sits inside the engine, and what can go wrong. It ends with a tiered recommendation so you can decide what to ship now and what to defer.

The Core Four: Market, Limit, Stop-Loss and Stop-Limit

These four cover the overwhelming majority of retail volume on any spot trading exchange. If you ship nothing else at launch, ship these well.

Market order

A market order buys or sells immediately at the best available prices until the full quantity is filled. The trader gets certainty of execution and gives up certainty of price. On a thin book a large market order walks through several price levels and the average fill can be far from the last traded price.

Operators should enforce a maximum slippage guard on market orders. A common pattern is to convert the market order into a limit order at the best price plus a configurable band (for example 5 percent) and cancel any remainder. This protects traders from a single fat-finger that empties your book and prints a chart candle you will be explaining in support tickets for days.

Limit order

A limit order rests in the book at a chosen price and executes only at that price or better. It is the building block of the order book itself. Every unit of visible depth is a resting limit order, so the share of limit orders in your flow is a direct measure of how much liquidity your users are providing.

Limit orders are also the simplest case for the engine: validate, insert into the price level, match on arrival if the price crosses the spread, otherwise rest. Fee logic usually rewards them with a lower maker fee when they rest and charges the taker fee when they execute on arrival.

Stop-loss order

A stop-loss is a dormant instruction: when the market trades through a trigger price, submit a market order. Traders use it to cap downside without watching the screen. For the operator the important detail is that a stop-loss is not in the order book. It lives in a separate trigger watcher that monitors a reference price, usually last trade or mark price, and only then sends a market order to the engine.

Because the resulting order is a market order, stop-losses suffer the same slippage problem described above, magnified by the fact that many stops cluster at obvious levels and fire together.

Stop-limit order

A stop-limit fixes the slippage problem at the cost of execution certainty. When the trigger price is hit, the watcher submits a limit order at a specified limit price instead of a market order. If the market gaps through the limit price the order rests unfilled, which is sometimes exactly what the trader wants and sometimes the reason their account was not protected.

Offer both. Traders who understand the difference will choose deliberately, and your support team will have a clear answer for those who did not.

Time-in-Force: GTC, GTD, IOC and FOK

Time-in-force is not an order type but a modifier on limit orders that decides how long the order may live. It matters because bots and institutions rely on it heavily and because each option changes the engine’s behavior.

Time-in-force	Meaning	Rests in book?	Typical user
GTC (good till cancelled)	Live until filled or cancelled	Yes	Everyone; the default
GTD (good till date)	Live until a timestamp	Yes, until expiry	Swing traders, bots
IOC (immediate or cancel)	Fill what you can now, cancel the rest	Never	Takers, arbitrage bots
FOK (fill or kill)	Fill the entire quantity now or cancel all	Never	Block traders, OTC-style flow

IOC and FOK are cheap to implement because they are pure matching-engine logic with no persistence. GTD needs an expiry scheduler that cancels orders reliably even across engine restarts. If your engine persists its order book through a write-ahead log, expiry times must be part of that log or orders will outlive their intended lifetime after a recovery.

Advanced Order Types: Take-Profit, Trailing Stop and OCO

Once the trigger watcher exists for stop orders, several advanced order types crypto platform users ask for become small increments rather than new systems.

Take-profit

A take-profit is the mirror image of a stop-loss: trigger when price moves favorably past a level, then submit a market or limit order to close. Mechanically it is the same watcher with the comparison reversed.

Trailing stop

A trailing stop follows the market by a fixed distance or percentage. If the price rises, the stop rises with it; if the price falls, the stop stays put and eventually triggers. The watcher must now track a high-water mark per order and recompute the trigger on every reference price update, which is more work per tick than a static stop. Most platforms limit the number of trailing stops per user or per market to keep the watcher predictable under load.

OCO (one-cancels-the-other)

An OCO pairs two orders, typically a take-profit limit above the market and a stop-loss below, and cancels the survivor when either executes. Traders use it to bracket a position in one action. For the engine, OCO introduces linked-order state: a fill or cancel on one leg must atomically cancel the other, including under partial fills and across a restart. Get this wrong and a trader ends up with both legs executed, which means an unintended position and a refund conversation.

Limit, market, stop and OCO orders on an exchange are now the baseline expectation of any trader who has used a top-ten venue. Shipping them is less about differentiation and more about not disqualifying yourself.

Maker Tools: Post-Only, Iceberg and Hidden Orders

Post-only and iceberg orders exist for the participants who supply your depth. If you want external market makers or serious algorithmic traders on your book, these are not optional.

Post-only

Post-only guarantees that the order will rest as a maker. If any part would execute immediately against the book, the engine rejects (or, on some venues, reprices) the order instead of filling it. Market makers use it because their entire economics depend on earning the maker rebate and never paying taker fees by accident. Implementation is a single check at insertion time, but the behavior must be documented precisely because bots will encode it.

Iceberg

An iceberg order shows only a small visible slice in the book while the remaining quantity stays hidden. Each time the visible slice fills, the engine replenishes it from the hidden reserve, usually re-timestamping it to the back of the queue. Large traders use icebergs to avoid signaling size. The engine must handle the replenishment inside the matching loop so that depth snapshots and trade feeds stay consistent.

Hidden orders

A fully hidden order has no visible quantity at all and typically ranks behind visible orders at the same price. Few mid-sized exchanges need these, and they complicate the fairness story you tell regulators. Treat them as an institutional-tier feature, if at all.

Execution Algorithms and Derivatives-Only Orders

TWAP and other algorithmic orders

A time-weighted average price order splits a large parent order into child orders submitted at regular intervals over a window. It is an execution algorithm rather than a book primitive, so it belongs in a separate algo service that talks to the engine through the same order API everyone else uses. This matters architecturally: the matching engine should never know a TWAP exists. Keeping algorithms outside the engine keeps the engine simple and lets you add VWAP or percentage-of-volume later without touching matching code.

Reduce-only

Reduce-only is specific to margin and perpetual futures. It tags an order so that it can only decrease the size of an existing position. If a fill would flip the position or open a new one, the engine trims or rejects the order. Traders use it when closing in volatile markets so a stale close order cannot accidentally open a position in the opposite direction. On a perpetual futures platform it is standard, and the risk engine depends on it to reason about exposure.

Conditional and trigger orders on derivatives

Derivatives venues usually trigger conditional orders on the mark price rather than the last trade price to make stop hunting through a single thin print harder. Your margin trading module needs the same choice: which reference price fires a trigger, and is that choice visible to the trader at order entry. Document it and keep it consistent across spot, margin and futures, or offer it as an explicit option.

Where Each Order Type Lives in the Engine

Operators often assume every order type is “in the matching engine.” Most are not. Knowing which component owns each type shapes your architecture, your testing and your failure modes. The matching engine architecture guide covers the price-time priority core in depth; here is how order types map onto it.

Order type	Component	Notes
Market, limit	Matching engine	Core book primitives
IOC, FOK, post-only	Matching engine	Insertion-time rules, no persistence
GTD	Engine plus expiry scheduler	Expiry must survive restart
Stop-loss, stop-limit, take-profit	Trigger watcher	Submits an order when reference price crosses
Trailing stop	Trigger watcher	Per-order high-water mark
OCO	Trigger watcher plus linked-order state	Atomic cancel of the sibling leg
Iceberg, hidden	Matching engine	Replenishment inside the matching loop
TWAP, VWAP	Algo service	External client of the order API
Reduce-only	Engine plus risk engine	Position-aware validation

The practical consequence is that your trigger watcher is a second critical system. It needs the same durability as the book, a clear source of truth for the reference price, and defined behavior when the price feed stalls. A watcher that silently stops evaluating during a feed outage is how traders discover their stop never fired.

Risk and Abuse Considerations

Order types are also attack surface. A few patterns deserve explicit design decisions before launch.

• Stop hunting. Large participants can push price through clustered stop levels on a thin book, fire a cascade of market orders, and buy the resulting dip. Mitigations include triggering on mark or index price, requiring a minimum trade size or duration to count as a trigger, and your market manipulation detection layer flagging the pattern.
• Self-trade prevention. Bots with multiple keys, or a single account with resting orders on both sides, can match against themselves. Institutions will ask what your self-trade prevention mode is: cancel newest, cancel oldest, cancel both or decrement and cancel. Wash trading through self-matches also inflates your reported volume, which regulators notice.
• Slippage on market and stop orders. Covered above; the slippage guard is the fix.
• OCO and linked-order edge cases. Partial fills, restarts and cancellations mid-match are where linked orders break. Test them deliberately.
• Iceberg replenishment timing. If replenishment keeps the original timestamp, the iceberg jumps the queue and makers will complain, rightly.
• Trigger watcher load. Thousands of trailing stops recomputing on every tick in a volatile market can lag the watcher. Rate-limit evaluation and cap per-user conditional orders.

Each of these is cheaper to decide on paper than to retrofit after an incident.

Which Order Types to Ship at Each Stage

The right answer depends on who is trading. A tiered rollout keeps scope tight without disqualifying the platform later.

Tier	Order types	Who it serves
MVP	Market, limit, stop-loss, stop-limit; GTC and IOC	Retail spot traders
Growth	Add take-profit, OCO, trailing stop, post-only, GTD, FOK; reduce-only if offering margin or futures	Active traders, basic bots, first market makers
Institutional	Add iceberg, hidden, TWAP/VWAP, self-trade prevention modes, mark-price triggers	Professional makers, funds, OTC-style flow

A platform built on Codono’s exchange software ships the MVP and growth tiers out of the box across spot, margin and futures, with the trigger watcher and linked-order state already in place, so the institutional tier is an extension rather than a rebuild. Whatever stack you choose, make sure the order model and the engine support the next tier before you commit, because retrofitting linked orders or reduce-only into an engine that never planned for them is painful.

Pre-launch checklist for the order types you do ship:

• Each order type has written semantics for partial fills, cancels and restarts
• Market orders carry a slippage guard
• Trigger reference price (last, mark, index) is defined and shown to traders
• Trigger watcher has defined behavior during price-feed outages
• OCO sibling cancellation is atomic and tested under partial fills
• Post-only rejection behavior is documented for API users
• Iceberg replenishment re-timestamps to the back of the queue
• Self-trade prevention mode is chosen and configurable per account
• Reduce-only validation is enforced in the engine, not only in the UI
• Every type is covered in the API docs with example payloads

Exposing Order Types Through the API and the Order Ticket

Order types are only useful if traders can find them and bots can rely on them. Two surfaces matter.

The API

Your trading API should express order type, time-in-force and flags such as post-only and reduce-only as separate, orthogonal fields rather than one combined enum. Bots built for larger venues expect this shape and will integrate faster. Return explicit rejection reasons: “post-only would cross” is actionable, “invalid order” is a support ticket. Our guide on API and trading bot integration covers rate limits, idempotency and WebSocket order updates that go with this.

The order ticket

The order ticket in your web and mobile UI should hide complexity by default and reveal it on demand. Show market and limit as tabs, put stop and conditional types behind an “Advanced” toggle, and expose time-in-force and post-only as small controls near the submit button. Every conditional order needs a plain-language preview before submission: “When BTC/USDT last price falls to 60,000, sell 0.5 BTC at market.” Traders who read that line make fewer mistakes, and fewer mistakes mean fewer chargeback-style disputes. The UX and conversion guide covers the broader order-ticket design patterns.

Pair the ticket with interactive charts that let traders drag stop and take-profit levels directly on the price pane. Chart-based order entry is now the expectation for anyone coming from a derivatives venue.

Finally, if you are courting professional flow, read what institutional clients expect before you decide the institutional tier is optional. Their onboarding questionnaire will include order types, self-trade prevention and trigger semantics.

Frequently Asked Questions

Which order types does a new crypto exchange need at launch?

Market, limit, stop-loss and stop-limit cover the large majority of retail flow, with GTC and IOC time-in-force behind them. Take-profit and OCO are cheap to add once a trigger service exists. Everything else can wait until you have the traders who ask for it.

Do stop orders sit in the order book?

No. A stop order is a conditional instruction held by a trigger watcher outside the book. When the reference price crosses the stop price, the watcher submits a market or limit order to the matching engine. Until then it is invisible to other participants and does not affect depth.

What is the difference between post-only and IOC?

Post-only rejects the order if any part of it would execute immediately, guaranteeing maker status. Immediate-or-cancel does the opposite: it executes whatever can fill right now and cancels the rest, so it never rests in the book. Market makers use post-only; takers and bots use IOC.

Why do perpetual futures exchanges offer reduce-only orders?

Reduce-only guarantees an order can only shrink an existing position, never flip it or open a new one. It protects traders closing positions in fast markets and simplifies the liquidation and risk logic because the engine knows the order cannot increase exposure.

Bottom Line and Next Steps

Crypto exchange order types are not a checklist to maximize. They are a statement about which traders you are building for and how much engine complexity you are willing to own. Ship the core four and the basic time-in-force options with real care, add conditional and maker tools once the trigger watcher exists, and treat algorithmic and hidden orders as an institutional investment you make when the flow justifies it.

Whatever tier you target, decide the semantics on paper first: reference prices, partial-fill behavior, restart recovery and self-trade handling. Those decisions are the difference between an order type that earns trust and one that generates incidents.

Want to see the full order model running? Request a demo or explore Codono’s exchange software to see spot, margin and futures order types working on one engine.

---

The Codono Team has been building crypto exchange infrastructure since 2017. This guide reflects production experience across 250+ exchanges and the order-handling questions operators ask most.