Development of Liquidity System for Prediction Markets
Polymarket in 2024 — $1.5 billion trading volume on presidential elections. But look at any "niche" market on the same Polymarket — bid-ask spread 10-15%, total liquidity $50k. This is where user experience breaks: user wants to bet $5000 on football match outcome, but slippage eats 8% before event even starts. The task of liquidity management system — make markets liquid before and independent of organic trader interest.
How AMM for Prediction Markets Works
LMSR and Its Limitations
Logarithmic Market Scoring Rule (LMSR) — historically first AMM for prediction markets. Outcome prices calculated via p_i = e^(q_i/b) / sum(e^(q_j/b)), where q_i is quantity of outcome i shares, b is liquidity parameter. Advantage: mathematically guaranteed market maker — market always liquid. Disadvantage: unlimited losses for market maker on extreme moves.
Later CPMM (Constant Product, like Uniswap v2) applied in Polymarket: for binary market YES_shares * NO_shares = k. YES price = NO_shares / (YES_shares + NO_shares). Simpler to understand and implement, losses bounded.
Conditional Tokens (ERC-1155)
Modern standard for prediction markets — Gnosis Conditional Tokens Framework. Each event outcome is separate ERC-1155 token. Collateral (e.g., USDC) locked in ConditionalTokens contract. Upon condition resolution (resolveCondition()), winning outcome token holders can redeem collateral 1:1.
This enables composite markets: combination of outcomes from multiple independent conditions — "AND-markets". For example, position "ETH > $5000 AND BTC > $100k by December" is intersection of two conditional tokens.
Liquidity Provisioning Architecture
Automated Market Making via Fixed Product AMM
For each market, deploy liquidity pool based on Fixed Product AMM (FPMM). LP deposits equal amounts of all outcomes (for binary market — YES and NO tokens). Initial outcome price = 50/50.
Contract FPMMFactory creates FPMM instance for each market:
function create(
address conditionalTokens,
address collateralToken,
bytes32[] memory conditionIds,
uint[] memory outcomeSlotCounts,
uint fee // basis points
) external returns (address fpmm)
Fee goes to liquidity providers — this is their incentive. Problem: prediction market fees usually small (0.1-2%), while risk for LP is significant. LP holds outcome positions until resolution. If market strongly one-sided (everyone bets YES) — LP essentially accumulates lots of NO, which may become worthless.
LP Incentive Mechanics
Simplest approach: liquidity mining — additional rewards in protocol token for LPs. But it's temporary; once mining ends, liquidity leaves.
More sustainable: dynamic fee — higher fee on low-liquidity markets, lower on competitive ones. Implementation: fee = base_fee + liquidity_adjustment, where liquidity_adjustment inversely proportional to pool depth.
Another pattern: shared liquidity pool — instead of per-market pools, single liquidity basket distributed across multiple markets. Contract automatically allocates liquidity where price impact highest. Risk diversified, capital efficiency higher.
Oracle Resolution and Dispute Mechanism
Most sensitive part — outcome resolution. Two approaches:
Centralized oracle. Trusted reporter address calls reportPayouts(). Fast, but centralized. For initial stage — acceptable with multisig reporter.
Optimistic oracle (UMA-style). Proposer proposes outcome with bond. 48-72 hours dispute window. Disputer can challenge with bond. If challenged — voting via UMA DVM or Kleros. Loser loses bond. Resistant to manipulation: cost of dispute > reward from wrong resolution.
Chainlink + Sports/Events API. For sports events — Chainlink Any API with verified sources (ESPN, official sports APIs). Declarative, automatic, no human factor. Limitation: not all events have public API.
Performance and Gas Issues
Prediction markets with many outcomes (>2) create gas problems. For event with 10 outcomes (e.g., world championship, 32 teams) — FPMM swap requires updating balances of all 32 tokens in single transaction. This is O(n) SLOAD/SSTORE operations on each trade.
Optimization: lazy evaluation — store only delta changes, recalculate full state only when needed (e.g., on redeem). But this complicates logic and requires careful invariant testing.
For markets with >5 outcomes on Ethereum mainnet — economically more sensible to deploy on Polygon or Base. L2 gas allows working with 20-30 outcome markets without issues.
Development Process
Analytics (3-5 days). Choose AMM mechanics (FPMM vs LMSR vs custom), oracle strategy, LP incentive model, target chain.
Contracts (2-3 weeks). Conditional tokens setup + FPMM factory + LP incentives + oracle adapters. Foundry with property-based tests: "sum of probabilities always = 1", "redeem never exceeds collateral".
Oracle integration (1 week). Chainlink API or UMA optimistic oracle setup, dispute mechanism.
Frontend (1-2 weeks). wagmi/viem integration, trading interface, probability display, LP dashboard.
Timeline Reference
Basic protocol for binary markets with centralised oracle — 1-2 weeks. Full system with optimistic oracle, LP incentives and multi-outcome support — 4-6 weeks.
Cost calculated after discussing market types and resolution mechanics.