Polymarket's Order Book vs On-Chain AMM Prediction Markets

The Core Split: Who Sets the Price?

Every prediction market design answers one question differently: what decides the odds on a YES share right now? Polymarket's CLOB answers with a matching engine, someone posts a bid, someone else lifts it, and the trade prints at whatever price both sides agreed to. LMSR-based platforms like Gnosis's original market maker contracts, or Augur's early experiments, answer with a formula instead: a cost function computes a price from the current inventory of shares, and every trade moves that inventory. One is a marketplace. The other is a vending machine with a price tag that updates itself.

That distinction cascades into gas costs, slippage, liquidity guarantees, and how much capital you need to bootstrap a market nobody's traded yet.

Polymarket's Hybrid CLOB

Polymarket doesn't run a fully on-chain order book. Nobody sane does; gas costs would make active market making unworkable. Instead, users sign EIP-712 typed orders off-chain and broadcast them to Polymarket's operator, which runs the actual matching engine. A resting limit order costs nothing until it fills. When two orders cross, the operator submits the match to the CTF Exchange contract on Polygon, which verifies both signatures, checks balances and allowances, and atomically swaps ERC-1155 conditional tokens for USDC. Settlement is non-custodial (the operator can match orders but can't move funds without a valid signature), but price discovery itself happens off-chain, in a system you can't audit block by block the way you can an AMM's bonding curve.

A simplified limit order looks like this:

{
  "salt": "8213...",
  "maker": "0xUserAddress",
  "signer": "0xUserAddress",
  "taker": "0x0000000000000000000000000000000000000000",
  "tokenId": "1298...conditional_token_id",
  "makerAmount": "50000000",
  "takerAmount": "100000000",
  "expiration": "0",
  "nonce": "0",
  "feeRateBps": "0",
  "side": "BUY",
  "signatureType": 0
}

That order sits in the book until matched or cancelled, no gas spent placing or pulling it. Resolution runs through UMA's Optimistic Oracle rather than a native dispute-token system: a proposer posts an answer, anyone can dispute it within a window by bonding collateral, and unresolved disputes escalate to UMA's DVM vote. That's a meaningfully different trust model from Augur's REP-staked reporting, and it's the part worth understanding before you build anything that depends on resolution timing.

LMSR and the AMM Generation

Gnosis's early prediction market stack, and the LMSR contracts Augur experimented with before settling on order books, used Robin Hanson's Logarithmic Market Scoring Rule. The cost function is simple enough to implement in an afternoon:

import math

def lmsr_cost(q, b):
    # q = outstanding shares per outcome, b = liquidity parameter
    return b * math.log(sum(math.exp(qi / b) for qi in q))

def price(q, b, i):
    denom = sum(math.exp(qj / b) for qj in q)
    return math.exp(q[i] / b) / denom

Every trade prices against this curve, not against another trader. That guarantees liquidity at any size, you're always quoted a price, even for the very first trade on a brand-new market. The tradeoff: someone has to fund the worst-case loss, bounded by b * ln(n) for n outcomes, before the market opens. Pick b too small and large trades blow through the curve with brutal slippage. Pick it too large and you've locked up capital that could be sitting in a market maker's inventory earning fees instead.

Augur, notably, never actually ran on an AMM in production. It used a fully on-chain order book matched via 0x, which meant every post, cancel, and fill cost real ETH gas. That killed liquidity depth long before REP governance disputes did. Gnosis's later product, Omen, moved to a Fixed Product Market Maker, the same x*y=k shape as Uniswap, built on top of Gnosis's Conditional Tokens Framework. That's the same CTF token standard Polymarket still uses today for issuing and redeeming YES/NO shares, even though it abandoned Gnosis's pricing curve entirely.

Where Each Model Actually Breaks

CLOB failure mode: dead books. A market with no active makers just sits there with a two-cent bid and a ninety-eight-cent ask, or no quotes at all. Depth exists only where a human or bot chose to place it. That's the same problem you'd hit market-making on any order-driven venue; the mechanics rhyme with running a maker bot against Hyperliquid's book, where quote presence is entirely on you, not the protocol.

AMM failure mode: capital lockup and price impact on size. A $50k trade against a thin LMSR curve moves the market 20+ cents even if the "true" probability hasn't budged, and someone had to pre-fund that loss exposure whether or not the market ever sees meaningful volume.

Both share: they're only as good as the oracle resolving them. A perfect matching engine or a perfectly tuned bonding curve is worthless if the resolution source is ambiguous or gameable, which is the actual hard problem in prediction markets.

Comparison Table

Dimension	Polymarket CLOB	LMSR / AMM (Gnosis, Omen)
Price discovery	Off-chain order matching	On-chain bonding curve
Settlement	On-chain, atomic, non-custodial	On-chain, atomic
Liquidity guarantee	None, depends on makers showing up	Always quoted, bounded by b
Gas per trade	Near-zero for makers, one tx per fill	One tx per trade, higher on L1
Slippage on size	Depends on book depth	Predictable, curve-defined
Capital to bootstrap	Zero, makers quote what they want	Must fund worst-case loss upfront
MEV / front-running surface	Matching engine, not public mempool	Public mempool, sandwichable
Resolution	UMA Optimistic Oracle	Varies (LMSR backer, Augur REP)

Which to Pick When

If you're building or trading on a platform meant for serious volume and tight spreads on popular markets, election odds, major sports, macro events, the CLOB wins outright. It's the same reason every serious perp venue moved off constant-product curves toward order books once volume justified the infrastructure; you can see the same execution-quality tradeoffs play out in how Jupiter routes swaps against Raydium's pools. Professional market makers can quote tight, and takers get real price improvement instead of paying a curve tax on every fill.

If you're building a long-tail platform with hundreds of niche markets that will never attract a dedicated market maker, a prop-betting app, an internal forecasting tool, anything where "always tradeable, even with one user" matters more than tight spreads, an AMM curve is still the more honest default. You're not gambling on liquidity showing up.

For teams actually building either one: a CLOB needs real infrastructure, low-latency market data feeds, signature verification, matching logic you'd want reviewed the way you'd review any latency-sensitive streaming data pipeline, plus bots capable of quoting continuously without getting picked off, a problem similar to running a Hyperliquid market-making strategy. An AMM needs careful curve parameterization and a clear-eyed view of worst-case loss before a market ever opens. Neither is solved by default. Get the architecture reviewed before committing capital or user funds to either shape, ideally in a strategy consultation that stress-tests the model against your actual expected order flow, not a spreadsheet.

If you're deploying a bot against Polymarket's book specifically, treat it like any other execution venue and land trades with intent, the same discipline that matters when landing trades reliably instead of racing public mempools.

Building a market maker or auditing one? Get your contracts and matching logic reviewed before real money sits on either side of the book.