Traditional prediction markets put a central authority between you and the outcome. They hold user funds. They control who can create markets. They decide when settlement happens. That’s a lot of trust to place in a single entity.
Blockchain technology enables decentralised prediction markets where positions are tokenised, settlement happens automatically through oracles, and no central authority controls your funds. Two primary architectures handle this. Ethereum‘s Conditional Token Framework using ERC-1155 tokens on Polygon. And Solana‘s SPL token approach through DFlow‘s Prediction Markets API.
This guide is part of our comprehensive prediction market fundamentals resource, where we explore technical implementation details for developers building blockchain-based market infrastructure. You get trustless infrastructure for building prediction markets with programmatic position management, oracle integration patterns, and composability with DeFi protocols.
What Are the Core Smart Contract Patterns for Prediction Markets?
Prediction market smart contracts implement three core patterns: market creation where you define conditions and outcomes, position management where you split collateral into outcome tokens and merge them back, and settlement execution where oracles verify outcomes and trigger payout distribution.
Market contracts serve as coordinators that interface with token contracts like ERC-1155 or SPL, oracle systems like UMA, and collateral management modules. They orchestrate the pieces rather than doing everything themselves.
The tokenisation logic is straightforward. Markets use condition-based tokenisation where 1 unit of collateral splits into complete sets of outcome tokens. Put in 1 USDC for a binary market, get 1 YES token and 1 NO token back. YES and NO shares always sum to $1.00, creating deterministic payoff structures and eliminating counterparty risk.
When opposing orders match, the platform mints matching outcome tokens while holding the collateral. This forces the market to remain balanced—every YES token in circulation has a corresponding NO token, and together they’re backed by exactly $1 of collateral.
Markets move through defined lifecycle states. Created when you define the condition. Active when users can trade. Resolved when the oracle reports the outcome. Settled when winning positions are redeemed.
State transitions happen based on specific triggers. Market creation transitions to Active when you enable trading. Active becomes Resolved when the oracle callback confirms the outcome. Resolved transitions to Settled as users redeem their winning positions. Each state restricts which operations are valid—you can’t redeem positions until the market is Resolved, and you can’t create new positions after settlement begins.
The UMA Prediction Market contract enables creation of binary prediction markets using Optimistic Oracle V3 assertions to handle these state changes through a callback mechanism.
You need reentrancy protection during split, merge, and redemption operations. Those token transfers create attack surfaces. There’s a window where your contract has updated balances but hasn’t finished the transfer. A malicious contract can exploit that window to drain funds.
Access control matters too. Only authorised oracle addresses should trigger settlement transitions. Lock your collateral properly and verify complete set integrity throughout the lifecycle. Token accounting errors compound quickly in financial systems.
How Does the Conditional Token Framework Enable Position Tokenisation?
The Conditional Token Framework is Gnosis’s smart contract system that tokenises prediction market positions by converting collateral into ERC-1155 outcome tokens. It uses a hierarchical ID system. conditionId identifies the unique market, collectionId specifies the outcome collection, and positionId becomes the tradeable token ID.
One contract manages everything. A single ConditionalTokens contract deployed at fixed addresses handles all markets. On Ethereum mainnet that’s 0xC59b0e4De5F1248C1140964E0fF287B192407E0C. You don’t deploy new contracts per market—you register your markets with this shared infrastructure.
Polymarket uses ERC-1155 tokens through CTF, which enables multiple token types within a single contract. This is more efficient than deploying separate ERC-20 contracts for every outcome token.
Each market needs three parameters. The questionId structures the query to the oracle as a bytes32 hash. For UMA compatibility, this typically includes a timestamp and the question text. The outcomeSlotCount is always 2 for binary markets but can be 3 or higher for multi-outcome predictions. And the Oracle Address—typically UMA’s optimistic oracle.
The ID derivation follows a hash-based pattern that creates unique identifiers for each component. Your conditionId = keccak256(oracle, questionId, outcomeSlotCount). The collectionId = keccak256(parentCollectionId, conditionId, indexSet). The positionId = keccak256(collateralToken, collectionId). Each hash builds on the previous one, creating a hierarchy that prevents collisions even across thousands of markets.
Index sets use bit arrays to track which outcomes you hold. For binary markets, one outcome maps to 0b01 and the other to 0b10. This bit representation lets you efficiently encode complex outcome combinations in multi-outcome markets where you might hold tokens representing “outcome A OR outcome B” as a single position.
Splitting is your entry point. Users deposit collateral, typically USDC, and receive equal amounts of all outcome tokens. The framework maintains 1:1 value backing.
Merging provides your exit before settlement. Market sentiment shifts and you want out? Merging lets you burn a complete set of outcome tokens and recover your collateral. You don’t wait for the event to occur or the oracle to resolve the outcome. This is valuable when you’ve changed your view on a prediction but don’t want to sell your tokens on the secondary market.
The merge operation requires you to hold one token for each possible outcome—the complete set. Burn them together and get your collateral back. The framework also supports redemption after settlement, where you burn only the winning outcome tokens to claim the full collateral amount.
The framework deploys across multiple networks. Beyond Ethereum mainnet, you’ll find it on xDai and various testnets. Use whichever network matches your deployment strategy and gas cost tolerance.
How Do ERC-1155 and SPL Token Standards Compare for Prediction Markets?
ERC-1155 was developed to address inefficiencies in previous token standards. It enables creation of fungible, non-fungible, and semi-fungible tokens all within a single smart contract. That’s powerful for prediction markets where you need multiple outcome tokens per market across potentially thousands of markets.
The standard supports batch transfers, allowing multiple token types to move in a single transaction. This reduces gas costs and increases transaction speed. Instead of three separate transactions to transfer three different outcome tokens, you do it in one.
Safe transfer checks ensure tokens go to compatible addresses, preventing losses from sending to incorrect destinations. The standard verifies the receiving address can handle ERC-1155 tokens before completing the transfer.
On Solana, DFlow’s Prediction Markets API provides SPL Tokens where positions are actual tokens giving you onchain ownership. The architectural approach differs from Ethereum’s shared contract model. SPL creates individual token accounts per user per position, following Solana’s account-based architecture rather than Ethereum’s contract storage patterns.
Gas costs vary dramatically across platforms. Ethereum mainnet split and merge operations cost $20-100 during congestion. Polygon reduces that to $0.01-0.10. Solana typically stays under $0.001. If you’re building for users who make frequent trades, those differences compound quickly. These are transaction costs for position management—deployment costs follow different patterns we’ll cover in the deployment section.
The architectural approaches create different trade-offs. ERC-1155 uses a single contract with token ID mapping. Every outcome token for every market lives in one contract, which simplifies integration but creates a central point of complexity. SPL‘s individual token accounts distribute the state across the blockchain, following Solana’s parallel processing model.
Developer experience differs too. Solidity for Ethereum means working in a mature ecosystem with extensive tooling and familiar JavaScript-adjacent syntax. Rust for Solana gives you Solana’s performance characteristics but requires learning systems programming patterns and Solana’s account model.
DFlow uses Concurrent Liquidity Programs as their liquidity mechanism. Users define intent onchain through limit orders. Liquidity providers observe these intents offchain and fill them at or better than the limit price. The protocol then mints SPL tokens representing the filled positions. This hybrid approach keeps expensive order matching offchain while maintaining onchain settlement and token custody.
Once positions become SPL tokens, they gain Solana DeFi composability—you can use them with DEXs, lending protocols, and other DeFi primitives through standard SPL token interfaces.
How Should You Implement Market Creation and Position Minting?
Market creation follows three conceptual phases. First you prepare the condition by defining your oracle source, creating a unique question identifier, and specifying how many possible outcomes exist. Then you register this condition with your token framework, locking in the resolution mechanism. Finally you enable position minting so users can deposit collateral and receive outcome tokens.
The condition preparation phase establishes the market’s identity and resolution path. Your question identifier needs to uniquely represent what you’re predicting. For UMA-compatible oracles, this means structuring a bytes32 hash that encodes the question text, relevant timestamps, and any ancillary data the oracle needs to verify the outcome. Getting this format right matters because the oracle uses it to fetch and validate resolution data.
For multi-outcome markets beyond simple binary YES/NO predictions, the outcome slot count determines how many distinct tokens the split operation creates. Set it to 3 for three-way markets like “Team A wins / Team B wins / Draw”. Set it to 4 or higher for markets with more possible outcomes. Each outcome gets its own tradeable token.
The condition registration phase connects your market to the token framework. For CTF-based systems, this means calling the preparation function on the shared ConditionalTokens contract. You’re not deploying a new contract—you’re adding your market’s condition to the registry maintained by the framework.
Position minting handles the collateral-to-token conversion. The framework defines partition arrays that specify how to distribute collateral across outcome tokens. For a simple binary market, the partition array indicates equal distribution—1 unit of collateral becomes 1 unit of each outcome token.
Users go through a standard approval flow before minting positions. They approve the market contract to spend their collateral tokens, then call the split function specifying how much they want to convert. The framework transfers the collateral, mints the outcome tokens, and sends them to the user’s address.
Initial price discovery happens when the first trades occur. When buy orders for opposite outcomes match at complementary prices totalling $1, the market creates new share pairs while collecting collateral. This bootstraps liquidity without requiring a central market maker to provide initial positions.
On Solana through DFlow, the process differs architecturally. Users submit order intents onchain expressing their desired positions and limit prices. Liquidity providers operating offchain observe these intents and decide whether to fill them. When a fill occurs, the protocol mints SPL tokens representing the user’s position. You’re working with an API that abstracts the token minting rather than calling smart contract functions directly.
How Do Smart Contracts Integrate with Oracle Systems for Outcome Resolution?
UMA’s Optimistic Oracle enables prediction markets to finalise outcomes through a verification process combining economic incentives with decentralised dispute resolution. It assumes honesty by default. Proposed outcomes remain valid unless someone challenges them. For a complete exploration of different oracle design patterns, including centralised versus decentralised approaches, see our dedicated oracle architecture guide.
The resolution workflow moves through clear stages. The market closes to new positions when the event concludes. An oracle proposer submits the outcome backed by a bond, typically $750. If unchallenged within the dispute window—usually 2 hours—the proposal automatically finalises. Total timeline from event to final settlement typically runs 2-4 hours for undisputed outcomes.
Your market contract submits a data request to the Optimistic Oracle specifying what needs verification and when. A proposer reviews the real-world outcome, posts their answer along with the required bond, and starts the dispute timer.
During the liveness period, anyone can dispute by posting a counter-bond. Disputes escalate to UMA’s Data Verification Mechanism where UMA tokenholders vote on the correct outcome. The losing party forfeits their bond, creating proper incentive alignment.
Because CTF and UMA were developed independently, platforms like Polymarket created adapter contracts to bridge them. The UMA-CTF Adapter fetches resolution data from UMA and converts it into the payout vector format that CTF expects. When UMA finalises an outcome, the adapter calls CTF’s report function with the appropriate payout structure—[1,0] for YES wins or [0,1] for NO wins.
The first dispute automatically resets the market, sending out a fresh oracle request. If the request gets disputed again, the Optimistic Oracle escalates to UMA’s DVM. That voting process takes 48-72 hours.
Your smart contract implements a callback interface to receive outcome data from the oracle. This callback triggers the payout vector assignment that determines which outcome tokens are worth 1 unit of collateral and which are worth 0.
The dispute mechanism needs proper economic calibration. Bond sizes should be large enough to make frivolous disputes expensive but not so large that legitimate challengers can’t afford to participate.
What Security Best Practices Apply to Prediction Market Smart Contracts?
Prediction market security requires protecting against reentrancy attacks during token operations, implementing strict access control for settlement functions, preventing oracle manipulation through economic guarantees, and running third-party audits before mainnet deployment. For comprehensive analysis of smart contract security best practices including market manipulation detection and case studies of real-world vulnerabilities, review our security implementation guide.
Reentrancy protection comes first. During token transfers, a malicious contract’s receive function executes. If your state updates happen after the transfer, that malicious contract can re-enter your function and exploit the stale state. Use the checks-effects-interactions pattern where you update all state before making external calls. OpenZeppelin’s ReentrancyGuard provides a battle-tested implementation.
Access control locks down settlement functions. Settlement and outcome reporting must restrict calls to authorised oracle addresses only. OpenZeppelin’s AccessControl provides a foundation for this.
The clearinghouse functions that handle collateral transfers need protection against parameter manipulation. Check token balances before and after transfers. Validate that collateral amounts match the tokens being minted or burned.
Oracle security needs careful economic calibration. Larger bonds make manipulation more expensive but can exclude legitimate participants if set too high. Understanding oracle manipulation prevention techniques helps you design robust bond and dispute mechanisms.
Collateral accounting requires precision. Prevent double-redemption where a user could claim their winnings multiple times. Ensure complete set integrity—the total supply of each outcome token should always match for a given market.
If you’re using upgradeable contracts through proxy patterns, understand the storage collision risks. Consider whether you really need upgradeability or if immutability provides better security guarantees.
Testing strategies should cover the financial logic thoroughly. Fuzz testing randomly generates inputs to find edge cases in your split, merge, and redemption functions. Test oracle integration with simulated timeouts, disputes, and resolution failures.
Third-party security audits are required before production deployment. The Polymarket UMA-CTF Adapter contracts were audited by OpenZeppelin. Focus your audit on token accounting logic, collateral management, and oracle integration points.
How Can Prediction Market Tokens Compose with DeFi Protocols?
Tokenised prediction market positions integrate with DeFi protocols through standard token interfaces. This enables several use cases. You can provide liquidity in automated market makers by pairing outcome tokens with stablecoins. You can use outcome tokens as collateral in lending protocols. You can create yield strategies through outcome token farming.
For liquidity provision in AMMs, outcome tokens pair with stablecoins in pools on Uniswap v3 for Ethereum or Orca for Solana. Traders swap between YES and NO positions while liquidity providers collect fees.
The impermanent loss dynamics differ from typical AMM pools though. As outcomes become clearer, one side of your LP position moves toward $1 while the other approaches $0. The LP fees need to compensate for that structural impermanent loss.
Lending integration presents both opportunities and challenges. Platforms like Aave on Ethereum or Solend on Solana could accept outcome tokens as collateral for borrowing stablecoins. This enables leverage on prediction positions.
Collateral valuation creates problems for lending protocols. How do you value an asset that might go to $1 or $0 based on a binary outcome? Prediction markets can flip from $0.70 to $0.10 in minutes on breaking news. Liquidation mechanisms need to account for this volatility.
Wrapped token patterns can extend composability. Some DeFi protocols only support ERC-20 tokens, not ERC-1155. Wrapping ERC-1155 outcome tokens into individual ERC-20 contracts provides compatibility at the cost of additional deployments.
On Solana, outcome tokens work with Jupiter aggregator for optimal routing, Solend for lending, and Orca for liquidity provision using standard SPL patterns.
AMM-based liquidity provision in decentralised prediction markets faces impermanent loss exposure, operational losses for market makers, transaction costs, and manipulation vulnerabilities in low-liquidity markets. These aren’t theoretical concerns.
Most successful decentralised platforms have shifted to offchain market makers that operate similarly to centralised platforms. They use the blockchain for settlement and token custody but keep order matching and liquidity provision offchain where it’s more efficient.
What Are the Deployment Workflows for Ethereum and Solana Prediction Markets?
Ethereum deployment follows a clear path. You write Solidity contracts defining your market logic. Test locally using Hardhat or Foundry. Deploy to testnets like Goerli or Mumbai. Get your contracts audited. Deploy to mainnet or Polygon for production. Verify your source code on Etherscan. Integrate your frontend with ethers.js or viem.
CTF integration requires no deployment of the core token framework. Use the existing ConditionalTokens contract already deployed on your target network. Your custom contracts call CTF functions for split, merge, and redemption operations.
Testing approaches should cover your contract logic thoroughly. Unit tests verify split and merge functions. Integration tests validate interaction with the deployed CTF contracts. Forked mainnet testing lets you test against the real CTF and UMA oracle deployments without spending real money.
Frontend integration connects your web interface to the blockchain. Set up ethers.js or viem to communicate with Ethereum nodes. Implement wallet connection through MetaMask or WalletConnect. Read CTF state to show users their positions. Construct transactions for split, merge, and redemption.
Cost considerations vary by network. Ethereum mainnet contract deployment costs $500-5000 in gas fees. Polygon reduces deployment costs to $1-10. Using existing CTF infrastructure eliminates deployment costs entirely—you only pay transaction fees for market creation, around $0.01 on Polygon.
Solana follows a different path. Write Rust programs using the Anchor framework. Test with Solana Test Validator running locally. Deploy to devnet for testing. Get audited. Deploy to mainnet-beta for production. Verify your program on Solana Explorer. Integrate your frontend with @solana/web3.js.
Solana deployment typically costs under $5. The Anchor framework simplifies program structure and testing.
DFlow’s Prediction Markets API provides complete infrastructure that handles smart contract operations through API calls. All Kalshi markets are available as tokenised markets on Solana through this API. You handle API authentication, call market creation endpoints, mint positions through API requests, and implement webhooks for settlement notifications. For detailed guidance on working with these APIs and comparing implementation approaches, see our developer community resources.
Monitoring and maintenance continue after deployment. Index blockchain events to track market state changes. Monitor oracle callbacks to detect resolution delays. Implement error handling for failed transactions.
Set up alerting for unexpected conditions. Track gas costs. Monitor contract balances to detect drainage attempts. Watch for oracle manipulation attempts on high-value markets.
Building decentralised prediction markets with smart contracts requires understanding multiple technical layers from token standards to oracle integration. This guide covered the core patterns for Ethereum and Solana implementations. For a complete overview of the prediction market ecosystem including platform comparisons, regulatory considerations, and business opportunities, explore our comprehensive prediction market guide.
FAQ
What programming languages do I need to build prediction markets?
Solidity for Ethereum-based markets using CTF and ERC-1155 tokens on Polygon. Rust for Solana-based markets using SPL tokens and Anchor framework. JavaScript or TypeScript for frontend integration with web3 libraries—ethers.js for Ethereum, @solana/web3.js for Solana.
Can I build prediction markets without deploying my own smart contracts?
Yes. Integrate with Gnosis’s deployed CTF contracts on Ethereum and Polygon rather than deploying your own token infrastructure. Or use DFlow’s Prediction Markets API on Solana which handles all smart contract operations through their API, requiring only frontend development. Find more smart contract code examples and documentation resources in our developer guide.
How much does it cost to deploy a prediction market?
Deployment costs vary by platform. Ethereum mainnet runs $500-5000 in gas fees. Polygon reduces this to $1-10. Solana typically stays under $5. Using existing CTF infrastructure eliminates deployment costs—you only pay transaction fees for market creation, around $0.01 on Polygon.
What’s the minimum collateral required to create a prediction market?
No minimum exists at the protocol level. CTF and SPL implementations support arbitrary collateral amounts. Practical minimums depend on gas costs and liquidity requirements. Binary markets typically start with $100-1000 in initial liquidity to enable meaningful trading.
How long does oracle settlement take for prediction markets?
UMA Optimistic Oracle has a 2-hour dispute window after outcome proposal before settlement can finalise. Total timeline from event occurrence to final settlement typically runs 2-4 hours for undisputed outcomes. Disputed outcomes that escalate to UMA’s DVM voting process take 48-72 hours.
Can prediction market outcome tokens be transferred between users?
ERC-1155 outcome tokens implement standard transfer functions enabling peer-to-peer transfers, DEX trading, and composability with DeFi protocols. SPL tokens on Solana similarly support transfers through standard SPL token program instructions.
What happens to losing outcome tokens after settlement?
Losing tokens become worthless after settlement. Payout vectors set winning positions to 1 and losing positions to 0. Users can burn losing tokens but receive no collateral. Only winning outcome holders receive payouts when they redeem their tokens.
How do I handle multi-outcome markets beyond binary YES/NO?
CTF supports arbitrary outcome counts through the outcomeSlotCount parameter. Set to 3 or higher for multiple outcomes. Split operations create complete sets of all outcome tokens—outcomeSlotCount of 4 creates 4 different outcome tokens from 1 collateral unit. Index sets use bit arrays to represent which outcomes you hold.
What are the gas optimisation strategies for prediction market contracts?
Batch operations using ERC-1155’s batch transfer functions reduce gas costs by combining multiple token movements into one transaction. Minimise storage writes by using events for historical data. Leverage existing CTF deployment instead of deploying per-market contracts. Use Polygon or Solana for dramatically lower transaction costs.
Can I create prediction markets with conditional outcomes?
Yes. CTF’s name comes from supporting conditional tokens where outcomes depend on multiple conditions. Implement nested conditions by using outcome tokens from one market as collateral for another market, creating complex conditional logic trees. This advanced pattern requires careful ID management.
How do I prevent market manipulation in decentralised prediction markets?
Implement minimum liquidity requirements to resist wash trading. Use UMA’s bond and dispute mechanisms to prevent oracle manipulation. Set appropriate settlement delays allowing dispute periods. Monitor for suspicious trading patterns. Larger bond sizes for high-stakes markets increase manipulation costs.
What’s the difference between Polymarket’s approach and DFlow’s approach?
Polymarket uses Ethereum’s CTF with ERC-1155 tokens deployed on Polygon with UMA Optimistic Oracle for settlement, creating fully decentralised markets where you can deploy custom market questions. DFlow uses Solana’s SPL tokens with Concurrent Liquidity Programs to tokenise Kalshi’s regulated markets, bridging centralised market creation with decentralised token infrastructure.
