A prediction market needs an engine that does one job: turn an order to buy or sell into a price. There are two answers in production today — LMSR (a logarithmic market-scoring rule, an automated market maker invented for prediction markets) and the central limit orderbook (the same model that runs every stock exchange). They look like they solve the same problem; they don’t.

Most of the writing online treats this as an “LMSR is for cold start, orderbook is for scale” cliché and stops there. The reality is more interesting and worth understanding before you commit to one — switching engines after launch breaks every UX assumption your traders have built.

This is a working engineering comparison from teams who’ve shipped on both sides. Math where it matters. Opinions at the end.

What LMSR actually does

The Logarithmic Market Scoring Rule was published by Robin Hanson in 2002 to solve a specific problem: small prediction markets have no liquidity at the start, so prices can’t form. If you list “Will the Fed cut rates in March?” as a Yes/No market and the first trader wants to bet $100 on Yes, who do they trade against?

LMSR’s answer is to invent a counterparty — a deterministic cost function the market quotes against on every trade. For a binary Yes/No market, the cost function is:

C(q_yes, q_no) = b · ln(exp(q_yes / b) + exp(q_no / b))

Where q_yes and q_no are the total quantities of Yes and No shares outstanding, and b is the liquidity parameter. The price of buying one Yes share is the partial derivative of C with respect to q_yes:

P(yes) = exp(q_yes / b) / (exp(q_yes / b) + exp(q_no / b))

The price of a No share is symmetric, and the two prices always sum to 1. That’s the only invariant that matters: prices behave like probabilities by construction.

The b parameter is what most engineers underestimate. It’s the maximum loss the market maker is willing to accept, given by b · ln(2) for a binary market. If you set b = $1000, the worst-case loss is about $693 — and the market is liquid enough that a $100 trade barely moves the price. If you set b = $50, every $20 trade lurches the price 10 points and traders complain. Picking b is not a parameter; it’s a financial decision about how much capital you’re willing to subsidize the market with.

The tradeoff: LMSR will always quote a price, even with zero traders. Spreads are zero (a buy and immediate sell only loses the price-impact differential, not a market-maker spread). The market maker is the protocol — it’s deterministic, never offline, doesn’t ask permission. You don’t need professional MMs to bootstrap the market.

In exchange: the protocol’s capital is locked in b. If you list 10,000 markets each needing b = $500, that’s $5M in subsidy. And the price moves on the next trade based on a curve, so there’s no “depth at this level” — you’re always at the curve.

What orderbooks actually do

A central limit orderbook (CLOB) is what every stock and crypto exchange runs. Sellers post asks (“I’ll sell 100 Yes at 65¢”), buyers post bids (“I’ll buy 100 Yes at 64¢”), and the matching engine pairs them when prices cross. The market price is wherever the most recent trade happened, or the midpoint of the best bid/ask.

There’s no cost function. There’s no protocol-as-counterparty. There’s only other traders.

This is why orderbook prediction markets feel different to a trader: you can place a limit order at any price you want, you can see the depth (10,000 contracts at 64¢, 5,000 at 63¢), and the spread tells you something true about how confident the market is. A 1¢ spread means deep liquidity. A 10¢ spread means thin.

The tradeoff: orderbooks need professional market makers to bootstrap. Day one of a new market with no MMs and no traders is just an empty book. The first user can’t trade. Liquidity providers need to be incentivized — usually with rebates (“we’ll pay you to post bids and asks”) or with the platform itself running an MM bot. Kalshi did this. Polymarket eventually moved to a hybrid (more on that below).

Orderbooks are also more prone to flash dislocations. A whale dumps 10,000 shares into a thin book and the price gaps from 65¢ to 40¢ in a single trade. Recovers in seconds, but every UI screenshot during that window shows the dislocation. LMSR can’t gap — the curve is continuous.

Where LMSR wins

  1. Long-tail markets. A platform listing 500 obscure questions (“Will Tunisia join BRICS by 2027?”) has no chance of attracting MMs to each one. LMSR makes every market tradeable from second one. This is why Augur, early Polymarket, and PredictIt-style markets used LMSR.

  2. Cold-start UX. Visitors don’t see “no orders yet — be the first.” They see a price (50/50 by default for a fresh binary market) and a spread of zero. They can trade. The market discovers a real price as flow comes in.

  3. No MM dependency. You don’t need to find, vet, and pay professional market makers. The cost function is the market maker. For a small team without exchange relationships, this matters.

  4. Predictable max loss. The protocol knows exactly how much it can lose on any market: b · ln(N) where N is the number of outcomes. For risk and treasury planning this is much cleaner than orderbook MM where losses are uncapped and event-driven.

Where orderbooks win

  1. Real liquidity reflects real conviction. A trader posting a $50,000 limit bid at 67¢ is making a real market signal. LMSR has no equivalent — there’s no “depth at 67¢”; there’s just the curve. For institutional flow, orderbook is the only credible mechanism.

  2. Tight spreads at scale. Once a market has MMs competing, spreads collapse to a penny or less. LMSR spreads are effectively zero for a single share but get worse fast as size grows (price impact compounds along the curve). A $100k order on LMSR will move the price more than the same order on a deep orderbook.

  3. Capital efficiency. Orderbook MMs can move their capital between markets dynamically based on edge. LMSR locks capital in each market for its lifetime. For a platform with thousands of simultaneously-active markets, that’s a 100× difference in capital intensity.

  4. Standard tooling. Every quant, MM, and HFT firm already speaks orderbook. They have FIX, REST, WebSocket libraries ready. Onboarding a professional MM to your LMSR market means custom integration. To your orderbook market: usually a config file.

  5. Resolution dynamics. As an event approaches resolution, traders want to size up or hedge out. Orderbooks let you ladder out cleanly with limit orders. LMSR forces you to take the curve’s price impact on the way out.

How production markets actually solve this

The interesting thing is what happens after launch.

Augur (2018) launched LMSR-only. It hit the cold-start advantage but struggled with capital efficiency at scale and the price-impact problem on large trades.

Polymarket launched with an LMSR-style AMM (FPMM — Fixed Product Market Maker, conceptually similar) and migrated in 2022 to a hybrid CLOB + AMM model. Limit orders match against each other when crossable, and against the AMM curve when they’re not. This gives you orderbook liquidity in popular markets, AMM availability in long-tail markets, and seamless UX where traders never know which engine filled their order.

Kalshi launched orderbook-only with the platform itself running market-making algorithms across every contract until external MMs arrived. CFTC-regulated, so they had the relationships to make this work.

PredictIt (now winding down) used LMSR with a fee skim — interesting because the fee meant the protocol was net profitable on most markets, paying for the b subsidy.

What we’d actually build today

For most teams listing fewer than 200 simultaneously-active markets and without exchange relationships:

Start with LMSR. Bootstrap simple, tradeable from launch, predictable risk. Add a CLOB layer later for your top 10 markets where flow justifies it.

For teams with institutional ambitions, regulatory cover, or exchange-MM relationships:

Start with orderbook. Pay for an MM bot in the early days, set up rebates aggressively, and accept that long-tail markets will be illiquid until you have organic flow.

For teams listing 1,000+ markets across long-tail categories:

Hybrid from day one. LMSR provides the floor for everything; CLOB layers on top for popular markets. Polymarket’s architecture is the reference. The complexity is real but unavoidable.

Three things people get wrong when picking:

  1. Thinking LMSR is “decentralized” and orderbook is “centralized” — they’re independent of where the matching runs. You can have a fully on-chain orderbook (dYdX v3) and you can have a centralized LMSR. The mechanism and the deployment are orthogonal.

  2. Underestimating b. Cheaping out on the liquidity parameter to save capital makes the market unusable — every trade lurches the price, traders give up, the market dies and you’ve lost a different way. Better to list fewer markets with adequate b than many markets with thin curves.

  3. Ignoring the resolution UX. Whatever engine you pick, the moments before settlement are the loudest part of the user experience. Make sure you’ve thought through how trading shuts down (close X minutes before resolution? on oracle finalization? halted manually?), how late-arriving orders are handled, and what happens to limit orders that never filled. The engine choice doesn’t free you from this.

The decision tree

  • Are you listing fewer than 50 markets at a time? → LMSR.
  • Do you have professional MM relationships and regulatory air cover? → Orderbook.
  • Are most of your markets going to be long-tail and illiquid? → LMSR.
  • Are most of your markets going to be high-volume and standardized? → Orderbook.
  • Are you listing thousands of markets across both? → Hybrid CLOB + AMM.

If you’re building a prediction market and want a sanity check on the engine choice, the b calibration, the oracle design, or the settlement edges — we’d love to talk. We’ve shipped on both sides and the differences are real but learnable.