> For the complete documentation index, see [llms.txt](https://docs.predict.fun/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.predict.fun/developers/technical-overview.md). # Technical Overview A technical overview of the Predict.fun protocol: the CLOB exchange, conditional token contracts, multi-outcome markets, oracle resolution, and yield. ### Predict.fun Protocol Technical Overview Predict.fun operates on a hybrid model combining decentralized and centralized components to deliver a secure and seamless prediction market trading platform. The system utilizes an off-chain Central Limit Order Book (CLOB) for order matching and ordering, while on-chain smart contracts handle the execution, settlement, and resolution of markets. #### Core Architecture **Conditional Tokens Framework** At the foundation of the system is the `ConditionalTokens` contract, adapted from the Gnosis Conditional Tokens standard. This contract manages the creation, interaction, and resolution of conditions linked to specific market outcomes. Key functions include: * Condition Preparation: Creates a condition by initializing a payout vector, where the oracle is enforced to be the message sender to prevent front-running attacks. * Position Splitting: Converts collateral into conditional tokens (ERC1155) representing different outcomes. * Position Merging: Combines complementary conditional tokens back into collateral. * Redemption: After condition resolution, token holders can redeem their positions according to the final outcome. The contract includes optional access-control gating via `SPLIT_POSITION_ROLE` and `MERGE_POSITIONS_ROLE` for granular permission management. **Exchange Layer** The `CTFExchange` contract facilitates on-chain execution and settlement of off-chain orders. When orders are matched, the contract handles swaps between binary outcome tokens (ERC1155) and collateral assets (ERC20). Orders are represented as signed, typed structured data (EIP712). The key trading operation is `matchOrders`, where the operator matches a taker order against multiple maker orders, with automatic minting/merging when matching buy-vs-buy or sell-vs-sell orders The `FeeModuleV2` acts as a proxy to the exchange, enabling dynamic fee calculations and refunds to ensure makers and takers pay only the actual fees determined at match time rather than worst-case fees encoded in orders. #### Multi-Outcome Markets (NegRisk System) For mutually exclusive multi-outcome markets—where exactly one outcome must resolve true—the protocol uses specialized "NegRisk" contracts: **NegRiskAdapter** The `NegRiskAdapter` links a set of binary YES/NO markets into a single multi-outcome structure with these key features: * Market Preparation: Creates a multi-outcome market * Question Preparation: Adds individual binary questions to a market * Wrapped Collateral: Uses a `WrappedCollateral` ERC20 token to represent collateral within the CTF system. Wrapped collaterals are backed by USDT. * Position Conversion: Enables conversion of NO positions to complementary YES positions plus collateral. For example, holding N NO positions can be converted to (N-1) units of collateral plus one of each complementary YES position. * Resolution Enforcement: Prevents more than one question per market from resolving true The `NegRiskCtfExchange` extends the base `CTFExchange` with automatic approvals for the `NegRiskAdapter`. **NegRiskOperator** The `NegRiskOperator` provides a permissioned layer for oracle operations: * Prepares markets and questions with unique request IDs * Receives outcome reports from a designated oracle * Supports flagging/unflagging questions for emergency resolution by admins #### Oracle System **UmaCompatibleCtfAdapter & UmaCompatibleOptimisticOracle** A streamlined oracle system for predict.fun with: * Whitelisted requestors for market creation * Whitelisted proposers for price proposals * No bonding or dispute mechanism (simplified trust model) * Valid prices: 0 (NO), 0.5 (50/50), 1 (YES) #### Yield Generation The protocol optionally generates yield on locked collateral through Venus protocol integration: **YieldBearingConditionalTokens** Extends the base ConditionalTokens with yield generation: * Deposits collateral to Venus vTokens when splitting positions * Redeems from Venus when merging or redeeming positions * Allows yield managers to claim accumulated yield * Can toggle yield generation on/off per underlying token **YieldBearingNegRiskAdapter & YieldBearingWrappedCollateral** Similar yield-bearing functionality for multi-outcome markets, with wrapped collateral that can generate yield through Venus while backing conditional token positions. **Yield-Bearing vs Non Yield-Bearing Markets** predict.fun has two sets of contracts. One set of contracts enables yield and another set of contract has no yield. Our backend monitors Venus USDT pool's utilization rate and stops yield-bearing markets from being created when the rate is too high. There is a max cap on allowed exposure and it decreases linearly from 75% (100% of the cap is allowed) to 90% (no more exposure is allowed except for existing markets) utilization rate. Instant redemption is of utmost importance to predict.fun and predict.fun does not put user deposit into a situation where redemptions fail. Each yield-bearing contract has an admin only function that allows the team to enable or disable the use of Venus. If the team deems the fund deposited into Venus is at risk, we will withdraw everything from Venus until any incident is resolved. predict.fun's backend has a configuration that specifies the max resolution time of a yield-bearing market. This allows us to control our max time exposure. The max resolution time will gradually increase and be eventually removed as predict.fun matures. In the future, predict.fun will integrate with multiple yield sources to diversify risks and provide better yield for traders.