Conditional Tokens

• Name: Conditional Tokens
• URL: https://github.com/gnosis/conditional-tokens-contracts
• Category: contingent-claim settlement standard / prediction-market position primitive / ERC-1155 outcome-tokenization layer
• Tags: ethereum-ecosystem
• Summary: Conditional Tokens are a claim-settlement primitive, not a market. They turn oracle-defined conditions into ERC-1155 positions over outcome subsets, with split, merge, and redeem flows doing the real work. That is why the note belongs under references: the useful thing here is the settlement grammar beneath prediction apps, not a standalone product surface.
• What it does:
  • Lets an oracle prepare a condition identified by (oracle, questionId, outcomeSlotCount), with categorical and scalar payout patterns described in the docs
  • Represents claims on outcome subsets as ERC-1155 positions backed by an ERC-20 collateral token rather than separate 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 positions
  • 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
  • Serves as a lower-layer settlement standard that later AMMs, prediction-market frontends, and oracle pipelines can sit on top of
• Key claims:
  • The durable insight is the decomposition: condition definition, outcome-subset encoding, position composition, and collateral settlement are distinct layers instead of one flattened prediction market object.
  • The ERC-1155 representation matters because it makes contingent claims portable inventory. Downstream systems can transfer, pool, or reuse positions without minting a new token contract for every market.
  • The docs make clear that truth discovery and semantic question design stay outside the standard. Conditional Tokens standardize onchain claim machinery, not oracle governance or dispute resolution.
  • The position DAG is the reason this note is worth keeping. It supports combinatorial exposure across conditions instead of only one resolved event at a time.
  • Split, merge, and redeem are the real control surfaces. They decide how collateral enters the system, how exposure gets atomized or recombined, and how claims cash-settle after resolution.
• 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.
• Sources:
  • https://github.com/gnosis/conditional-tokens-contracts
  • https://raw.githubusercontent.com/gnosis/conditional-tokens-contracts/master/docs/developer-guide.rst
  • https://raw.githubusercontent.com/gnosis/conditional-tokens-contracts/master/docs/glossary.rst
  • https://raw.githubusercontent.com/gnosis/conditional-tokens-tutorial/master/docs/01_prediction_markets_use_case.md

Internal linkages

• Strongest consumer-side comparison in this corpus: azuro.

• Oracle-decision layer that often sits above contingent-claim settlement: uma-optimistic-oracle-v3.

• Last reviewed: 2026-06-12 UTC