> For the complete documentation index, see [llms.txt](https://docs.0y.world/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.0y.world/markets/what-is-0ys-lmsr/comparison.md).

# Comparison

How 0Y Compares to Alternatives

Before choosing LMSR, 0Y evaluated every major AMM pricing model. Here is how they compare against our specific requirements.

#### Feature Comparison

<table data-header-hidden><thead><tr><th width="141.59375"></th><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Pricing Model</strong></td><td><strong>Bounded Loss?</strong></td><td><strong>Sharp Bettor Safe?</strong></td><td><strong>Fast Markets?</strong></td><td><strong>Simple to Build?</strong></td><td><strong>Oracle Compatible?</strong></td></tr><tr><td><strong>LMSR</strong></td><td>Yes — always</td><td>High</td><td>Excellent</td><td>Yes</td><td>Native</td></tr><tr><td><strong>CPMM (x*y=k)</strong></td><td>No — unbounded</td><td>Low</td><td>Poor</td><td>Yes</td><td>Partial</td></tr><tr><td><strong>PMM (Proactive MM)</strong></td><td>Partial</td><td>Medium</td><td>Good</td><td>Medium</td><td>Required</td></tr><tr><td><strong>Limit Order Book</strong></td><td>No</td><td>Low (thin books)</td><td>Poor at launch</td><td>Complex</td><td>Partial</td></tr><tr><td><strong>Dynamic Parimutuel</strong></td><td>Yes — self-funded</td><td>Medium</td><td>Poor</td><td>Medium</td><td>Bolted-on</td></tr><tr><td><strong>P2P Matching</strong></td><td>No protocol risk</td><td>Low</td><td>Very Poor</td><td>Simple</td><td>None needed</td></tr><tr><td><strong>Parimutuel + TWAP</strong></td><td>Yes — pool-based</td><td>High</td><td>Medium</td><td>Medium</td><td>Required</td></tr></tbody></table>

#### Why We Rejected Each Alternative

**CPMM (x\*y=k) — What Uniswap Uses**

CPMM is the engine behind most DeFi liquidity pools. We actually launched with a version of this and it failed for our use case. The problem: there is no upper bound on losses. If users bet heavily on one side, the protocol's exposure grows without limit. For fast markets with AI bettors, this is catastrophic. We learned this the hard way.

**Limit Order Book — What Traditional Exchanges Use**

Order books work beautifully on Binance because millions of traders are active simultaneously. In a 1-minute prediction market with 50 users, there simply are not enough buyers and sellers to create a functioning book. The result: wide spreads, poor prices, frustrated users, and dead markets. Not viable at our current stage.

**Dynamic Parimutuel (DPM)**

DPM pools all bets and redistributes at resolution — similar to horse racing. The advantage is zero protocol risk. The fatal flaw for us: prices only truly resolve at the end. In a 1-minute market, users cannot see meaningful live odds movement. The product experience feels broken even when the math is fine.

**P2P Matching**

Pure peer-to-peer matching requires two willing counterparties for every bet. In thin markets, this means many users place a bet and wait — sometimes the entire 1 minute — without a match. This is unacceptable for a fast-market product. P2P might work as a premium feature for large positions in the future, but cannot be the core engine.

**Parimutuel + TWAP Hybrid**

This is a genuinely interesting model with very high manipulation resistance. We are using a version of this for our slow markets currently and will migrate to LMSR shortly (football, narrative events). But TWAP — Time Weighted Average Price — needs time to be meaningful. A 1-minute TWAP on a 1-minute market provides essentially zero manipulation protection. The model does not fit fast markets.

<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.0y.world/markets/what-is-0ys-lmsr/comparison.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
