Summary: Conditional Tokens are worth cataloging as a lower-layer primitive beneath prediction-market apps, not as a standalone market brand. The core contracts standardize how an oracle-defined condition becomes redeemable claim tokens over subsets of outcomes, represented as ERC-1155 positions that can be split, merged, combined across conditions, and eventually redeemed back into collateral or shallower positions. That makes Conditional Tokens a useful comparison point for prediction markets, insurance-like event claims, futarchy, and contingent settlement systems because the real control surfaces are not just question creation or resolution, but how conditions are defined, how outcome subsets are encoded, how multi-condition exposure is composed, and how collateral-backed claims move between shallow and deep positions.
What it does:
Lets an oracle prepare a condition identified by (oracle, questionId, outcomeSlotCount), with categorical and scalar payout patterns supported by the docs
Represents claims on outcome subsets as ERC-1155 positions backed by an ERC-20 collateral token rather than by standalone market-specific token contracts
Uses index sets and collection identifiers to encode subsets of outcomes and compositions across multiple conditions
Allows users to split collateral into conditional positions, merge positions back upward, and redeem resolved positions into collateral or shallower conditional claims
Supports deep positions contingent on several conditions at once, so exposure can be composed as a DAG instead of only as isolated single-market tokens
Provides a general settlement layer that later AMMs and prediction-market frontends can sit on top of rather than baking market logic into one app-specific contract family
Key claims:
Conditional Tokens clear the bar because they isolate the settlement grammar of contingent claims from the UI, AMM, or market-operator layer. That is a durable mechanism worth keeping visible in the corpus.
The most important mechanism insight is the split between conditions, outcome collections, collection identifiers, and positions. This makes what is being resolved, which subset of outcomes is referenced, and which collateral-backed claim a user holds distinct comparison layers instead of one flattened market object.
The ERC-1155 representation matters because it turns prediction-market exposure into a reusable multi-asset inventory layer. Conditional claims can be transferred, pooled, or composed by downstream systems without requiring a separate token contract per market.
The docs make clear that oracle and question-ID interpretation remain offloaded to surrounding systems. Conditional Tokens standardize the onchain claim machinery, but not truth-discovery, dispute resolution, or semantic question encoding.
The position DAG is analytically important because the system is not limited to one resolved event at a time. It can express contingent combinations across conditions, which makes it a stronger base layer for combinatorial markets, insurance-like claims, and event-linked structured products.
Split / merge / redeem flows are the core control surfaces. They determine how collateral enters the system, how exposure gets atomized or recombined, and how resolution actually cash-settles claims.
Conditional Tokens belong in the active corpus because they provide a canonical mechanism entry for prediction-market infrastructure and a missing comparison baseline for Azuro, Omen-style systems, and any oracle-backed contingent-claim protocol.
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official contract docs, glossary, tutorial, and repository materials collected in ../whitepapers/conditional-tokens-primary-sources-2026-05-13.md.