Market status

State machine

The trading cut-off is the market’s tradingWindow.closesAt, or the end of the match for markets that trade in-play. Any status from PRE_MARKET through DISPUTED can also move to VOIDED. Pre-listing states (DRAFT, REJECTED, APPROVED, DEPLOYING) are internal: the public API never returns a market in them, and filtering by them is rejected with invalid_status. When a market reopens from PENDING_RESOLUTION, its book starts empty — resting orders were cancelled at the cut-off, so re-quote.

Status → trading effect

Status	User-facing trading	Notes
`PRE_MARKET`	Resting LIMIT GTC orders only	Other order types are rejected with `code: pre_market_post_only`, and an order that would cross the book with `code: pre_market_crossing_order`
`OPEN`	Tradeable	The only state that accepts every order type
`PAUSED`	Place order rejected (`code: market_not_open`)	The platform cancels every resting order and releases its locked collateral. The book is empty when the market returns to `OPEN`, so re-quote after resume
`POSTPONED`	Place order rejected (`code: market_not_open`)	The fixture was postponed while the market was paused (resting orders were already cancelled by the pause). Returns to `OPEN` once rescheduled, or ends `VOIDED`. `tradingMode` is `paused`, `notTradableReason` is `postponed` (full market rows only — `GET /api/events` list rows omit both)
`SUSPENDED`	Place order rejected (`code: market_not_open`)	Longer-term halt. Unlike a pause, the suspension itself does not cancel resting orders: a background sweep cancels them and releases their locked collateral shortly afterwards, usually within minutes. While the market is suspended they are not listed by `GET /api/orders/open` — to end them at once, cancel by id (`POST /api/orders/cancel-batch`) or with `POST /api/orders/cancel-all`. After resume, `GET /api/orders/open` lists any that are still live
`CLOSED`	Rejected	Trading cut-off reached; unmatched orders cancelled and funds returned; awaiting the result
`PENDING_RESOLUTION`	Rejected	Oracle is resolving
`DELAYED`	Rejected	Oracle couldn’t get data; manual review
`DISPUTED`	Rejected	A user challenge is being reviewed
`RESOLVED`	Rejected	Terminal — redemption available
`VOIDED`	Rejected	Terminal — positions redeem at the void payout (below)

Terminal states — recovering value

Status	Holder of YES + NO shares can	What to call
`RESOLVED`	Redeem winning shares 1-for-1 USDC; losing shares are worth 0	Nothing, if auto-redeem is on (the default) and your winnings on the market are at least 1 USDC — the platform redeems them within a few minutes. Otherwise `POST /api/me/positions/redeem` with `{ marketId, outcomeIndex }` from your position, then poll `GET /api/me/positions/redeem/{jobId}`. The platform pays the gas and the payout is credited to your vault. API-key callers also send an owner-signed `auth` object.
`VOIDED`	Redeem every share at the market’s payout vector (`payoutNumerators`). A standard void is `[1, 1]`: on a binary market 1 YES = 0.5 USDC and 1 NO = 0.5 USDC, so a YES + NO pair returns 1 USDC. A void at set prices carries its own vector	Nothing, if auto-redeem is on (the default) — the platform redeems the refund within a few minutes, with no 1 USDC minimum. Otherwise the same redeem call as `RESOLVED`.

Your shares sit in your vault, not in your EOA, so calling ConditionalTokens.redeemPositions from the EOA pays nothing. The vault owner can also redeem on-chain directly with Vault.redeemPositions(conditionId, indexSets) (binary) or Vault.redeemPositionsNegRisk(negRiskMarketId, questionIndex, amount) (neg-risk); the payout is credited to the vault either way. Once a market is in any terminal state, any open orders against it are cancelled by the platform (status CANCELLED) and locked balances refunded to available — you don’t need to cancel them yourself. See Settlement & Oracle for the end-to-end resolution timeline.

Subscribing to status changes

Subscribe on the public /ws/market gateway to the market_lifecycle channel with the market symbol:

{
  "id": 1,
  "cmd": "subscribe",
  "params": {
    "subscriptions": [
      { "channel": "market_lifecycle", "ids": ["UAE-CUP-FINAL-20260425"] }
    ]
  }
}

Each status transition pushes a status_changed frame. The frame id is the symbol lower-cased; data.marketSymbol keeps the original case:

{
  "type": "status_changed",
  "id": "uae-cup-final-20260425",
  "data": {
    "marketSymbol": "UAE-CUP-FINAL-20260425",
    "fromStatus": "OPEN",
    "toStatus": "PAUSED",
    "tsMs": 1776867721000
  },
  "serverTs": 1776867721042,
  "sid": 7,
  "channel": "market_lifecycle"
}

action and txHash are added when known and omitted otherwise. The same channel also carries market_disputed and market_resolved frames — see WebSocket messages. Market makers should treat any non-OPEN status as “pause all new orders” and wait for the transition back to OPEN.

Getting Started

Authentication

Vaults

Deposits

Trading

Events & Tags

Markets

Portfolio

Withdrawals

WebSocket

Settlement & Oracle

On-chain Contracts

Partners

Errors

State machine

Status → trading effect

Terminal states — recovering value

Subscribing to status changes

​State machine

​Status → trading effect

​Terminal states — recovering value

​Subscribing to status changes

State machine

Status → trading effect

Terminal states — recovering value

Subscribing to status changes