Conditional token

Also written conditional tokens, CTF token, Conditional Tokens Framework

The ERC-1155 token a Polymarket position actually is: one outcome of one question, created by the Gnosis Conditional Tokens contracts against locked collateral. One unit of collateral splits into a complete set, one token per outcome, and a complete set merges back into collateral. Once the oracle reports, each token redeems for its share of the payout. It is a claim on collateral, not a coin with a supply of its own.

A dashboard that reads Polymarket from the chain is reading conditional tokens, whether or not it uses the phrase. Most of the ways two such dashboards disagree about a wallet's position, its profit or a market's volume trace back to three operations on these tokens that are not trades.

How it works

Gnosis's Conditional Tokens contracts build everything from a condition: a question that one named oracle will report on, with a fixed number of outcome slots. A yes/no question has two. The condition's identifier is a hash of the oracle, the question and the slot count, so the same wording under a different oracle is a different condition.

A position is a claim on some subset of those slots, backed by a particular collateral token, and each position is an ERC-1155 token whose ID is a hash of the collateral and the slots it covers. On Polymarket, the Yes share and the No share of a market are two such tokens. Polymarket's current exchange contracts, CTF Exchange V2, describe themselves as the system for trading these assets, with operator-run matching and a wrapped collateral layer.

Three operations create, destroy and cash out positions:

  • Split. Lock one unit of collateral and receive one token for each outcome — a complete set. The Gnosis documentation notes this generalises the "buy all outcomes" call of its earlier market contracts.
  • Merge. Hand back a complete set and receive the unit of collateral. This is the reverse, and the reason a Yes and a No together are always worth one unit before resolution.
  • Redeem. After the oracle reports a payout vector — one number per slot, summing to one — each token converts into collateral at its slot's share. A Yes on a question that resolved yes takes the whole unit.

Polymarket's multi-outcome adapter states the constraint that follows: once collateral is split into position tokens, there are only two ways to get it back, merging complete sets or redeeming after resolution. The exchange's own architecture lists mint and merge among its asset operations, so a match can create a new pair from two buyers rather than move an existing token from a seller to a buyer.

Two cases that surprise people

A payout does not have to be all or nothing. The framework's own scalar example resolves a condition to nine-tenths and one-tenth, and Polymarket's adapter README notes that its UMA resolution adapter can return [1,1] — equal weight on both sides, so each token redeems for half.

Multi-outcome markets add a conversion. In a market of mutually exclusive candidates, the adapter lets a holder turn No tokens on several candidates into Yes on the rest plus collateral, because the two positions pay the same in every outcome. Value moves between tokens without anyone else taking the other side.

Why it matters here

A position can change with no trade to explain it. Splitting, merging, redeeming and the multi-outcome conversion all move value in and out of a wallet's positions without a counterparty fill. A tracker that computes profit from the trade history alone will show a gap exactly where those happened. OrcaLayer tracks the split, merge and redeem operations separately, and tracking a wallet's positions walks through what else a reconstruction has to handle.

Volume and open interest depend on how you count a mint. When a match creates a fresh pair rather than moving an existing token, the number of tokens outstanding grows and no seller exists. A dashboard counting transfers, one counting fills and one counting collateral locked will each report something defensible and different. Why two dashboards disagree on volume is the long version.

"Token" suggests a coin, and this is not one. A conditional token is an ERC-1155 ID, not an ERC-20 contract: it is identified by a contract address and a number rather than by a ticker, and every question mints its own. Its value before resolution is whatever its book says; after resolution it is exactly its slot's payout, and that payout is not collateral in the wallet until someone calls redeem.

Winning is a transaction, not an event. After a market resolves, the tokens sit in the wallet until they are redeemed, and the collateral arrives only then. The Polymarket CLI has ctf redeem and a separate ctf redeem-neg-risk for multi-outcome markets, and polymarket-client exposes the same three operations as library calls. How money gets out covers the steps after that.

The ID is derived, so check it rather than trust it. Because a position ID is a hash of the collateral and the condition, a tool that computes it from the wrong collateral or the wrong condition gets a valid-looking ID that matches nothing. When a wallet shows no position where one should be, compare the token ID against the market's own listing before assuming the position is gone.

Where you will meet this

Cards in the catalogue whose own text uses the term.

Sources

  1. Conditional Tokens documentation, glossary and developer guide — Gnosis, read
  2. Polymarket CTF Exchange V2, repository README — Polymarket, read
  3. Polymarket Multi-Outcome Markets (neg-risk-ctf-adapter), README — Polymarket, read

Updated