Skip to main content

​
Protocol overview

Context is a prediction market protocol on Base. Three 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 (Base Sepolia)

ContractAddress
Settlement0xCB6CBCb87fe36Dd48b08930867C8D1E5fDDeE251
Holdings0x3A81C17a9bf6D5d425fbF67C4BE8aA279f8F6F95
MarketFactory0x333271eB9a252F3CCc5fd9e6026B09C717Df01d5
ResolutionTimelock0x9fE68A1595C049B54b797B599dAac90A60A94F91
TUSD0xBbee2756d3169CF7065e5E9C4A5EA9b1D1Fd415e

​
Architecture

​
Core contracts

​
MarketFactory

Creates prediction markets and manages outcome tokens. Each market has a set of ERC1155 outcome tokens (e.g., Yes and No) backed by TUSD collateral. Key operations:
  • Mint complete sets — deposit TUSD, receive one of each outcome token
  • Burn complete sets — return one of each outcome token, receive TUSD 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 (e.g., “Who will win the election?” with candidates A, B, C, D).

​
Settlement

The Settlement contract is the execution layer. It receives matched orders from the fill signer and settles them onchain. 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 balances held in the Holdings contract
  • Deposit with Permit2 — mint complete sets using a gasless Permit2 signature

​
Holdings

A balance manager that custodies user ERC20 tokens (TUSD 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)

​
ResolutionTimelock

Adds a time delay to market resolution. Resolutions are proposed, wait through a timelock period, and can be canceled or replaced before execution.

​
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>
}

​
Limit order (Order struct)

The standard order type. Sits on the book until filled or canceled. 
struct SignedOrder {
    bytes32 marketId;
    address trader;
    uint256 price;          // 0 to 10^decimals (6 for TUSD)
    uint256 size;           // in collateral token decimals
    uint8 outcomeIndex;     // 0 = first outcome (usually Yes)
    uint8 side;             // 0 = Buy, 1 = Sell
    bytes32 nonce;          // unique per order, used for cancellation
    uint256 expiry;         // unix timestamp
    uint256 maxFee;         // max fee in token-native units, enforced pro-rata
    uint8 makerRoleConstraint;      // 0 = ANY, 1 = MUST_BE_MAKER, 2 = MUST_BE_TAKER
    uint8 inventoryModeConstraint;  // 0 = ANY, 1 = REQUIRE_HAS_INVENTORY, 2 = REQUIRE_NO_INVENTORY
}

​
Market order (MarketOrderIntent struct)

Fills immediately at the best available price. Uses maxPrice as a price ceiling (for buys) or floor (for sells). 
struct MarketOrderIntent {
    bytes32 marketId;
    address trader;
    uint256 maxSize;        // maximum total size to fill
    uint256 maxPrice;       // for buys: max price, for sells: min price
    uint8 outcomeIndex;
    uint8 side;             // 0 = Buy, 1 = Sell
    bytes32 nonce;
    uint256 expiry;
    uint256 maxFee;         // max total fee across all fills
}

​
Signatures

Both EOA wallets (ECDSA) and smart contract wallets (ERC-1271) are supported. The Context SDK handles signing automatically — see the orders module for usage.

​
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 cancel endpoint (recommended for most integrators)

​
Token mechanics

Outcome tokens are backed 1:1 by TUSD collateral through a complete sets mechanism.
OperationInputOutputWhen
Mint1 TUSD1 Yes + 1 No tokenAnytime
Burn1 Yes + 1 No token1 TUSDAnytime
RedeemWinning tokensTUSD 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 TUSD based on the payout percentages. For a binary market, winning tokens pay out 1 TUSD 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) TUSD
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 TUSDConvert all NOs to pure collateral
Concentrate3 NO1 YES + 2 TUSDBet on one outcome + take profit
Balanced2 NO2 YES + 1 TUSDPartial conversion
Swap only1 NO3 YES + 0 TUSDTrade 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.