Oracle Resolution
Binary markets resolve through an M-of-N consensus oracle: independent oracle signers
each submit a YES/NO verdict on-chain, and the market finalizes only once a threshold of
matching verdicts is reached. Native markets settle on-chain via
magma_binary_vault; third-party markets mirror the
source platform instead. This page covers both.
The backend oracle resolver (M-of-N consensus), deadline sweeper, and settlement worker are live on Solana devnet. Kalshi resolution sync is live (brokered via DFlow). Polymarket is data-only ingestion today — see Third-party resolution.
M-of-N consensus
Resolution is split into two on-chain instructions, mirroring MAGMA's narrative oracle:
| Instruction | Caller | Effect |
|---|---|---|
submit_oracle_resolution | An authorized oracle signer | Writes a binary_oracle[market_id, oracle] submission: the signer's pubkey, vote (YES/NO), and confidence |
finalize_resolution / finalize_resolution_spl | Anyone (permissionless) | Once the M-of-N threshold and timelock are met, finalizes on the matching verdict and unlocks payouts |
A minimum number of independent signers must submit matching verdicts before
finalize_resolution can succeed. Finalization itself is permissionless — once the
threshold and timelock conditions hold, anyone can trigger it.
| Parameter | Testnet | Mainnet |
|---|---|---|
| Oracle threshold | 1 (single oracle) | ≥ 3 (M-of-N) |
| Resolution timelock / dispute window | 0 seconds | 48 hours |
Testnet runs threshold = 1 for development velocity. The account structures and
instruction set are identical to mainnet; only the threshold and timelock values differ.
See the Mainnet checklist.
Categories
Each market is assigned a resolution category at creation by the AI oracle analysis pass. The category selects which data sources the backend resolver consults — price feeds for market questions, sports data providers for sports questions, web-search and LLM reasoning for evidential questions, and so on. This is the same category-driven source model documented for narratives in Oracle Architecture; binary markets reuse that source stack.
A well-posed category and a clear falsifiability assessment are what let the resolver produce a defensible verdict — questions that fail the falsifiability check at creation are flagged before they can go live.
Confidence scoring
Each oracle submission carries a confidence value alongside its YES/NO vote. The backend computes confidence from the agreement and quality of the sources consulted for the market's category. Confidence governs whether the market resolves at all:
- Sufficient confidence → signers submit matching verdicts and the market proceeds to the timelock / dispute window.
- Insufficient confidence → the market is pushed toward refund
(
oracle_status = 4) rather than resolving to a low-confidence outcome.
This mirrors the narrative oracle's confidence-gated behavior, where a verdict below the confidence floor opens a challenge window or refunds rather than auto-finalizing.
Dispute & admin path
After a verdict is written (oracle_status = 1), the timelock period doubles as a
dispute window. A dispute is raised with resolve_dispute, moving the market to
oracle_status = 3 (disputed) and writing a binary_dispute[market_id] record. This is
the ML-3 path shared with settlement:
- Dispute opens during the window → payouts held.
- Admin review examines the on-chain submissions against verifiable data.
- Outcome upheld → the market finalizes on the original verdict.
- Cannot confirm → the market converts to refund (
oracle_status = 4) and backers reclaim their stakes.
On mainnet a dispute bond is required to open a dispute, deterring frivolous challenges (see the Mainnet checklist).
Third-party resolution
Markets imported from external venues do not use MAGMA's native on-chain settlement. They follow the source platform's resolution and are mirrored into MAGMA's database.
| Source | Status | Resolution mechanism |
|---|---|---|
Kalshi (kalshi_import) | LIVE | Brokered via the DFlow API; the market follows Kalshi's resolution, DB-synced. No MAGMA on-chain settlement. |
Polymarket (polymarket) | Data-only | Ingestion only via the Gamma API. On-chain / EVM trading is Phase 14 (planned) — not resolved or settled by MAGMA today. |
A kalshi_import market's outcome is whatever Kalshi resolves; MAGMA records it but
does not run magma_binary_vault settlement for it. A polymarket market is read-only
data in MAGMA today — there is no MAGMA settlement, native or mirrored, until the
planned Phase 14 on-chain integration. Only seed and bot markets settle through the
native M-of-N oracle described above.
See also
- Backing & Settlement — what finalization pays out.
- Creating Markets → source types — how source is assigned.
- Oracle Architecture — the shared multi-source oracle stack and categories.