Post-Only Orders: Why the Venue Rejects Them

One instruction, three implementations

A post-only order is easiest to understand as a promise the venue makes to the rest of the book: this order will not remove liquidity. The price is still a limit price, the quantity is still a quantity, but the order is allowed to exist only in the state where it rests.

That promise has to be enforced at one moment — when the order reaches the matching engine and the engine asks whether it can execute against the opposite side. If the answer is yes, the order cannot be both post-only and filled. Something has to give.

The three large venues in this guide give different answers to that question, and the difference is not cosmetic. Binance treats post-only as a distinct order type and rejects a marketable one. Coinbase attaches a boolean to a limit order configuration and rejects a marketable one. OKX accepts the order, then cancels it. A trading loop that assumes one behaviour will mis-handle the other two.

What Binance means by LIMIT_MAKER

Binance’s Spot API lists LIMIT_MAKER among its order types. The documentation defines it in one sentence: it is “a LIMIT order that will be rejected if the order immediately matches and trades as a taker,” and adds that this “is also known as a POST-ONLY order.”

Two details follow from that wording.

First, the rejection is a property of the order type, not of a separate flag. You do not send a normal limit order with a post-only boolean. You send type=LIMIT_MAKER, and the venue knows before it touches the book that the order may not take.

Second, the test is “immediately matches.” A post-only order is not forbidden from filling later. It is forbidden from filling on arrival. Once it rests, it is an ordinary maker order and can be hit by anyone who chooses to trade against it.

Binance’s documentation does not print a dedicated error code for this rejection on the trading-endpoint page. The practical consequence is still clear: the order is not accepted, so there is no live order to cancel and no fill to reconcile. A client that treats “no order id in the response” as a transport failure and retries immediately will send the same marketable order again and receive the same rejection.

What Coinbase means by post_only

Coinbase’s Advanced Trade API takes the other shape. post_only is a boolean inside a limit order configuration, documented on limit_limit_gtc and limit_limit_gtd. The field description is explicit: “Enable or disable Post-only Mode.” When enabled, “only Maker Orders will be posted to the Order Book,” and “Orders that will be posted as a Taker Order will be rejected.”

The behavioural promise is the same as Binance’s. The implementation differs in two ways that matter to a client.

• The post-only instruction travels inside a named configuration object. A request that puts post_only at the top level, or inside a market order configuration, is not the documented shape.
• The rejection is again a rejection, not a cancellation. Coinbase’s docs describe an order that would be a taker as rejected, which means the order never becomes a live order.

For a client that already builds Coinbase order payloads, the risk is the nesting. A post-only flag placed in the wrong object can be ignored by a permissive validator, and the order then executes as an ordinary taker limit order. The cost difference is exactly the maker-taker spread, which is why the flag was there.

What OKX means by post_only

OKX also exposes post-only as an order type, ordType=post_only, and its definition starts the same way: “Post-only order, which the order can only provide liquidity to the market and be a maker.”

The next sentence is where it diverges. OKX says: “If the order would have executed on placement, it will be canceled instead.”

That is a different lifecycle. Binance and Coinbase refuse the order. OKX accepts it and then removes it. In an API response, an accepted-then-cancelled order can carry an order identifier, and a client that only checks whether an identifier came back may conclude that the order is live when it is already dead.

OKX’s documentation also uses post_only as an instrument state, not only as an order type. In that context, a pair in the post_only state accepts only post-only orders; market, IOC, FOK and normal limit orders are rejected. The two uses of the same string are worth keeping apart when reading an error: one describes what you sent, the other describes what the instrument currently allows.

Why the order was marketable in the first place

The rejection is not random, and it is not usually a venue fault. It means the price you named was already executable against the opposite side of the book at the moment the engine saw it.

The common causes are mechanical:

1. You placed at the touch. A buy at the best ask is a taker order by definition. A sell at the best bid is the same on the other side. Post-only at the touch is a contradiction unless the book is one tick wide and you are joining the correct side.
2. You placed through the touch. A buy above the best ask is worse than taking; it is a marketable limit order with a price ceiling. A post-only flag does not make it patient.
3. The book moved between your snapshot and the engine. You read the best ask at 100.10, sent a buy at 100.10, and by the time the order arrived the ask had fallen to 100.09. Your order was marketable against the new book even though it was not marketable against the old one.
4. The book was crossed or locked. A temporary cross between venues, or a stale quote on one side, can make a passive-looking price aggressive against the current book.

Only the first two are fully under your control; the third is latency and the fourth is market structure.

The price that survives

The safe rule is arithmetic rather than folklore. For a buy, the limit price must be strictly below the best ask. For a sell, it must be strictly above the best bid. If you want to join the queue rather than improve it, the buy goes at the best bid and the sell at the best ask — but only when those prices are not already marketable.

There is a second constraint that is easy to miss on a thin book: the distance has to survive the round trip to the engine. A buy one tick below the ask survives a one-tick move in your favour. A buy one tick below the ask does not survive an ask that falls two ticks before your order lands. The faster the market and the slower your connection, the more margin you need between your price and the touch.

That is why post-only strategies often quote several ticks away rather than at the touch. The order is less likely to fill, but when it does it is unambiguously a maker order.

What post-only does not change

Post-only is often described as a way to guarantee the maker fee. That is half true, and the half that is false causes trouble.

If the order is accepted and later fills, the fill is a maker fill. But a post-only order that is rejected or cancelled never fills, so it never earns or pays anything. The maker rate is a property of the fills you get, not of the order type you sent.

Post-only also does not change queue priority. An order that joins the best bid sits behind every order already at that price; improving the price buys priority but moves you closer to the rejection boundary. That trade-off is the same one described in maker versus taker orders.

A LIMIT_MAKER order on Binance has no separate time-in-force that changes the outcome; it either rests or is rejected. For GTC, IOC and FOK on ordinary limit orders, see Binance time in force.

Retry logic that does not make things worse

The rejection is a normal state, not an exception. A client that treats it as a transport error and retries the identical request will produce a tight loop of identical rejections, and on OKX it may produce a sequence of accepted-then-cancelled orders that clutter the order history.

A safer loop does three things.

1. Classify the response before retrying. A rejection is a decision about price. A timeout is an unknown. A rate-limit error is a decision about pace. Only the timeout should be retried with the same parameters, and even then only after querying by client order id.
2. Move the price away from the touch on rejection. Re-sending the same price against a moving book is a bet that the book will move back. If the strategy wants to rest, it should widen the distance, not repeat the request.
3. Log the book state at the moment of rejection. Best bid, best ask, and the timestamp of the snapshot are enough to tell whether the cause was your price or the book’s movement. Without that record, every rejection looks like a venue fault.

The same discipline applies to the other order shapes that split size or time. An iceberg or post-only TWAP can generate many post-only children, and a rejection in the middle of a slice changes the size that actually rests. The parent order has to know which children survived, not just how many were sent.

When post-only is the wrong tool

Post-only is the right instruction when the strategy’s edge depends on being a maker: a fee rebate, a queue position, or a spread capture that only works if the order does not cross. It is the wrong instruction when the goal is to be filled.

A trader who needs to exit a position should not send a post-only order and hope. The order may be rejected repeatedly while the market moves away, and the position remains open. A marketable limit order or a market order is the honest instruction for an exit; the taker fee is the cost of certainty.

The same logic applies to stop losses. A stop converted into a post-only limit can fail to fill during a fast move, which is the moment the stop was supposed to work. See stop-limit versus stop-market orders.

A checklist before sending a post-only order

• Confirm the venue’s shape: Binance order type LIMIT_MAKER, Coinbase boolean on a limit configuration, OKX order type post_only.
• For a buy, set the price strictly below the best ask; for a sell, strictly above the best bid.
• Leave enough distance that the book cannot move into your price before the order reaches the engine.
• Decide in advance what a rejection means for the strategy: widen, wait, or abandon.
• Do not retry a rejection with the same price and no new book snapshot.
• On OKX, check the order state after acceptance; an accepted post-only order can already be cancelled.
• Reconcile fees from the fill record, not from the order type. A rejected post-only order has no fill and no fee.

Sources and what they support

• Binance Spot API, Trading endpoints — defines LIMIT_MAKER as a limit order “rejected if the order immediately matches and trades as a taker,” and states that it is also known as a post-only order. Read 2026-11-03.
• Coinbase Advanced Trade API, Create order — defines post_only on limit order configurations, states that only maker orders will be posted, and that orders which would post as a taker are rejected. Read 2026-11-03.
• OKX API v5, Place order — defines ordType=post_only and states that an order which would execute on placement “will be canceled instead.” Read 2026-11-03.

Risk note. The order-type behaviour described here was read from each venue’s API documentation on 2026-11-03. Venues change error handling and order semantics without notice, and a production trading client should verify the response it actually receives. Nothing here is investment advice.