Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Polymarket/ctf-exchange/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

The Registry mixin enables “binary matching” on the CTF Exchange by maintaining a mapping of token IDs to their complementary tokens and parent condition IDs. This is essential for matching buy orders of complementary tokens (via a “mint” operation) and sell orders of complementary tokens (via a “merge” operation). Binary matching assumes that two complementary tokens are always worth, in sum, 1 unit of underlying collateral. This is enforced by the CTF contract which allows minting and merging of full sets (complete collections of outcomes). Source: src/exchange/mixins/Registry.sol

​
Data Structures

​
OutcomeToken

struct OutcomeToken {
    uint256 complement;
    bytes32 conditionId;
}
Stores information about an outcome token:
  • complement: The token ID of the complementary token
  • conditionId: The parent condition ID from the CTF contract

​
State Variables

​
registry

mapping(uint256 => OutcomeToken) public registry
Mapping from token IDs to their OutcomeToken information, including complement and condition ID.

​
Functions

​
getConditionId

function getConditionId(uint256 token) public view override returns (bytes32)
Gets the associated condition ID for a token ID.

​
Parameters

  • token (uint256): The token ID to look up

​
Returns

  • bytes32: The parent condition ID of the token according to the registry

​
getComplement

function getComplement(uint256 token) public view override returns (uint256)
Gets the complementary token ID for a specified token ID.

​
Parameters

  • token (uint256): The token ID to get the complement for

​
Returns

  • uint256: The complement token ID

​
Requirements

  • The token must be registered (validated via validateTokenId)

​
validateComplement

function validateComplement(uint256 token, uint256 complement) public view override
Validates that a given complement ID matches the registered complement for a token.

​
Parameters

  • token (uint256): The token ID to check
  • complement (uint256): The suspected complement token ID

​
Reverts

  • InvalidComplement() if the complement doesn’t match the registered value

​
validateTokenId

function validateTokenId(uint256 tokenId) public view override
Validates that a token ID has been registered.

​
Parameters

  • tokenId (uint256): The token ID to validate

​
Reverts

  • InvalidTokenId() if the token is not registered (complement is 0)

​
_registerToken

function _registerToken(uint256 token0, uint256 token1, bytes32 conditionId) internal
Internal function to register a complementary token pair.

​
Parameters

  • token0 (uint256): The first token ID of the pair
  • token1 (uint256): The second token ID of the pair
  • conditionId (bytes32): The CTF condition ID for the pair

​
Requirements

  • token0 and token1 must not be equal
  • Neither token0 nor token1 can be zero
  • Neither token can already be registered

​
Emits

  • TokenRegistered(token0, token1, conditionId)
  • TokenRegistered(token1, token0, conditionId)
It is the responsibility of operators to register new outcome tokens with correct token IDs, complements, and condition IDs. All registrations assume binary outcomes that are valid in the context of the CTF contract.

​
Events

​
TokenRegistered

event TokenRegistered(uint256 indexed token0, uint256 indexed token1, bytes32 indexed conditionId)
Emitted when a token is registered. This event is emitted twice per registration (once for each token in the pair).

​
Parameters

  • token0 (uint256): The token being registered
  • token1 (uint256): Its complement token
  • conditionId (bytes32): The parent condition ID

​
Errors

​
InvalidComplement

error InvalidComplement()
Thrown when a complement validation fails.

​
InvalidTokenId

error InvalidTokenId()
Thrown when a token ID is invalid or not registered.

​
AlreadyRegistered

error AlreadyRegistered()
Thrown when attempting to register a token that has already been registered.

​
How Binary Matching Works

  1. Matching Buy Orders: When matching buy orders for tokens A and A’ (complements), the exchange can mint a full set from collateral, then distribute token A to one buyer and token A’ to the other.
  2. Matching Sell Orders: When matching sell orders for tokens A and A’, the exchange can receive both tokens, merge them back into collateral, and pay out the sellers.
  3. Finding Complements: The registry allows the exchange to quickly look up the complement of any token and its condition ID, which is required for the mint/merge operations on the CTF contract.

Build docs developers (and LLMs) love

Get started for freeTalk to us