Skip to main content
Binary and neg-risk markets follow different on-chain settlement paths. Pick the section that applies to the market type you’re integrating.

​
Binary markets — propose → challenge → finalize

​
Step 1 — Oracle source check

The market is configured (at admin authoring) with one or more data sources. When the configured source(s) yield an unambiguous outcome, the market becomes ready to propose. When data is unavailable or ambiguous (no safe majority across configured sources), the market moves to DELAYED. See Void & delayed.

​
Step 2 — On-chain proposal

​
Step 3 — Challenge window

Only the first challenge is accepted.

​
Step 4a — No challenge, finalise

Internally calls ConditionalTokens.reportPayouts, unlocking redemption.

​
Step 4b — Challenge, re-verify

​
Neg-risk markets — direct winner-index report

Neg-risk markets do not use the propose / challenge / finalize lifecycle above. The path is shorter:
  1. Provider-side winner selection — oracle-service selects the winning outcome index from the configured data source(s).
  2. On-chain winner report — the winner index is reported on the neg-risk adapter; the contract resolves that outcome’s token at 1.0 and all other outcomes resolve as losers (0.0).
  3. Redemption — winning-token holders redeem on chain via ConditionalTokens.redeemPositions (or the /api/me/redemptions helper); credit lands the same way as for binary markets.
There is no challenge window on neg-risk. If a neg-risk market needs to be voided post-report (data error, event abandonment), it follows the same admin-authorised void path as binary — but the propose → challenge → finalize cycle is not in scope here.

​
Crypto markets

Crypto markets are binary markets, so they follow the propose → challenge → finalize path above. Two things differ: The evidence is a price rule, not a match result. The outcome is derived from Chainlink price data evaluated against the immutable rule captured on the market at listing time (crypto.productType / direction / targetPrice / deadlineAt / month). Touch products (THRESHOLD_BY_DEADLINE, THRESHOLD_DURING_MONTH) lock YES on the first touch — equality counts — but still settle after the observation window ends. Up/Down windows propose within a minute or two of closing. A 15-minute window closes, and the oracle proposes the direction against the frozen open price (cryptoWindow.openPrice) — typically 1–2 minutes later, versus the ~15 minutes a sports market waits on its data source. What follows is the ordinary challenge window: the platform default unless the window was armed for the fast on-chain path, which gives it a per-market window of zero and finalizes immediately after the proposal. Payouts are [1, 0] for Up (outcome index 0) and [0, 1] for Down (index 1), and cryptoWindow.outcome flips to "UP" / "DOWN" only once the market is RESOLVED — a proposed direction is not a settled one.
Don’t hardcode a settlement delay for crypto. Read resolution.proposedAt and resolution.challengeWindowClosesAt off the market payload — that timestamp is the exact instant finalize becomes legal, and it differs per market.

​
What you observe as a partner

​
Redemption

Two paths produce the same end state — partners can pick whichever is operationally easier:
  1. On-chain self-service — call ConditionalTokens.redeemPositions directly from your client. See the ConditionalTokens contract page for the call signature. Useful when you’re already running an on-chain submitter and want to stay homogeneous.
  2. Off-chain helper — POST /api/me/redemptions — submits a redemption job that the platform’s submitter executes on chain on your vault’s behalf. Body shape:
    indexSets selects which outcome partitions to redeem ([1] for YES only, [2] for NO only, [1,2] for both). Returns { "redemptionId": "...", "status": "QUEUED" } and the redemption completes asynchronously. Missing/invalid marketId returns 400 invalid_request.
Either way, once the on-chain redemption confirms, chain-watcher picks up the PayoutRedemption event and credits the resulting USDC to your off-chain /api/me/balances.collateral automatically — partners don’t need to call any platform endpoint to “claim” winnings beyond the initial redemption call.