Skip to content
Financial Context Wiki

Post-only order

A post-only order is a venue-specific limit-order instruction intended to rest rather than immediately take liquidity; rejection, cancellation, repricing, queue priority and fees depend on the exact matching rules.

Updated

For educational purposes only; not investment advice. Orders, fees and fills can change before cancellation or final reconciliation.

Direct answer

A post-only or add-liquidity-only instruction is attached to a limit order and tested when that order reaches the matching engine. If any part would immediately execute against resting liquidity, the venue follows its own rule: it may reject the request, accept and cancel the order, or move its price to a non-marketable level. Post-only therefore expresses an entry condition, not a universal order type with one outcome.

An order that successfully rests can later trade when an opposing order arrives. That fill is commonly classified as maker liquidity, but the actual fill record and fee ledger control. An acknowledgement, an open status or a post-only flag alone does not guarantee execution, maker treatment, a rebate or a better net result.

How it works

Marketability is evaluated from the engine’s state, not a stale screen. A buy limit at or above the best ask and a sell limit at or below the best bid normally cross the book. Tick rounding, auctions, locked or crossed books, hidden liquidity, price protection and self-trade prevention can alter the result. Automatic repricing also changes the requested limit and queue position, so it must be an explicitly accepted venue rule.

Post-only is independent of other instructions. GTC, GTD, IOC and FOK govern time in force; some venues reject post-only with immediate-execution instructions. reduce-only, close-only and position-side fields govern exposure. A stop or take-profit order may not enter the book until triggered, and the converted child order is then checked under the venue’s current post-only rules.

Queue and lifecycle semantics are equally specific. Price-time priority is common but not universal. A price change, size increase or cancel-and-replace often loses priority; a supported size reduction may retain it. Self-trade prevention can cancel or reduce the incoming order, the resting order or both. Only ordered public and private events establish what actually happened.

Use this workflow:

  1. Pin the venue, legal entity, product, session and API version; record tick, lot, minimum notional, fee tier and whether marketable post-only orders are rejected, canceled or repriced.
  2. Capture a timestamped, sequence-consistent best bid, best ask and depth view; specify side, limit, size, time in force, position mode, post-only, reduce-only, self-trade prevention and trigger fields.
  3. Round price and size exactly and precheck crossing, price bands, balances, margin, order caps and incompatible modes, while treating engine-arrival state as authoritative.
  4. Submit with a unique client order ID; keep transport success separate from accepted, resting or terminal status, and record the server order ID, timestamp and full response.
  5. Consume ordered order and fill events; reconcile cumulative fill, remaining quantity, fill ID, price, notional, liquidity flag, fee or rebate currency, and any queue-changing amendment.
  6. Treat amend, cancel and replace as races until terminal events arrive; retry idempotently after timeouts and resynchronize after duplicate, missing or out-of-order messages.
  7. Reconcile filled, canceled, rejected or expired quantity with inventory, holds and balances, then evaluate actual fees, rebates, adverse selection and missed fills; for an onchain venue, separately verify inclusion, protocol execution and required finality.

Examples

  • Crossing behavior. The best bid and ask are 99.90 / 100.00, and the tick is 0.01. A post-only buy for 2 BTC at 100.00 would immediately meet the ask. A reject-style venue rejects the request; a cancel-style venue records no fill and cancels it. A reprice-style venue could move it to 99.99, but only if that documented behavior was requested. A buy at 99.99 may rest if the engine state is unchanged; it is not guaranteed to fill.
  • Resting maker fill and fees. A sell for 3 ETH at 99.90 rests while the bid and ask are 99.80 / 100.00, then an aggressive buy fills it. Notional is 3 x 99.90 = 299.70. With maker rate -1 bp, the fee is 299.70 x -0.0001 = -0.02997, a rebate. Misclassifying it at a 5 bp taker rate produces a 0.14985 charge, a 0.17982 difference. Use the actual liquidity flag and fee record.
  • Partial fill and cancellation race. A resting post-only sell is 10 units at 100. It fills 4, then the client sends cancel. Before terminal cancellation another 1 fills, leaving 5 canceled. Total filled quantity is 5, not 4; filled notional is 500, and a 2 bp rebate is 0.10. A cancel acknowledgement is not the terminal inventory record.
  • Lower fees can still cost more. Buying 10 immediately at 100.00 with an 8 bp taker fee costs 1,000.80. Missing that price and later resting at 100.20 with a 2 bp maker fee costs 1,002.2004. The maker route saves 0.5996 in fees but costs 1.4004 more overall. Post-only manages execution behavior; it does not optimize the complete trade automatically.

Risks

  • The wrong venue or product post-only rule is assumed.
  • A marketable order is unexpectedly rejected, canceled or repriced.
  • Quote latency makes a non-crossing client price cross at engine arrival.
  • Tick rounding changes the submitted price or crossing test.
  • A locked book, auction or special trading mode changes behavior.
  • A resting order never fills.
  • Adverse selection dominates any maker rebate.
  • Fee tier, rebate sign or fee currency changes.
  • Maker status is inferred from the request rather than each fill.
  • Queue depth or hidden liquidity is underestimated.
  • An amendment resets queue priority.
  • A partial fill is omitted from inventory or cash.
  • Cancel or replace races create an extra fill or overlapping order.
  • A timeout or non-idempotent retry creates uncertain or duplicate state.
  • WebSocket gaps, duplicates or out-of-order events corrupt the local view.
  • Self-trade prevention cancels or reduces an unexpected side.
  • Post-only conflicts with IOC, FOK or another time-in-force rule.
  • Reduce-only, close-only or position mode rejects, shrinks or reverses intent.
  • A triggered child order becomes marketable and is canceled or rejected.
  • Venue, custody, API or rule failure, or onchain ordering, gas, reorg or finality, breaks reconciliation.

Common misconceptions

  • Post-only guarantees a fill. It can reject, cancel, rest without trading or expire.
  • A successful API response proves the order is resting. Transport acknowledgement and matching-engine state are different records.
  • Every post-only fill earns a rebate. Maker classification, fee tier, currency and rate are fill- and venue-specific.
  • Amending or canceling prevents any later fill. Priority can reset, and fills can win the race before terminal confirmation.
  • A transaction hash or block inclusion proves an onchain order became maker liquidity and finally traded. Inclusion, protocol execution, resting state, fill and chain finality are separate events.

Sources

Navigation

Search the wiki...