Skip to main content
Polymarket represents tradeable outcomes as ERC-1155 balances. Every binary market has a YES position and a NO position, but the contract that owns those balances depends on the market’s position system.

​
Positions Ledgers

Do not send a CTF token ID to PositionManager or a Position ID to Conditional Tokens. Market discovery provides the identifiers required by each workflow.

​
Position Lifecycle

Both systems expose the same basic position lifecycle.

Split

Convert pUSD into a YES and NO token pair.

Merge

Convert a YES and NO token pair back into pUSD.

Redeem

Exchange resolved outcome tokens for their payout.

​
Token Flow

pUSD can be split into YES and NO outcome tokens, which can be traded, merged, or redeemed after resolution.pUSD can be split into YES and NO outcome tokens, which can be traded, merged, or redeemed after resolution.

​
CTF

Conditional Tokens owns the outcome balances. Each outcome token has a unique CTF position ID, used as its ERC-1155 token ID. CTF computes it onchain in three steps.
1

Compute the Condition ID

2

Compute the Collection IDs

The indexSet is a bitmask identifying which outcome slots belong to a collection. It must be a nonempty proper subset of the condition’s outcome slots. A binary market has one collection for each outcome.
3

Compute the Position IDs

The resulting position IDs are the ERC-1155 token IDs for the market’s YES and NO outcomes. Most integrations should read these token IDs from market data. Computing them manually is only necessary for direct contract integrations.
For a binary condition, index set 1 identifies YES and index set 2 identifies NO. Market data returns the resulting token IDs, so most integrations do not need to derive them.

​
Polymarket Protocol V2

PositionManager owns every outcome balance and routes each Position ID to its registered module. The module ID is encoded in the Position ID.

​
Position ID

A Position ID is the ERC-1155 token ID for a Polymarket Protocol V2 outcome. Its 256 bits encode the module, condition, and outcome that define the position. The first byte identifies the owning module, and the last byte identifies the outcome, with 0 for YES and 1 for NO. Treat the complete Position ID as an opaque decimal string in application code.
The 256-bit position ID, split into moduleId, baseHash, arity, reserved, resolutionChain, conditionIndex, and outcomeIndex fields
The Router is the public entry point for splits, merges, redemptions, and module-specific position operations. A split requires pUSD approval for the Router. A merge or redemption requires PositionManager approval for the Router.

​
Negative Risk and Combos

Negative-risk events link several outcomes so a NO position can be converted into the complementary YES positions. The two systems implement that behavior through different contracts. See Negative Risk Markets for the event model. Combos use PositionManager and the CombinatorialModule. Each leg is a Polymarket Protocol V2 Position ID from the BinaryModule or NegRiskModule. The resulting Combo is still a binary-shaped YES and NO pair, which allows it to use Exchange v3. See Combinatorial Positions for the Combo position model.

​
Contract Addresses

See Contracts for Polymarket’s current smart contract addresses on Polygon.