On this page
A Polymarket limit order sets a price boundary; it does not guarantee a fill. Whether it fills immediately, waits or is rejected depends on its price, the available book and the chosen order rules. This guide, checked October 6, 2026, concerns the international prediction CLOB, not Polymarket US or perpetuals.
Explore the limit-order simulator with a fictional book. It separates immediate fills, resting shares, canceled shares and post-only rejection. It connects no wallet and submits no order.
For the distinct task of interpreting bids, asks and displayed odds, read the Polymarket order-book guide.
Start with the price boundary
The official order guide describes limit orders as specifying price and potentially resting until filled, canceled or expired. Prices must respect the market’s increment and orders its minimum size. A buy’s cap and a sell’s floor are different directions; check the outcome and side before interpreting the quote.
In a fictional buy, 200 shares at a maximum of 54¢ does not mean 200 shares are available at 54¢. Suppose the entered asks are 50 shares at 52¢, 100 at 54¢ and 200 at 57¢. Only the first 150 shares fit the cap. Their modeled cost is $26 + $54 = $80 before fees; their average is about 53.33¢. The 57¢ level remains outside that price boundary.
This arithmetic uses a fixed snapshot and share quantity. It says nothing about whether the book will remain available, how a live order will be validated or what the resulting position will be worth.
Choose how long an unfilled order remains active
| Lifetime | Documented purpose |
|---|---|
| GTC — Good Till Cancelled | Keep the order active until filled or canceled |
| GTD — Good Till Date | Set an expiration deadline |
For GTD, the current official guide specifies a one-minute security offset and an expiration at least three minutes into the future. Check the current convention before converting your desired effective lifetime to a timestamp. The simulator does not model GTD timing.
Use a deadline to express when your willingness to trade ends. For instance, in a hypothetical announcement-driven trade, a resting order placed before the announcement could remain exposed afterward unless it expires or is successfully canceled. A favorable-looking old price can reflect changed information rather than an opportunity.
Compare immediate-execution policies separately
The official guide distinguishes FAK, which fills available liquidity then cancels the remainder, from FOK, which requires the full amount immediately or fills nothing. These are immediate-execution policies, distinct from a resting lifetime. The market-buy SDK examples express amount as money, while sell examples use shares; follow the current method’s units.
| Fictional 200-share buy at a 54¢ cap | Immediate shares | Remaining shares |
|---|---|---|
| GTC illustration | 150 | 50 resting |
| FAK illustration | 150 | 50 canceled |
| FOK illustration | 0 | 200 canceled in this model |
These rows use the same three-level book and fixed share request solely to illustrate policy. They are not API payloads or venue responses. FOK’s modeled zero fill is the consequence of insufficient qualifying depth for the whole request, not a forecast of a live request’s error code.
A limit order is not automatically passive
The official guide says post-only rejects an order that would match immediately rather than taking liquidity. It can accompany GTC or GTD. Without that constraint, a marketable limit price can match existing orders; the word “limit” alone does not mean the order will wait.
In our fictional book, a post-only buy capped at 54¢ crosses available asks, so the simulator rejects the entire sample order. Lowering the cap to 51¢ produces no immediate match and leaves the requested shares resting in the model. That resting amount is not evidence about future fills or queue priority.
Acceptance, a fill and settlement are separate records
The order-management guide recommends checking an order by ID and reconciling open orders with resulting trades. Current records expose original size, matched size, status and associated trades. Use the appropriate authenticated account context rather than inferring execution from a public price alone.
If a request times out, preserve its identifiers and check actual state before submitting a replacement. A missing response does not establish that the first order failed. Similarly, a cancellation attempt does not undo an already executed portion. Treat intended action and confirmed result as separate records.
For withdrawing a resting instruction and checking partial results, read the Polymarket cancellation guide.
Use the simulator to challenge assumptions
- Change the cap so only one entered level qualifies.
- Compare GTC’s resting remainder with FAK’s canceled remainder.
- Switch to FOK and observe the all-or-none condition.
- Enable post-only on GTC and compare crossing with non-crossing prices.
- Switch to sell and use bids; the floor reverses which prices qualify.
The simulator excludes fees, funds and allowances, account and market eligibility, tick/minimum-size validation, delays, queue priority, settlement and later fills. The slippage calculator explores static depth without this policy layer. For integration boundaries and current SDK context, read the Polymarket API guide.
Before a real trade, read the exact contract and its resolution rules independently of your execution choice. A price cap controls one part of an order; it cannot establish the event’s probability or guarantee a profit.