What the Documented Venue Means by a Market Order

A "market order" on the documented venue is not a second kind of order. Official docs say every user-facing order is a limit order: a price you will pay or accept, and a quantity. A market order is that same order with the price set so it is marketable — high enough to buy the resting asks, or low enough to sell into the resting bids. The label is a use of a limit, not a promise that you trade at the number on the screen.

This page is about that object, on public documentation retrieved 2026-08-16T01:14Z. It is not a rewrite of the already-live guide on bid, ask, spread, and depth. That companion owns the four numbers people collapse into "the price," and the fact that a screenshot is not a fill. It is not a rewrite of the fees guide, which already owns the midpoint display rule and the taker-fee table, and which mentions this definition in one sentence. This page owns the definition, what "marketable" means, the estimate as a snapshot, Fill-and-Kill versus Fill-or-Kill, and the fact that delayed is not a match.

What this page does not claim. It does not tell you to press Market, to take the spread, or to size off an estimate. It does not describe the current buttons on the public website — those were not screenshotted tonight — and it does not know whether a control labeled Market submits Fill-and-Kill, Fill-or-Kill, or something the docs do not name. It does not treat a documentation $0.34 / $0.40 / $0.37 trio, or a $0.55 buy that improves to $0.52, as a live book. It does not guess the delay on a named live market.

It is still a limit

The prices-and-orderbook page is blunt: all orders on this venue are technically limit orders. A "market order" is simply a limit priced to execute immediately against resting orders. The order-lifecycle page says the same thing without the quotes: all orders are limit orders; "market orders" are those limits with a price set to execute immediately against the best available resting orders. The place-orders page says a market order uses the same underlying order as a limit and derives a marketable price from current book liquidity.

A limit that is not marketable rests. The lifecycle page's test is arithmetic. A buy is marketable when its price is greater than or equal to the lowest ask. A sell is marketable when its price is less than or equal to the highest bid. If that test fails, the order sits until someone trades against it, it is cancelled, or — if it is Good-Till-Date — it expires.

Post-only is the other use of the same machine. Official docs say a post-only order will only rest. If it would match immediately — if it would cross — it is rejected instead of executed. That is documented with Good-Till-Cancelled or Good-Till-Date. It is the opposite of pricing a limit to cross. This page does not tell you to use either setting.

Marketable is not "any price"

The place-orders page has the integration derive a marketable price from current depth, then send that price as a cap. On a buy, maxPrice is the highest price the order may pay. On a sell, minPrice is the lowest price it may receive. If the book moves before the order is submitted, the same page says the order may fill only in part, or not at all.

That cap is why "market order" here is still a limit. Crossing the spread is not an instruction to pay whatever prints next. The docs' own estimate helper is labeled a snapshot. "The available price can change before you submit the order." An estimate is not a fill. A later fill is UNKNOWN.

A market order, on that same page, never rests. Any amount that cannot fill is cancelled. Fill-and-Kill takes what is there and cancels the rest. Fill-or-Kill takes the entire order immediately or takes none of it. Fill-and-Kill is the documented default on the place-market-order helper. Which of those — if either — a website control submits is UNKNOWN.

Delayed is not a fill

Matching is not always the next line after "accepted." The lifecycle page says some markets hold a marketable order before they match it. It names a 250 millisecond taker delay on selected crypto and finance up/down markets, and a sports or game delay on configured sports markets. During either delay the order is pending and cannot be cancelled. If balance, allowance, market, or risk checks fail when the delay expires, the order is rejected instead of matching.

The place-orders page is explicit about the status that comes back. delayed means the order was accepted and has not matched. The returned amounts are zero or empty. There are no trade IDs yet, because no fills exist yet. Treat it as pending, not as a fill. Market Details names the field an integration is told to read — secondsDelay, "delay, in seconds, before a newly placed marketable order can match." The documentation JSON on that page shows secondsDelay: 0. That 0 is a documentation example retrieved 2026-08-16T01:14Z. Which live markets currently delay, and for how many seconds, is UNKNOWN. This packet did not call the CLOB.

After a match, settlement is a different clock. Official docs say the operator matches offchain and settlement transfers pUSD and outcome tokens onchain. That settlement is atomic: the trade succeeds, or nothing happens. An accepted response may not yet carry a transaction hash. The operator, the trading-overview page says, cannot set prices or execute trades the user did not authorize.

The number on the screen is still the wrong object

A market buy, on the prices-and-orderbook page, pays the lowest ask. A market sell receives the highest bid. The number the same page says the venue displays is the midpoint of those two, unless the spread is wider than ten cents, in which case it shows the last trade. Their documentation example: best bid $0.34, best ask $0.40, displayed $0.37. A buyer in that example pays $0.40. Those three figures are documentation, not a live book.

So a "market order" priced to cross is still not a fill at the displayed percentage. The already-live fees guide owns that display rule and the taker-fee formula. This page only needs the one consequence: the object you send to cross the book is a limit at a marketable price, and the object on the screen may be a midpoint, a last trade, or an estimate. They are allowed to differ.

If the crossing price is better than the cap, the lifecycle page says the taker keeps the improvement. Its documentation example: a buy priced at $0.55 that matches a resting sell at $0.52 pays $0.52. That pair is documentation. It is not a reason to send a marketable buy.

A market buy's dollar amount, the place-orders page says, is the pre-fee notional. Platform fees and builder taker fees are charged on top. What those fees are on a named live market is UNKNOWN here. That invoice lives on the fees companion, and only after that market's own feeSchedule is read.

Tick size and minimum size are per market. Market Details publishes a grid of increments and says to read the active values from the market rather than assuming one. Its documentation example is a 1¢ tick and a minimum size of 5. The prices-and-orderbook page separately says the book has no maximum size and that large orders may move the price. A minimum and the absence of a maximum are not a contradiction. Neither number is a live book's size tonight.

A reading routine

Read the object before the button. If the docs on this venue are the ones you are reading, a market order is a limit priced to be marketable. Marketable is a test against the best opposing quote, not against the displayed midpoint. An estimate is a snapshot. delayed is accepted, not matched. Unfilled size on a market order is cancelled, not rested.

Then stop. This page does not tell you to cross. It does not tell you to rest. Depth, screenshot-as-non-fill, and the fee table are other guides. The contract you would be buying, if you were buying, is still the resolution rules — and that is another guide still.