Polymarket Order Types: GTC, GTD, FOK, FAK and Post-Only

Polymarket has one order primitive — a signed limit order — and four execution types that control how long it lives: GTC, GTD, FOK and FAK. A "market order" is not a separate instrument. It is a limit order priced to cross the book immediately, and it uses one of the two immediate-or-cancel types. Post-only is a flag that rejects an order if it would take liquidity. Choosing the right combination is the difference between paying the spread and earning it.

The short version: GTC rests until cancelled; GTD rests until a timestamp; FOK fills entirely or not at all; FAK fills what it can and cancels the rest. Post-only guarantees maker status. All four go to the same central limit order book, and every fill settles on Polygon.

The four lifetimes

GTC (Good Till Cancelled) is the default for a resting quote. The order sits on the book until it fills or you cancel it. In the API, a GTC order uses an expiration of 0. It is the right choice for a passive limit order that you plan to manage manually or replace when the market moves.

GTD (Good Till Date) is the same, with an expiry. You set the expiration field to a Unix timestamp in seconds before signing. When the timestamp passes, the order stops being eligible. GTD is useful around scheduled events: a quote that expires before a debate, a data release or a game starts cannot be left stale by a connectivity failure.

FOK (Fill or Kill) must fill the entire amount immediately or not at all. It is an all-or-nothing execution type, and it is only used with market orders. If the book cannot absorb the full size at the allowed price, nothing happens.

FAK (Fill and Kill) fills whatever is available immediately and cancels the remainder. It is the default for market orders. A FAK order can partially fill, which is usually what you want when exiting a position and the book is thin.

Market orders must use an expiration of 0 and either FAK or FOK. The order type is not part of the signed EIP-712 payload; it is a top-level field in the request. That matters for integrations: the signature authorizes the order's price and size, while the order type tells the matching engine how to handle the remainder.

Post-only and the maker guarantee

A post-only order is rejected if it would cross the spread. It can only rest on the book. That is how a market maker guarantees that a fill will be a maker fill, which matters for fee treatment and for liquidity reward eligibility.

The rejection is not an error in the system; it is the system doing its job. If the best ask is $0.52 and you submit a post-only buy at $0.54, the order would take, so it is rejected instead of executing. You reprice to $0.51 or $0.52 and try again. In a fast market, this can happen repeatedly, which is why market-making systems usually combine post-only with a local view of the book and a cancel-and-replace loop.

Post-only also appears during maintenance. After a matching-engine restart, the engine enters post-only mode for two minutes: cancels remain available, but new orders must be eligible maker orders submitted as post-only. A non-post-only order submitted during that window is rejected with a post-only error. Integrations should honor the server's retry delay rather than hammering the endpoint.

How a fill actually walks the book

Suppose the ask side has 25 shares at $0.52 and 30 shares at $0.54. The visible liquidity is $13.00 at the first level and $16.20 at the second, or $29.20 in total.

A $20 FAK buy takes all 25 shares at $0.52 and then 12.96 shares at $0.54. It spends $13.00 + $7.00 = $20.00 and receives 37.96 shares, an average price of about $0.5269. The unfilled remainder is zero because the order was sized to $20.

A $40 FOK buy fails entirely: only $29.20 is available, so the all-or-nothing condition is not met. A $40 FAK buy fills the available $29.20 and cancels the remaining $10.80. That is the practical difference between the two types: FAK guarantees you get the liquidity that exists; FOK guarantees you get the size you asked for or nothing.

Price improvement goes to the taker. If you place a limit buy at $0.55 and it matches a resting ask at $0.52, you pay $0.52, not $0.55. The resting order's price sets the trade price when it is better for the incoming order. This is why a limit order can fill below your stated maximum, and why the displayed midpoint is not the price you should assume.

Partial fills are normal for resting orders. A 1,000-share bid may fill in pieces as different sellers arrive. You can cancel the unfilled portion at any time before it matches, but you cannot cancel the portion that has already filled. During a taker delay, a marketable order is pending and cannot be cancelled at all.

Priority, ticks and delays

Resting orders are matched by price first, then by time at the same price — the standard continuous-auction rule. Better-priced orders execute before worse-priced ones, and at a single price level the earliest accepted order is served first. Polymarket's public documentation describes the book and the matching flow but does not publish a formal queue specification, so treat time priority as market convention rather than a contractual guarantee. For sizing, the practical implication is simple: to be filled ahead of the queue, you need a better price, not just an earlier timestamp.

Tick size and minimum order size come from the market's book response. They vary by market: the docs' example uses a $0.01 tick and a five-share minimum, but a market can use a finer tick or a larger minimum. Check the book before calculating size. A price that is valid in one market may be rejected in another.

Selected crypto and finance up/down markets apply a taker delay of 250 milliseconds. The order is held, validation runs again, and then it matches or rests. Sports markets can apply a configured delay around live games. The API may return a "delayed" status, which means the order was accepted but has not matched; it is not a fill. The order cannot be cancelled during the delay, and if risk checks fail when the delay expires, it is rejected.

Risks and common mistakes

• Market-order slippage. A market order walks the book. In a thin market, the average fill can be several cents worse than the top of the book. Estimate the price first, then set a maximum for a buy or a minimum for a sell.
• FOK failure at the worst time. All-or-nothing is reassuring until you need to exit and the book is one share short. FAK is usually the safer exit.
• GTD clock errors. Expiration is Unix seconds, not milliseconds. A timestamp in the wrong unit can expire immediately or live far longer than intended.
• Post-only rejection loops. If your fair value is above the market, post-only will keep rejecting you. That is a signal that you are trying to be a maker at a taker price, not a bug to work around.
• Stale quotes. Resting orders do not update when the underlying event changes. Use GTD around catalysts, or cancel manually.
• Engine restarts. The API can return HTTP 425 during a restart. Retry only restart errors, honor Retry-After, and resume with post-only orders for the first two minutes.

The order type is a small decision with a large effect on execution cost. A trader who always crosses pays the spread and the taker fee. A trader who always rests may never fill. The useful default is a GTC limit order inside the spread for entries, a GTD order around known events, and FAK for exits where partial execution is acceptable.