How the Gnosis conditional token framework powers prediction market shares
The Gnosis Conditional Token Framework (CTF) is the infrastructure beneath many on-chain prediction markets. Polymarket uses it. So do several smaller platforms. The CTF turns ambiguous real-world events into tradeable tokens that can be split, merged, and settled on-chain.
ERC-1155: the basis for conditional tokens
The CTF builds on the ERC-1155 token standard. This matters because ERC-1155 can represent both fungible and non-fungible assets in a single contract. Most prediction market participants encounter fungible outcome tokens - shares that are identical within a given outcome. But the same framework also supports non-fungible positions that encode specific condition sets. That flexibility lets the CTF handle simple binary markets and complex multi-outcome events without separate contracts for each.
ERC-1155 uses a single balanceOf function with a token ID parameter. Each ID maps to a distinct asset. The CTF assigns IDs algorithmically based on the condition and outcome they represent.
How conditional token IDs encode market conditions
Every conditional token ID in the CTF contains two pieces of information: the condition ID and the outcome index. The condition ID is itself a hash - typically derived from the oracle address, the question, and a nonce. The outcome index is a number representing one possible result.
A binary market on "Will BTC exceed $100k on Dec 31, 2026?" might produce condition ID 0xabc...123 with outcomes indexed as 0 and 1. The token for outcome 0 gets an ID computed as keccak256(abi.encodePacked(conditionId, outcomeIndex)). This deterministic encoding ensures that anyone can independently derive the same token ID for the same condition and outcome.
The framework enforces this ID structure. Attempt to mint a token with mismatched condition and outcome parameters, and the contract will reject the transaction. That is the origin of the "Conditional token ID mismatch" error. It means the caller supplied a combination of condition and outcome that does not correspond to any valid token ID under the CTF's rules.
Splitting and merging positions
The CTF does not mint outcome tokens directly. Instead, it allows a user to split a collateral position into outcome tokens, and later merge them back. This is the core mechanism.
To split, a user deposits collateral (USDC, DAI, or whatever the market accepts) into the CTF contract. They specify which condition and how many outcomes. The contract locks the collateral and mints one token per outcome, each with a balance equal to the collateral amount. If you deposit 100 USDC into a binary market, you receive 100 outcome-A tokens and 100 outcome-B tokens.
Merging reverses this. The user sends equal amounts of all outcome tokens back to the contract. The contract burns them and releases the original collateral. If you hold 100 A and 100 B, you can merge them to reclaim 100 USDC.
This split-merge design is why outcome tokens trade at prices that sum to roughly $1 (or 1 unit of collateral). Arbitrage keeps the total near parity: if A is worth $0.60 and B $0.35, someone can buy both, merge, and claim $1, netting the spread.
The misconception about ERC-20 fungibility
Many participants assume outcome tokens are standard ERC-20 tokens. That is not always accurate. While the CTF can and does produce tokens that behave like ERC-20s for each individual outcome, they are technically ERC-1155 tokens with a zero-address operator override that mimics ERC-20 transfers. The interface feels familiar - transfer, approve, balanceOf all work - but the underlying implementation is not a fresh ERC-20 contract per outcome.
The practical consequence matters for integrations. Not every wallet or DEX that supports ERC-20 will support the CTF's ERC-1155-with-ERC-20-wrapper pattern without special handling. Polymarket's frontend abstracts this, building its own transfer and approval logic. But a raw interaction with the CTF contract may fail if the caller expects pure ERC-20 semantics.
The "Outcome tokens are fungible ERC-20 tokens on all platforms" claim is therefore misleading. They are fungible in the sense that all tokens of the same outcome ID are identical. They are not fungible in the sense of being standard ERC-20 compliant across every tool. Wallets and interfaces must explicitly support the CTF's token standard.
The Gnosis CTF is not flashy. It does not need to be. It provides a deterministic, auditable way to turn ambiguous futures into tradeable positions. Its design choices - hash-based IDs, ERC-1155 flexibility, split-merge mechanics - are what make on-chain prediction markets work at scale. The "Conditional token ID mismatch" error is simply the framework enforcing those choices, protecting users from trades that would break the underlying accounting.
Not financial advice. wswap.site publishes market data and general information about digital assets. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.