Skip to main content
Settlement is automated through two on-chain oracles: Oracle for binary markets and the neg-risk oracle for neg-risk markets. Both run the same propose → challenge → finalize lifecycle — see Flow for the timelines. On the data side, a market settles from the data source configured for it when it is listed; some markets have more than one source, in which case a strict majority of them must agree.

Flow

Propose / challenge / finalize timelines for binary and neg-risk markets.

Challenges

10 USDC bond, 2h window, override / confirm / void outcomes.

Void / delayed

When automated settlement cannot proceed safely.

Data sources

The platform integrates with multiple match-data providers (for example Stats Perform, API-Football and LSports). By default a market is configured with one source; some markets are configured with additional sources. When a market has several sources, the rule is a strict majority: more than half of the configured sources must report the same outcome (with two sources, both). A market moves to DELAYED when the configured source(s) cannot produce a safe, unambiguous outcome — data is unavailable or ambiguous, there is no strict majority among the configured sources, or the source reports the event cancelled or abandoned (the platform then decides whether to void). See Void & delayed.

Bond + challenge window

Binary and neg-risk markets both settle through the propose → challenge → finalize lifecycle with a bond-backed challenge window. Binary markets use Oracle (keyed by conditionId); neg-risk markets use the neg-risk oracle (keyed by negRiskMarketId), which settles every outcome of the group in one transaction — see Flow. On both:
  • Challenger bond: 10 USDC
  • Challenge window: 2 hours after proposal by default (the exact deadline is resolution.challengeWindowClosesAt)
  • Only the first challenge per market is accepted
Outcomes: See Void & delayed for what the void payout vector means for redemption.

Emergency paths

These exist on both oracles; the id is the conditionId (binary) or the negRiskMarketId (neg-risk).
  • markDelayed(id) / undelay(id) — pause while waiting for data.
  • voidMarket(id) — admin-authorised void path (executed by the oracle’s admin role). On neg-risk it is queued first and is not available once any position in the group has been converted — see Void & delayed.
  • initiateProposalClear + executeProposalClear — 7-day timelock path for clearing a stuck proposal.

What partners typically need to know

  1. Fills are not final until the oracle finalises the market.
  2. Subscribe to market_lifecycle on /ws/market (id = market symbol): market_resolved fires on finalisation, market_disputed on a challenge, and every status change — including VOIDED and DELAYED — arrives as status_changed.
  3. Redemption goes through your vault, which holds the outcome tokens. Auto-redeem, on by default, redeems voided-market refunds and winnings of at least 1 USDC per market for you within a few minutes of the final status. For anything smaller, or with auto-redeem off, use the gasless POST /api/me/positions/redeem, or have the vault owner call Vault.redeemPositions / Vault.redeemPositionsNegRisk (see Redemption). The payout is credited automatically to the USDC row’s available in GET /api/me/balances.