Claim Representation and Implementation Standards

Motivation

Up until now we have had the mental model of binary prediction markets. They consist of binary event bets that are represented as event contingent claims, which have academic grounding as Arrow–Debreu securities.

Binary, in that context, refers to a situation where we have two

exclusive, and
exhaustive

event outcomes — yes-or-no questions. We want to discuss the implications of this choice, and relax this assumption — especially if we want more sophisticated events or bet combinations. That setup is grounded in combinatorial markets (Hanson 2003).

Formal motivation

The state space of a prediction market, denoted by $\mathcal{X}$ , captures both the event specification and the current market configuration. It is defined as

\mathcal{X} = \{ (\mathcal{E}, \mathcal{A}),\, T,\, \mathcal{S},\, L \}

where

$(\mathcal{E}, \mathcal{A})$ denotes the event space,
$T = [t_0, t_1]$ is the time interval during which the market is active,
$\mathcal{S} = (s_1, \ldots, s_n)$ is the vector of outstanding shares corresponding to each outcome, and
$L$ is the total amount of liquidity or collateral backing the outstanding shares.

Hence $\mathcal{X}$ formally encodes both the informational and economic state of the market at a given time $t \in T$ , represented as $\mathcal{X}_t$ .

From $\mathcal{S}$ , one can subsequently derive the instantaneous price vector $\mathbf{p}$ and the implied market probability distribution over outcomes, while $L$ tracks the cumulative liquidity or payout pool available for settlement at resolution.

Once the true realization of the event is known, an information update about the realized outcome $A^*$ is provided by a neutral entity referred to as an oracle.

The oracle updates the market with external information by assigning realized payout values $p_i$ to the event’s outcome shares $\mathcal{S}$ , thereby determining which shares are eligible for redemption.

At resolution, each share $s_i \in \mathcal{S}$ obtains the payout value

p_i = \begin{cases} \bar{p}, & \text{if } A_i = A^*,\\ 0, & \text{otherwise.} \end{cases}

and holders of the winning shares $s^*$ can redeem their claims against the available liquidity $L$ . Typically $\bar{p} = 1$ . In a fully collateralized, complete-set market this payout exactly consumes the pool,

L = \bar{p}\, s_{A^*}

Binary claims as tokens

For a binary event, one unit of collateral $\bar{p} = 1$ can be decomposed into two complementary contingent claims:

YES: pays 1 if the event occurs
NO: pays 1 if the event does not occur

At this stage it is convenient to think of the claims as fungible ERC-20 tokens each. These claims may be traded explicitly as two separate assets, or one side may be quoted while the complementary price is implied by no-arbitrage:

P(\mathrm{YES})+P(\mathrm{NO})=1

Primary market: each unit of collateral can create a full set of claims (YES and NO), since only one of these will qualify for payout (events are exclusive).

Secondary market: it remains to the venue operator whether

there is one marketplace for e.g. YES and the NO price is dictated by $P(\mathrm{NO})=1-P(\mathrm{YES})$ ,
there are two marketplaces, and arbitrageurs ensure price adjustment, or
both assets are priced against each other through an AMM.

This leaves a conceptually strong distinction between the

claim representation and settlement layer (here: fungible ERC-20 tokens), and
claim exchange and price-finding layer (centralized or decentralized venues).

Limitations

While the above solutions are intuitive, they have practical limits. More sophisticated events or bet combinations become infeasible or impractical, and complexity grows with the number of events — especially conditional events.

The binary construction is therefore only the simplest special case. In general, prediction markets seek to allocate claims over a broader state space of possible worlds.

Let the event admit $n$ mutually exclusive and exhaustive outcomes

\mathcal{A}=\{a_1,\dots,a_n\}, \qquad \sum_{i=1}^n \mathbf{1}_{a_i}=\bar{p}

Then one unit of collateral $\bar{p}$ can be decomposed into a complete set of $n$ Arrow–Debreu claims

\{s_1,\dots,s_n\}

where claim $s_i$ pays

s_i = \begin{cases} 1, & \text{if } A_i \text{ occurs},\\ 0, & \text{otherwise.} \end{cases}

Prices satisfy the no-arbitrage complete-set condition

\sum_{i=1}^n P(s_i)=1

This immediately generalizes binary YES/NO markets to:

categorical markets (A/B/C/…)
ranked outcomes
scalar ranges
mutually exclusive scenario sets

Combinatorial logic (Hanson 2003)

Hanson proposes an approach that allows traders to express beliefs over structured dependencies rather than isolated binary questions. Suppose we have multiple linked events

E_1,E_2,\dots,E_m

with joint outcome space

\Omega = \mathcal{A}_1 \times \mathcal{A}_2 \times \dots \times \mathcal{A}_m

Traders may care not only about atomic outcomes, but combinations such as:

$A \cap B$ — both occur
$A \cup B$ — either occurs
$A \mid B$ — $A$ occurs conditional on $B$
subsets of $\Omega$

Hence claims become securities over subsets $S \subseteq \Omega$ with payoff

s_S(\omega)= \begin{cases} 1, & \omega \in S,\\ 0, & \omega \notin S. \end{cases}

Does this work with one ERC-20 per outcome?

If each claim requires a separate ERC-20 token contract, then the number of required assets grows rapidly with:

number of outcomes $n$ ,
number of linked events $m$ ,
number of useful subsets $S \subseteq \Omega$ .

In the worst case

|\mathcal{P}(\Omega)| = 2^{|\Omega|}

possible contingent claims may exist. That makes separate ERC-20 deployments operationally inefficient — the central lesson of the ERC-20 prediction market.

Architectural implication

We therefore seek a system where:

one collateral asset backs many claims,
many claim types can coexist in one contract,
claims can be split and recombined,
joint and conditional outcomes can be represented efficiently.

This is precisely the motivation for the Conditional Token Framework (CTF), where claim identities become token IDs inside a shared ERC-1155 container rather than separate ERC-20 contracts — the direction of the ERC-1155 prediction market.

How does Hanson deal with this theoretically?

Hanson (2003) addresses the same combinatorial problem, but on a different layer. He does not begin with how claims should be tokenized or transferred. Instead, he asks how a very large family of contingent claims can be priced, updated, and kept internally consistent.

His core move is to replace many static token markets with one automated market maker over a joint probability distribution across all states:

p=(p_1,\dots,p_N), \qquad \sum_i p_i=1

Participants do not primarily trade individual tokens. Instead, they move the market from the current belief state $(p)$ to a new state $(p')$ . The system then charges the implied cost of that update through a cost function (via market scoring rules).

The market maker maintains a continuously differentiable, convex function

C : \mathbb{R}^n \to \mathbb{R}

which maps the vector of outstanding shares $\mathcal{S} = (s_1, s_2, \ldots, s_n)$ to the cumulative collateral required to support those positions. The value $C(\mathcal{S})$ represents the total amount of collateral that would have been collected from all traders to reach state $\mathcal{S}$ .

When an agent changes their share holdings by $\Delta \mathcal{S}$ , the corresponding payment (or refund) is

\Delta L = C(\mathcal{S} + \Delta \mathcal{S}) - C(\mathcal{S})

which is the amount of collateral exchanged between the agent and the AMM. The instantaneous or marginal price of an outcome share is the gradient of the cost function,

p_i = \frac{\partial C(\mathcal{S})}{\partial s_i}

with the vector form

\mathbf{p} = \nabla C(\mathcal{S}) = (p_1, p_2, \ldots, p_n)

Each component $p_i$ is the infinitesimal price to purchase an additional unit of share $s_i$ given $\mathcal{S}$ . Because $C$ is convex, $\mathbf{p}$ is monotone in $\mathcal{S}$ , ensuring consistent and arbitrage-free pricing.

Hence the central idea is:

trade beliefs rather than standalone tokens,
let the market maintain a shared aggregate probability model,
interpret trades as information updates.

Under logarithmic market scoring rules (LMSR), prices are derived from the distribution and desirable modularity properties hold: users can update local beliefs without unnecessarily disturbing unrelated parts of the distribution (Hanson 2007).

This substantially mitigates combinatorial explosion: instead of creating separate markets for every claim, one coherent market prices claims derived from the joint distribution.

Hanson also notes that this is only a partial solution. While incentives and pricing improve, computational complexity remains for large state spaces. He discusses workarounds including Bayes-net representations, sparse dependency structures, overlapping local market makers, and approximate inference methods.

Relationship to CTF

CTF solves a different problem.

Hanson: economic pricing architecture
CTF: blockchain asset architecture

Where Hanson asks how complex claims should be priced, CTF asks how such claims can be represented, issued, transferred, recombined, and settled efficiently on-chain.

What is an ERC-1155?

Before introducing CTF, we need the token standard it builds on. ERC-1155 is an Ethereum token standard for multi-asset contracts:

ERC-20 — one contract usually represents one fungible asset (one contract, one asset),
ERC-721 — one contract manages non-fungible tokens (one contract, many unique assets),
ERC-1155 — many token types coexist in a single contract, which can manage fungible tokens, semi-fungible tokens, unique items, and arbitrary classes identified by IDs (one contract, many fungible or non-fungible asset classes).

It was mostly used in gaming and NFT ecosystems, where one contract might contain currencies, weapons, tickets, skins, and collectibles. Each asset is a token ID with its own balances and metadata.

Useful for prediction markets

Markets generate many related asset types:

YES claim on Event A
NO claim on Event A
Candidate B wins
Candidate A or B wins
BTC > 150k by Dec 31
Candidate A wins AND inflation > 4%

With ERC-20, each claim typically needs a separate token contract. ERC-1155 avoids that:

one contract can host many contingent claims,
each claim becomes a token ID,
balances remain fungible within each claim class,
transfers can be batched efficiently,
no new contract deployment is needed per market.

That makes ERC-1155 a natural substrate for the Conditional Token Framework.

Conditional Token Framework: conceptual architecture

Our focus is the layer representing claims and settlements. CTF turns collateral into structured claims over outcome subsets, and leaves pricing and trading to external market layers.

Core primitives:

Condition: a question resolved by an oracle
Outcome slots: the mutually exclusive outcomes of that question
Collection: any subset of outcomes
Position: collateral tied to a collection
Token ID: the ERC-1155 representation of that position
Payout vector: the oracle’s final settlement weights

Lifecycle of a position

Technical

The lifecycle touches both the representation/settlement layer (CTF) and the market/trade layer (M):

(CTF) Positions are created / a condition is prepared
- prepareCondition(address oracle, bytes32 questionId, uint outcomeSlotCount)
- defines the oracle, the question identifier, and the number of outcome slots
(CTF) Collateral is associated / collateral is split into claims
- splitPosition(IERC20 collateralToken, bytes32 parentCollectionId, bytes32 conditionId, uint[] partition, uint amount)
- for an $n$ -outcome market, each unit of collateral becomes a full set $(s_1, \dots, s_n)$
- claims are ERC-1155 token IDs and are credited to the user
(M) Positions can be traded on the market layer
- CTF does not determine prices or trade — it only tracks balances and ownership
- see Gnosis conditional-tokens-market-makers
Optional (CTF): claims are merged
- mergePositions(IERC20 collateralToken, bytes32 parentCollectionId, bytes32 conditionId, uint[] partition, uint amount)
- before resolution, holders of a complete complementary set may recombine them through merge
- allows exit without waiting for settlement
(CTF) Conditions are resolved
- reportPayouts(bytes32 questionId, uint[] payouts)
- the oracle reports a payout vector — fractional payouts are possible for scalar / multi-outcome markets
- claim balances still exist; redemption values are now determined
(CTF) Winning positions are redeemed
- redeemPositions(IERC20 collateralToken, bytes32 parentCollectionId, bytes32 conditionId, uint[] indexSets)
- claims are burned; corresponding collateral is released

Economic

Economic state	Value type	Description	Example
Collateral	Unconditional value	Base asset used to fund claims before any event resolution.	100 USDC deposited into CTF
Positions	Conditional value	Claims whose value depends on future outcomes; represented as ERC-1155 position IDs.	100 YES + 100 NO shares
Redeemed payout	Realized value	Final value after oracle resolution and claim redemption.	100 USDC returned to winning holder

The market layer: AMMs on top of CTF

CTF does not answer: what is the fair price of a claim; who stands ready to buy or sell; how traders enter or exit instantly; how liquidity is pooled; or how fees are distributed.

In the Gnosis architecture, that layer is implemented through separate market-maker contracts built on top of CTF. They use CTF positions (ERC-1155 claim IDs) as underlying assets and provide automated trading.

Two canonical automated market makers:

Fixed Product Market Maker

Prices claims from pool inventories — prices emerge from reserve balances rather than an explicit probabilistic model
same intuition as a DEX: scarce tokens increase in price
process: collateral enters the pool → collateral is split into complete sets → traders receive the desired outcome token → the pool retains complementary claims → opposite trades can later merge back into collateral

LMSR Market Maker

Follows Hanson: instead of pricing from inventories, it prices through a convex cost function over outstanding shares. Under LMSR, prices correspond naturally to probabilities, liquidity is continuous, and the sponsor’s worst-case loss is bounded.

Let $\mathcal{S}=(s_1,\dots,s_n)$ denote the current share state. The market maker defines $C(\mathcal{S})$ , and the cost of a trade is

\Delta L = C(\mathcal{S}+\Delta\mathcal{S}) - C(\mathcal{S})

Marginal prices are

p_i = \frac{\partial C}{\partial s_i}

Code analysis

CFMM core contract state

The contract stores references to:

ConditionalTokens public conditionalTokens;
IERC20 public collateralToken;
uint[] positionIds;

Hence the AMM directly holds inventories of CTF claim tokens.

CFMM buy flow

When a trader buys an outcome claim:

collateral is transferred into the AMM,
fees are deducted,
remaining collateral is split through CTF into a full set of claims,
the desired outcome token is sent to the trader,
complementary claims remain inside the pool.

splitPositionThroughAllConditions(investmentAmountMinusFees);
conditionalTokens.safeTransferFrom(
  address(this),
  msg.sender,
  positionIds[outcomeIndex],
  outcomeTokensToBuy,
  ""
);

CFMM sell flow

When a trader sells an outcome claim back:

the AMM receives the claim token,
combines it with complementary pool inventory,
merges complete sets back into collateral through CTF,
returns collateral minus fees.

mergePositionsThroughAllConditions(returnAmountPlusFees);
require(
  collateralToken.transfer(msg.sender, returnAmount),
  "return transfer failed"
);

LMSR market maker implementation

The core pricing functions are:

calcNetCost(int[] memory outcomeTokenAmounts)
calcMarginalPrice(uint8 outcomeTokenIndex)

A trader specifies how many claims to buy or sell across outcomes, and the contract computes the implied collateral cost of moving the market to the new state — the cost functions discussed above.

Trade lifecycle

Lifecycle step	CFMM / FPMM	LMSR
Common starting point: what the position is	Take a binary market such as BTC > 150k by Dec 31. CTF creates two claim IDs: YES and NO. A position is one of these collateral-backed claims — a balance of a claim ID.	Same. A position is again a collateral-backed balance of a claim ID.
1. Market initialization	A liquidity provider sends collateral into the FPMM. The contract receives collateral, calls `splitPosition(...)`, mints a full set of outcome claims, keeps those claims in AMM inventory, and mints LP shares to the funder. After funding, the pool holds YES claims, NO claims, fee balances, and LP accounting. The market begins with actual token inventories ready for trading.	The LMSR sponsor provides funding. This funding determines liquidity sensitivity. The market begins with an initial cost-function state, an initial outstanding-share configuration, and a bounded-loss guarantee for the sponsor. Unlike FPMM, the key object is not token reserves, but the current point in LMSR state space $q$ .
2. Trader buys position	Suppose a trader buys YES. The trader sends collateral to the AMM. The AMM takes a fee, splits remaining collateral into fresh YES+NO through CTF, transfers YES to the trader, and retains NO plus the rest of its inventories. The trader now holds YES as an ERC-1155 claim token. Economically, the trader acquired a conditional YES claim. YES inventory became scarcer relative to NO, so YES price rises. Price changes because reserve composition changed.	Suppose a trader buys YES. The trader proposes a trade vector with positive YES quantity ( $\Delta q_{\mathrm{YES}} > 0$ ). The contract computes the collateral cost ( $\Delta C = C(q+\Delta q)-C(q)$ ). The trader pays this cost, the market state updates, and the trader receives YES claim tokens. Economically, the trader is not draining inventory but moving the market belief state. The claim token is the same object, but the price came from the cost-function geometry.
3. Position held / transferred	The trader holds the YES claim token in their wallet. It may be held, transferred, sold back to the pool, or used on another venue. At this stage it is simply a CTF claim token outside AMM control.	After the trade, the trader also holds YES as a claim token. It may be held, transferred, sold, or redeemed later. The representation is identical to FPMM, but its valuation originated from the LMSR state rather than reserve scarcity.
4. Trader sells position back	Suppose the trader later sells YES back. The trader transfers YES to the pool. The AMM receives YES, combines it with complementary NO inventory, merges complete sets through CTF, recovers collateral, and pays the trader collateral minus fees. Economically, a claim re-enters circulation inside the AMM and collapses back into collateral. The lifecycle is inventory-centric: minted from collateral, held in pool inventory, transferred to trader, maybe returned, recombined into collateral.	If the trader sells YES back, the trader proposes a negative trade amount. The contract computes the reverse state move, determines the collateral refund from the cost difference, receives YES back, and updates the market state. Again, the core object is ( $\Delta C = C(q') - C(q)$ ), now favorable to the trader. Economically, the trader is unwinding an information position and the market moves from one belief state to another.
5. Hold to resolution / redemption	If the trader keeps YES until the event resolves: the oracle reports payout, the trader redeems YES through CTF, YES is burned, and collateral payout is received. Settlement follows the normal CTF process.	Same as FPMM. The oracle resolves the event, the winning claim is redeemed, the claim token is burned, and collateral is paid out. The settlement layer is unchanged.

References

[1] Robin Hanson — Combinatorial Information Market Design (2003).
[2] Robin Hanson — Logarithmic Market Scoring Rules for Modular Combinatorial Information Aggregation (2007).
[3] Gnosis — ConditionalTokens.sol (conditional-tokens-contracts).
[4] Gnosis — FixedProductMarketMaker.sol.
[5] Gnosis — LMSRMarketMaker.sol.
Polymarket — CTF exchange overview (production CTF-style settlement architecture).
Related write-ups — ERC-20 Prediction Market, ERC-1155 Prediction Market.