What is a Post-Only Order?

Introduction

Post-Only orders are a way to tell a market: I want to add liquidity, not take it. That sounds like a small instruction, but it solves a real problem. In an electronic order book, a normal limit order can behave in two different ways depending on the state of the market at the instant it arrives. It might rest on the book and wait for someone else to trade against it, or it might execute immediately against an existing order. Those are mechanically different outcomes, and on many venues they also have different fees, rebates, and strategic consequences.

That difference is why post-only exists. A trader may choose a price that looks passive when the order is sent, but by the time it reaches the matching engine the opposite side may have moved toward it. Without protection, an order meant to provide liquidity can arrive as an aggressive order and remove liquidity instead. Exchanges therefore offer a post-only instruction to make the trader’s intention explicit: either let the order rest as maker liquidity, or do not let it execute on entry.

The core idea is simple, but the details are not uniform across venues. Some exchanges reject or cancel a post-only order if it would trade immediately. Some reprice it so that it can still post without locking or crossing the market. Some apply special handling for midpoint or non-displayed orders. And in some equity venues, the exchange may even override the usual post-only behavior when immediately taking liquidity is economically at least as good as posting and later earning the maker economics. So the right way to understand post-only is not as a universal rule with one implementation, but as a family of venue-specific mechanisms built around a single invariant: the order is designed to avoid arriving as a taker unless the venue explicitly defines an exception.

How does a post-only order enforce maker intent in a limit order book?

A continuous limit order book has two kinds of activity. Resting orders sit on the book and advertise willingness to trade at a stated price. Incoming marketable orders interact with those resting orders and execute immediately. The first group supplies liquidity; the second consumes it. That distinction matters because it changes queue position, execution timing, and often fees.

A normal limit order does not guarantee which side of that line it will fall on. Suppose the best ask in a market is 100.05, and you send a buy limit at 100.00. If nothing changes before arrival, your order posts below the ask and becomes a resting bid. But if the best ask falls to 100.00 while the order is in transit, that same order is now marketable. The matching engine will typically execute it against the resting ask. You submitted a limit order, but you did not control whether it would post or take.

A post-only instruction changes that. It tells the venue that posting is not just a preference but a condition. If your buy at 100.00 would rest, fine. If it would execute immediately, the venue must do something else. What it does next depends on the venue’s rules: reject the order, cancel it, slide its displayed price away from the lock, or handle it under some more specialized logic.

That is the compression point for the whole topic: post-only is not mainly about price; it is about controlling your role at entry. Once that clicks, the rest of the details make sense. Fees matter because makers and takers are often charged differently. Queue position matters because a posted order can gain time priority. Market structure rules matter because a displayed order cannot always be allowed to lock or cross other protected quotes. But all of those are downstream of the same design goal.

Why use post-only orders; fees, queue position, and avoiding accidental taker fills

On many venues, the immediate reason to use post-only is fee control. Coinbase’s Exchange API states the point directly: if post_only is true, the order should only make liquidity, and if any part of the order would take liquidity, the order is rejected and no part executes. Bybit describes the same mechanism in trader-facing terms: post-only ensures the limit order is placed into the book, and if it would execute immediately, the system cancels it to avoid the higher taker fee. BitMEX’s ParticipateDoNotInitiate instruction does the same by canceling an order that would have executed on placement.

The fee motivation is real, but it is not the whole story. A posted order also acquires a place in the queue at its price. In a price-time priority book, that queue position is valuable because later orders at the same price stand behind earlier ones. For market makers and other passive strategies, the game is not just “get filled at this price” but “get filled while being early enough in the queue that the fill is likely to happen before the market moves away.” A post-only order protects that passive posture.

It also protects against a specific operational risk: latency. BitMEX explains post-only as protection against the far touch moving toward the order while it is in transit. That is exactly the problem. Between the client deciding to send the order and the matching engine processing it, the book may change. Without post-only, a trader who believes they are quoting passively can end up crossing the spread accidentally. With post-only, the venue either preserves the maker intent or refuses the order.

The consequence is that post-only is often most important when the spread is narrow, when latency matters, and when maker/taker economics are material enough that an unintended taker fill changes the trade’s expected value. That is why the feature appears so often in API-level order parameters and in exchange rulebooks aimed at professional participants.

Example: the same limit order placed with and without post-only

Imagine a market with a best bid of 49.98 and a best ask of 50.00. You want to buy at 50.00 only if you can join the book as a maker. From your perspective, that may seem contradictory: your price is equal to the ask, so whether the order posts or trades depends entirely on what the venue allows and what resting liquidity is present.

If you send an ordinary buy limit at 50.00, the order is marketable on arrival. The matching engine sees sell liquidity available at 50.00, so it executes immediately against that sell order, in whole or in part. You have bought at your limit or better, but you did it by taking liquidity.

If you send the same order as post-only on a venue like Coinbase, the engine checks whether any part of the order would take liquidity. If yes, the order is rejected and none of it executes. On a venue like BitMEX, the instruction is expressed differently (ParticipateDoNotInitiate) but the effect is similar: if it would execute on placement, it cancels instead.

Now consider a venue with price-sliding logic in equities. The same order might not simply disappear. If posting it at 50.00 would lock a displayed order or a protected quote, the venue may slide the displayed price one minimum price variation away so the order can rest without violating the venue’s constraints. Nasdaq states that if a Post-Only order would lock a resting displayed order on the book, the incoming order will either post one minimum price variation away from the locking price or be canceled, depending on the customer port setting. The order remains maker-intended, but the exact posted price is adjusted to preserve that status.

That example shows why “post-only” does not always mean “submit this exact visible price or reject.” On some venues it means “maintain maker-only behavior, even if the venue has to reprice within the rules of the market.”

Why do exchanges handle post-only orders differently?

The simplest implementation is common in crypto venues and API docs: if the order would take, reject or cancel it. Coinbase uses rejection. BitMEX uses cancellation on placement. Bybit describes automatic cancellation if the order would execute immediately. Kraken’s WebSocket API exposes a post flag for limit orders, identifying the order as post-only, though that specific page does not spell out the exact runtime behavior in the crossing case.

This simple version is easy to reason about because the invariant is strict. Either the order rests, or it never becomes active. There is no partial immediate execution, no venue-side repricing, and no ambiguity about the trader’s intention. It fits especially well in markets where there is no external protected quotation framework constraining displayed prices across venues in the way U.S. equities venues are constrained.

U.S. equity markets are more complicated because the exchange is not operating in isolation. If a displayed order would lock or cross a protected quote at another market center, the venue cannot simply ignore that fact. Nasdaq’s documentation makes this explicit: if a Post-Only order would lock or cross a protected quote of another market center, it will either be processed like a Price-to-Comply order (or Price to Display if attributable) or be canceled, depending on customer port settings. In other words, the venue can preserve the maker intent by repricing the order into a compliant displayed form rather than just discarding it.

This is the market-structure reason post-only acquired so much complexity in equities. The SEC’s memo on maker-taker fees describes post-only and related order types as mechanisms developed so professional traders can quote aggressively, avoid taking liquidity, and avoid locking the market while still pursuing maker economics. Once those goals coexist, the venue needs machinery to decide when to cancel, when to slide, when to display at one price but rank at another, and how to interact with hidden or midpoint liquidity.

So the implementation differences are not arbitrary. They come from the surrounding constraints of the market. In a simpler venue, post-only can be a binary maker-only gate. In a fragmented equities venue, it often becomes part of a broader repricing system.

What happens when a post-only order would lock or cross the market?

A post-only order becomes interesting precisely when it would not simply rest harmlessly inside the spread. The hard case is when it would lock or cross existing liquidity.

A locking order is priced equal to the best contra quotation. A crossing order is more aggressive than the best contra quotation. If a buy order arrives at a price equal to the best displayed sell, it locks; if it arrives above that best displayed sell, it crosses. On a simple crypto venue with strict maker-only logic, both situations usually produce the same answer: reject or cancel, because the order would take liquidity.

On Nasdaq, the behavior depends on what is being locked or crossed. If the order would lock a resting displayed order on the book, the incoming Post-Only order either posts one minimum price variation away or is canceled, depending on customer port settings. If it would lock a resting non-displayed order, however, Nasdaq says the incoming order will post and display at the locking price while the non-displayed order remains posted at that same price. That is a very different result, and it shows that “post-only” does not mean there can never be an internal locked state involving hidden interest; it means the displayed incoming order is treated under a special set of rules to preserve posting behavior.

That distinction surprises many readers the first time they see it. The intuitive but incomplete model is: “post-only means no immediate interaction with opposite-side liquidity.” The more accurate model is: post-only governs how the incoming order behaves at entry, but the venue may separately decide how to represent or preserve hidden contra liquidity. Hidden orders, midpoint orders, and trade-now style instructions make the engine’s choices more complicated than the phrase “maker-only” suggests.

How do midpoint and hidden (non‑displayed) orders affect post-only handling?

Midpoint and hidden liquidity expose where the concept starts to break away from the simple retail mental model. If all orders were displayed limit orders at a single price ladder, post-only would be easy. But many venues also allow orders that rest non-displayed or reference the midpoint of the best bid and offer.

Nasdaq’s factsheet gives a good example. If a Post-Only order would lock or cross a resting midpoint order and the price difference is less than the “forgone net rebate,” the Post-Only order will post and display at the locking or crossing price. The midpoint order is then either canceled or updated depending on the entry protocol: canceled if entered over OUCH or Flite, updated if entered over FIX, RASHport, or QIX. That is a highly venue-specific rule, but the reason it exists is general: once the contra order is not a simple displayed quote, the exchange may compare the economic value of posting versus executing and then choose the path that best fits its fee and display logic.

IEX’s proposed Post Only rule reaches a similar place by a different route. Its filing says a Post Only order would not remove liquidity from the IEX order book on entry except when the value of removing liquidity equals or exceeds the value of posting and later providing liquidity, including fees and rebates; the filing’s “Sum of Fees” test. By default the order is also subject to display-price sliding, though a member may instead instruct cancellation of untraded quantity. Again, the implementation is more sophisticated than “always reject if marketable.” The venue is asking a more refined question: is there any economic reason, given this fee schedule and this contra interest, to allow immediate removal anyway?

This is where a smart reader can get tripped up. The words “post-only” suggest an absolute prohibition. In some venues that is close to true. In others, especially equities, the term names a default intention wrapped in exceptions defined by the venue’s matching and fee rules. The stable idea is not “never executes on entry under any circumstances.” The stable idea is “the order is designed to preserve passive liquidity provision unless the venue’s rules explicitly define a reason not to.”

How do fees and rebates influence post-only order behavior?

Post-only only makes full sense once maker-taker pricing is in view. If being a maker and being a taker had identical economics, there would still be reasons to want queue position or passive execution, but the demand for a dedicated maker-only instruction would be weaker. The SEC’s memo makes this plain: post-only and related order types developed largely to let traders capture maker rebates and avoid taking fees while also complying with locked-market constraints.

That does not mean post-only is just a fee trick. It means fees sharpen the difference between two execution paths that were already strategically distinct. If a posted order later trades, it may earn a rebate or incur a lower fee. If it removes liquidity immediately, it may pay more. Coinbase states the practical rule simply: market orders are always takers and incur taker fees; post-only exists to force the opposite role for a limit order.

Some venues make the fee comparison part of the matching logic itself. Nasdaq refers to a threshold based on the “forgone net rebate” when determining whether post-only logic applies in certain crossing situations. Its factsheet says that if a Post-Only order would cross another order already on the book such that the price difference is greater than the forgone net rebate, Post-Only logic does not apply and the order is processed as an Immediate-or-Cancel at the best price. IEX similarly uses a value comparison to decide when removing liquidity is at least as good as posting and later providing it.

The important conceptual point is this: fees do not merely reward passive behavior after the fact; on some venues they actively shape the order-handling rule itself. That is why post-only sits at the boundary between trading strategy and market structure.

Which order types and time‑in‑force settings are incompatible with post-only?

Because post-only is about posting rather than immediate execution, it naturally conflicts with some other instructions. Coinbase’s API says post_only is invalid when time_in_force is IOC or FOK. That makes sense from first principles. An IOC order says “execute immediately, cancel the rest.” A post-only order says “do not execute immediately; post instead.” Those instructions pull in opposite directions. FOK is even less compatible because it requires immediate complete execution.

Kraken’s API likewise identifies the post flag as available only on limit orders. That too follows directly from the mechanism. A market order is, by design, an order to trade immediately with the best available contra liquidity. There is nothing to “post” in the post-only sense.

Venue rulebooks often add further restrictions. Nasdaq says Post-Only orders must be entered as displayed limit orders, and cross orders marked Post-Only are rejected. IEX’s proposed rule limits Post Only to displayed, non-routable limit or discretionary limit orders, imposes time-in-force constraints, and says the instruction is not operative for securities priced below $1.00 per share. These are not arbitrary housekeeping details. They mark the boundary beyond which the venue can no longer reliably preserve the logic of a posted, passive, visible order.

Common misconceptions about post-only orders

The most common misunderstanding is thinking post-only guarantees a fill that will be treated as maker. What it actually guarantees is narrower: it tries to guarantee the order arrives as non-taking interest. If the order is canceled because it would take liquidity, then there is no execution at all. The trader may miss the trade entirely.

The second misunderstanding is thinking all venues enforce post-only by the same method. They do not. Some reject. Some cancel. Some slide the price. Some compare fee economics. Some have special handling for hidden or midpoint orders. In equities venues, the exact result may even depend on the protocol or port settings used to submit the order. Nasdaq says several outcomes (cancel versus post-away-from-lock, for example) depend on customer port settings, and its midpoint handling differs by protocol.

The third misunderstanding is thinking post-only is purely a user convenience feature. It is partly that, but it is also a response to the structure of modern electronic markets. The SEC memo argues that specialized order types like post-only emerged because exchanges needed ways to let liquidity providers quote aggressively, earn maker rebates, and avoid locking markets under Rule 610. That background matters because it explains why the rules sometimes look more intricate than the plain-language label suggests.

Limitations of post-only orders and when they fail

Post-only works cleanly only if the venue can draw a crisp line between “would take now” and “would rest now.” In practice, that line can blur because of hidden liquidity, midpoint reference prices, self-trade prevention rules, protocol-specific handling, and race conditions in fast markets.

There is also a deeper limitation. Post-only controls entry behavior, not execution quality in a broader sense. A posted order can still sit unfilled while the market runs away. It can lose queue position if canceled and resubmitted. It can be repriced by venue logic in ways that preserve maker status but change the visible quote. So the instruction solves the problem “do not let me become a taker on arrival,” but it does not solve the broader problem “get the trade I want on good terms.” Sometimes those goals conflict.

And the economic rationale depends on assumptions that may not hold everywhere. If maker-taker differentials are small, or if queue position matters less than certainty of execution, then the benefit of post-only shrinks. Conversely, when rebates and taker fees strongly affect expected value, the instruction becomes central to strategy design.

Conclusion

A post-only order is best understood as a limit order with a protected intention: join the book as liquidity, or do not trade on entry.

Everything else is the venue-specific machinery used to honor that intention inside a real market.

• cancelation
• rejection
• price-sliding
• midpoint exceptions
• fee tests

The memorable version is simple. A normal limit order controls your price. A post-only order tries to control your role. It exists because in electronic markets, those are not the same thing.

How do you place a post-only order?

Place a post-only limit order when you want to add liquidity without risking an immediate taker fill. On Cube, you set a limit price and enable the post-only flag so the engine only posts your order to the book; if it would execute on entry the order is not allowed to take liquidity. Use a limit order (not market) and a non-immediate time-in-force so the post-only instruction can operate.

1. Fund your Cube account with fiat or a supported crypto transfer.
2. Open the market for the asset pair you want and choose a limit order.
3. Enter your limit price, enable the post-only option, and set a non‑immediate time‑in‑force (e.g., GTC).
4. Review the estimated fees and queue implications, then submit the order.