Markets

All live PredictAsiaX prediction markets. Data sourced from GET /v1/markets. Click a card for the raw API view. Every market has an embeddable widget — see Embed a market.

Loading markets…

Create a market

Every market on PredictAsiaX is created by submitting a proposal through POST /v1/composer/markets (canonical alias for POST /v1/composer/proposals — both call the same handler). Creation is permissioned to any builder at tier read_live or above (auto-graduated at $100 30-day attributed volume). The market_creator fee split (2–3 bps of every fill under the PAF 7-actor model, see Fee Architecture) accrues to your builder wallet for the life of the market.

Market types

Binary (YES / NO) — single outcome, 0–1 probability. Most common. Settlement produces exactly one winning side.
Over / Under (scalar) — numeric threshold (e.g. "BTC > $150k by 2026-12-31"). Resolves against a numeric feed.
Multi-outcome (categorical) — N > 2 discrete outcomes, one wins. Submit via POST /v1/composer/proposals (seeded templates at GET /v1/composer/templates).

Templates + settlement rules

PAX seeds a set of typed market templates — each declares a resolution rule schema, edge cases, and expected data source. You can optionally propose against a template so operator review is faster and translations are pre-cached, or submit a fully-custom proposal. The template catalog is public + no-auth:

GET /v1/composer/templates              # list seeded templates
GET /v1/composer/templates/{tpl_id}     # read a single template + param schema

Every template renders its resolution rule and edge-case text in 13 languages (English, 简中, 繁中, 日本語, 한국어, Bahasa, Tiếng Việt, ไทย, हिंदी, Español, Português, Русский, العربية). Rendered previews are what your end-users see — not raw parameter names.

Submit + track

POST /v1/composer/markets
  {
    "title":                 "Will BTC close above $150,000 on 2026-12-31?",
    "rules_text":            "Resolves YES if the CoinGecko BTC/USD 4pm ET close on 2026-12-31 is > 150000.00 (fallback: mean of Coinbase + Kraken 4pm ET)",
    "resolution_rule":       "asset_above_by",
    "primary_source_url":    "https://www.coingecko.com/en/coins/bitcoin",
    "backup_source_urls":    ["https://api.coinbase.com/v2/prices/BTC-USD/spot"],
    "cutoff_time_ms":        1798761600000,
    "resolution_deadline_ms": 1798848000000,
    "edge_cases_text":       "If CoinGecko is unavailable at 4pm ET, use the mean of Coinbase + Kraken 4pm ET.",
    "proposed_template_id":  "tpl_asset_above_by"       // optional
  }
→ { data: { proposal_id: "prp_...", state: "pending_review" }, meta: { ... } }

GET /v1/composer/proposals/{prp_id}    # poll proposal state + translation progress
GET /v1/composer/proposals             # list your own proposals

The proposal enters the review state machine (pending_review → approved → market row created + pending_translation → listed → trading → resolving → settled) and an admin worker (SLA-tracked) does the scoping check before listed. trading is when the CLOB opens; market_creator attribution is set at market row creation and immutable.

Fee accrual for creators

Every CLOB fill in your market writes a FEE_MARKET_CREATOR event (3 bps at auto tier / trade_full, 2 bps at genesis/partner) to the Neon financial ledger, credited to creator:<user_id>. See GET /v1/revenue for accrual state (per-role breakdown) and POST /v1/builders/me/settle to move settled amount into a USDT withdrawal. Full settlement path in Fee Architecture / Payout flow.

Oracle / resolver responsibility

Automatic engines resolve against declared data sources (price APIs, sports APIs, official authorities). For markets flagged admin_reviewed at creation, or when the automatic resolver returns indeterminate, the market routes into the resolver queue — Oracle Provider track builders bond USDT per attestation to submit resolution evidence. Public evidence URLs + challenge-and-defend model. Every resolution writes an audit event verifiable at /verify.

Embed a market

Every market has a self-contained widget URL that publishers can iframe. It renders title + live prices + a "Trade on PredictAsiaX" CTA. Attribution is baked in — replace YOUR_APP_ID with your app ID so any user routed from the widget carries your builder attribution.

<iframe
  src="https://docs.predictasiax.com/embed?id=m_btc_150k_2026&theme=dark&app_id=YOUR_APP_ID"
  width="360" height="240"
  style="border:0; border-radius:10px"
  loading="lazy"
  title="PredictAsiaX market embed">
</iframe>

Query params: id (required, market ID). theme = dark | light. app_id = your app id for attribution on click-throughs.

Query the raw endpoint

curl "https://api.predictasiax.com/v1/markets?category=crypto&q=btc&limit=20"

Response envelope { data: { markets: [...], page: { next_cursor } }, meta: {...} }. See OpenAPI spec for the full Market schema.