Prediction markets are simple to describe and unforgiving to build. Users buy shares in outcomes (“Will X happen by Y date?”), prices move toward the market’s collective probability estimate, and at resolution one side gets paid out. The hard parts — the parts where teams get stuck — are pricing under thin liquidity, oracle settlement under contested outcomes, and operational handling of edge cases that look like they should never happen but always do.

We’ve worked on prediction-market infrastructure across a few flavors (sports, geopolitics, crypto). This is the architecture we’d start from if we were building a Polymarket-style market today, and the failure modes we’d be planning for from day one.

The pricing engine: LMSR vs CFMM

Two main pricing primitives dominate prediction markets.

LMSR (Logarithmic Market Scoring Rule) is the academic reference design. It uses a cost function to compute the price of a share given the current market state. It’s bounded-loss (the market maker can’t lose more than a fixed amount) and provides liquidity even with no participants. The downside: it’s a market-maker design, which means the protocol is providing liquidity, which means somebody has to fund that liquidity.

CFMMs (Constant Function Market Makers, à la Uniswap) apply the AMM pattern to prediction outcomes. Each outcome is a token; an AMM pool holds reserves of each. Prices come from the pool’s invariant. Liquidity is provided by users who deposit reserves and earn fees.

Polymarket runs CFMM-style with concentrated liquidity. We’d recommend the same architecture for new builds in 2026. The reasons:

  • Liquidity-provider incentives are clean (LPs earn fees on volume, just like in DeFi).
  • The market is permissionless to make — anyone can spin up a new market and seed it.
  • Concentrated liquidity (Uniswap v3-style) lets LPs target the price ranges where they think the market is mispriced, dramatically improving capital efficiency over uniform liquidity.

The LMSR approach is simpler to reason about academically but harder to scale operationally because the protocol is on the hook for the liquidity.

Oracle design is the protocol

Pricing is interesting; settlement is where prediction markets succeed or fail.

A prediction market resolves at the end of its lifecycle: the question is answered, one outcome wins, holders of the winning outcome’s shares are paid out. The mechanism that determines “what’s the answer” is the oracle, and getting it wrong has consequences far beyond getting any other oracle wrong. A bad price oracle costs LPs money. A bad settlement oracle decides who wins and loses millions of dollars in a binary, irreversible way.

Three patterns we’d consider for serious markets:

Optimistic oracle (UMA-style). Anyone can propose an answer; anyone can dispute it within a window. Disputes go to a voting process (token-weighted, in UMA’s case). This works well when the answer is clearly determinable from public information. It struggles on truly contested events.

Multi-source aggregator. The protocol pulls answers from multiple data providers (Chainlink, custom feeds, news APIs) and resolves based on consensus. Robust against any single source being wrong; vulnerable to systematic biases across all sources.

Curated resolver with social fallback. A trusted party (the protocol, a designated council, etc.) resolves the market. Disputed resolutions can be escalated to a slower, more deliberative process. Easier to operate, harder to scale to permissionless markets.

The right answer depends on the market category. Sports outcomes are uncontested and well-suited to multi-source aggregation. Political outcomes are sometimes uncontested (“did event X happen on date Y?”) and sometimes contested (“did the count exceed N?”); optimistic oracles handle these reasonably. Highly subjective markets shouldn’t really be on-chain in the first place.

The lifecycle nobody documents well

A prediction market goes through five states, and most of the operational complexity lives in the transitions between them:

  1. Created. Market is proposed but not yet trading.
  2. Trading. Liquidity is in, users are buying and selling outcome shares.
  3. Closed. Trading is paused; resolution is pending.
  4. Resolved. The outcome is determined; payouts are claimable.
  5. Disputed. Resolution is contested; payouts are frozen pending resolution.

The transitions between these states are where bugs live.

The Trading → Closed transition needs to handle in-flight orders gracefully. If a user submits a buy order at the exact moment the market closes, what happens? You don’t want the order to land in a closed market and become stuck capital. The clean pattern: closed markets accept zero new orders but refund any in-flight ones.

The Closed → Resolved transition needs a defined waiting period. Even with a fast oracle, you want a buffer where the resolution can be challenged before payouts go out. Polymarket-style markets typically have a 24-hour challenge window. Shorter is dangerous; longer makes the market less useful.

The Disputed state is where serious thought is required. Frozen payouts need to remain frozen until the dispute resolves. The dispute resolution process needs to be deterministic and auditable. Users need clear UI showing why their payouts are frozen and when to expect resolution. Most market failures we’ve seen happen here.

Liquidity bootstrapping

A new prediction market with no liquidity is useless. Users won’t trade because the spread is too wide; LPs won’t seed because there’s no volume. The classic chicken-and-egg.

Two patterns that work:

Protocol-seeded liquidity. The protocol provides the initial liquidity for new markets out of a treasury, then withdraws as third-party LPs come in. This puts the protocol on the hook for inventory risk, which is non-trivial. The protocol either needs market-making expertise in-house or needs to pair with an external market maker.

Subsidized LP fees. New markets pay enhanced LP rewards (in protocol token, in fees, etc.) to attract initial liquidity. This works if your protocol token has value to LPs; it doesn’t work if you’re trying to bootstrap from zero.

Most successful prediction markets use a combination: protocol-seeded for the first few weeks, then transition to LP-driven as the markets find product-market fit.

Failure modes you’ll see

A short list of things that will happen and that your system should be ready for:

  • An oracle resolves a market incorrectly. Have a dispute window, and have a clear process for what happens during a dispute.
  • A market gets created on a question that turns out to be ill-posed (“will X happen by Y” but X is ambiguously defined). Have a void/refund mechanism that returns capital to participants without picking a winner.
  • A whale moves the price during the final minutes before close. This is unavoidable in any market; the design choice is whether to disclose order flow, batch the final moments into an auction, or accept it.
  • Payouts get stuck because of a smart contract bug. Have an emergency pause that doesn’t require governance and that’s well-documented in advance so users don’t panic.
  • The legal question of what your prediction market is. Talk to a lawyer in your jurisdiction before you talk to a smart contract engineer. The number of prediction-market projects shipped without legal review and then quietly shut down is non-trivial.

A pragmatic build

For a serious prediction-market protocol from scratch, we’d budget:

  • 2 senior smart contract engineers, 4–5 months for the AMM, lifecycle, and oracle integration.
  • 1 senior backend engineer for keeper services, oracle aggregation, monitoring, 3 months.
  • 1 product/front-end engineer, 4 months for the trading UI and resolution UX.
  • Audit budget: $100–200k, 4–6 weeks calendar.
  • Legal and compliance work: variable, but it’s not zero.

If you’re scoping a prediction market or a market-making product on top of one, we’d be glad to walk through the architecture.