Skip to main content

​
Protocol overview

Context is a prediction market protocol on Base. Four core contracts handle the onchain layer: MarketFactory manages markets and outcome tokens, Settlement matches and settles signed orders, and Holdings custodies user balances. All orders are signed offchain using EIP-712 and settled onchain in batches.

​
Contract addresses

ContractMainnet (Base 8453)Testnet (Base Sepolia 84532)
Settlement0x00000000008c286A2aaa99c6Be3b3D405A9295000xa9b830f4496b88c2d3C103fB96Df8f413031eBDD
Holdings0x0000000000CcA5bC44912C63d63e1673FeE923f60xBed9a1A6CB168D60aD2C7770Be6B62bD9244D6d3
Collateral tokenUSDC 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913USDC 0xBbee2756d3169CF7065e5E9C4A5EA9b1D1Fd415e
Permit20x000000000022D473030F116dDEE9F6B43aC78BA30x000000000022D473030F116dDEE9F6B43aC78BA3

​
Architecture

​
Core contracts

​
MarketFactory

Creates prediction markets and manages outcome tokens. Each market has a set of ERC-1155 outcome tokens (e.g., Yes and No) backed by USDC collateral. Key operations:
  • Mint complete sets — deposit USDC, receive one of each outcome token
  • Burn complete sets — return one of each outcome token, receive USDC back
  • Redeem — after resolution, burn winning tokens for their payout
  • Convert positions — in multi-binary markets, convert NO positions to YES positions (see negative risk)
MarketFactory also supports multi-binary markets — a parent market with multiple child binary questions where only one outcome can resolve YES.

MarketFactory reference

Full function signatures, read helpers, and events

​
Settlement

The execution layer. Receives matched orders from the fill signer and settles them onchain. Also provides Holdings-native mint/burn/redeem/conversion flows so users can perform token lifecycle operations without withdrawing from Holdings. Key operations:
  • Settle fills — execute matched orders (single or batch)
  • Cancel nonces — invalidate orders by canceling their nonce
  • Mint/burn/redeem from Holdings — perform token operations using Holdings balances

Settlement reference

Full function signatures, structs, and events

​
Holdings

A balance manager that custodies user ERC-20 tokens (USDC and outcome tokens). Users deposit funds, then authorize Settlement as an operator so it can transfer balances during order settlement. Key operations:
  • Deposit / withdraw — move tokens in and out
  • Deposit with Permit2 — gasless deposits using a Permit2 signature
  • Set operator — authorize Settlement to manage balances (required before trading)
  • Transfer — move balances internally between users

Holdings reference

Full function signatures and events

​
Order signing

Orders are signed offchain using EIP-712 typed data. The API handles submission and matching — you only need to sign and submit.

​
EIP-712 domain

{
  name: "Settlement",
  version: "1",
  chainId: <chain ID>,
  verifyingContract: <Settlement address>
}

​
Signed order (Settlement V2)

The unified order type for both limit and market orders. 
struct SignedOrder {
    bytes32 marketId;
    address trader;
    uint256 maxShares;          // max shares to sell (sell) or max shares output (buy)
    uint256 minSharesOut;       // min shares output
    uint256 maxCollateralIn;    // max collateral to spend (buy budget)
    uint256 minCollateralOut;   // min collateral output
    uint8 outcomeIndex;         // 0 = No, 1 = Yes
    uint8 orderKind;            // 0 = BUY, 1 = SELL_INVENTORY, 2 = SELL_NO_INVENTORY
    bytes32 nonce;              // unique per order, used for cancellation
    uint256 expiry;             // unix timestamp
    uint256 maxFee;             // max fee in token-native units, enforced pro-rata
    uint8 timeInForce;          // 0 = GTC (good-til-cancel), 1 = IOC (immediate-or-cancel)
    uint8 makerRoleConstraint;  // 0 = ANY, 1 = MAKER_ONLY, 2 = TAKER_ONLY
}
Order kinds:
  • BUY (0) — budget-native: spend up to maxCollateralIn, receive at least minSharesOut
  • SELL_INVENTORY (1) — sell from existing token inventory
  • SELL_NO_INVENTORY (2) — sell by minting from collateral budget

​
Signatures

Both EOA wallets (ECDSA) and smart contract wallets (ERC-1271) are supported. The Context SDK handles signing automatically. See the Settlement contract reference for the full V2 struct definitions.

​
Canceling orders

Orders are canceled by invalidating their nonce:
  • Direct — call settlement.cancelOwnNonce(nonce) onchain
  • Via signature — sign a CancelNonce(address trader, bytes32 nonce) message and anyone can submit it
  • Via API — use the API reference for the cancel order endpoints (recommended for most integrators)

​
Token mechanics

Outcome tokens are backed 1:1 by USDC collateral through a complete sets mechanism.
OperationInputOutputWhen
Mint1 USDC1 Yes + 1 No tokenAnytime
Burn1 Yes + 1 No token1 USDCAnytime
RedeemWinning tokensUSDC payoutAfter resolution
  • Minting — deposit collateral, receive one of each outcome token. Settlement can do this automatically from Holdings balances during order matching.
  • Burning — return a complete set (one of each token) to get your collateral back. Useful for exiting a position without selling on the orderbook.
  • Redemption — after a market resolves, burn your outcome tokens to receive USDC based on the payout percentages. For a binary market, winning tokens pay out 1 USDC each.

​
Negative risk

In multi-binary markets, only one outcome can resolve YES. This means holding multiple NO positions has built-in redundancy — at most one of your NO tokens will lose value. The protocol lets you convert this redundancy into collateral or YES positions.

​
Conversion formula

N NO tokens -> (M - N) YES tokens + (N - 1) USDC
Where M is the total number of outcomes and N is the number of NO positions you’re converting.

​
Conversion types

For a market with 4 outcomes:
TypeInputOutputDescription
Full exit4 NO0 YES + 3 USDCConvert all NOs to pure collateral
Concentrate3 NO1 YES + 2 USDCBet on one outcome + take profit
Balanced2 NO2 YES + 1 USDCPartial conversion
Swap only1 NO3 YES + 0 USDCTrade 1 NO for multiple YES tokens

​
How it works

Positions are specified using an indexSet bitmask where each bit represents an outcome. For example, in a 4-outcome market:
  • indexSet = 7 (binary 0111) = convert NO positions for outcomes 0, 1, and 2
  • indexSet = 3 (binary 0011) = convert NO positions for outcomes 0 and 1
Conversions are blocked if any child market has already resolved YES, preserving mutual exclusivity.
Most integrators interact with negative risk through the API rather than calling contract functions directly. The protocol handles conversions automatically when optimizing position management.

Common flows

Step-by-step examples for funding, trading, minting, redeeming, and converting positions