> For the complete documentation index, see [llms.txt](https://praxis-4.gitbook.io/praxis/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://praxis-4.gitbook.io/praxis/documentation/advanced/prediction-market-amm.md).

# Prediction Market AMM

How AMMs solve the liquidity problem in prediction markets, rebuilt from first principles.

Prediction markets look simple from the outside: buy YES, buy NO, wait for the outcome. But under the hood, the hardest question is liquidity. Who is ready to trade with the user before the market becomes popular?

Here, we explore how AMMs can solve that problem. We start with the basic reason AMMs are useful for prediction markets, then look at how Polymarket's early AMM worked, and finally rebuild the same formula from a more intuitive idea: when a user buys one side, the market must lock enough value from the opposite side to pay them if they win.

The goal is not to explain a formula but to understand why it exists and what it tells us about building better prediction markets.

***

## Why AMMs Matter for Prediction Markets

Every prediction market needs liquidity. Without it, the market becomes passive: users place offers, wait for someone to take the other side, and often face poor prices or no execution at all.

You can think about market making as running a small exchange booth. A trader comes and asks: "Can I buy YES?" or "Can I sell NO?" For the experience to feel smooth, someone must always be ready to trade with them. In large markets, this role can be filled by professional market makers and active traders. But in small or niche markets, this is much harder.

Prediction markets have a long-tail problem. There may be thousands of possible events: elections, sports games, crypto prices, lawsuits, product launches, governance votes, and strange internet-native markets. Many of them are interesting, but not all of them will attract enough active traders. A CLOB can work beautifully for large markets, but for small markets the order book may be empty, thin, or too expensive to maintain.

This is where AMMs are powerful.

Instead of requiring an active market maker to constantly place and update orders, an AMM turns liquidity into a pool. Users trade against that pool directly, and prices update automatically according to a formula. This does not remove risk for liquidity providers and they still need to be compensated for taking the other side of trades but it makes the process much simpler.

For traders, the benefit is clear: the market is always open. They do not need to wait for another user to accept their offer. They can enter or exit a position immediately, even in a smaller or newer market.

That is the core strength of AMMs in prediction markets: they make liquidity available before the market is popular.

***

## How Polymarket's Early AMM Worked

Polymarket currently uses a CLOB — a central limit order book. But in its early version, Polymarket used an AMM. Understanding that old design is useful, because it shows one of the simplest ways to create liquidity for prediction markets.

The basic idea is simple: every market has two pools — YES tokens and NO tokens. The AMM keeps their product constant:

$$
Y \times N = k
$$

Where $$Y$$ is the YES reserve, $$N$$ is the NO reserve, and $$k$$ is the constant product.

When someone buys YES, they remove YES tokens from the pool and increase the NO side. When someone buys NO, the opposite happens. The formula automatically updates the price.

For a binary market, the price of YES is:

$$
p\_{\text{YES}} = \frac{N}{Y + N}
$$

And the price of NO is:

$$
p\_{\text{NO}} = \frac{Y}{Y + N}
$$

This may feel counterintuitive at first. If the pool has many YES tokens and fewer NO tokens, YES is cheap and NO is expensive. Why? Because buying YES means taking YES tokens out of the pool and leaving more NO exposure behind.

### A worked example

Suppose the market pool has:

| Reserve | Amount |
| ------- | ------ |
| YES     | 800    |
| NO      | 200    |

The constant product is $$800 \times 200 = 160{,}000$$. The current YES price is:

$$
\frac{200}{800 + 200} = 0.20
$$

So the market is pricing YES at 20% and NO at 80%.

Now imagine a user wants to buy YES for $10. We ignore fees for simplicity.

At first glance, you might think: if YES costs $0.20, then $10 should buy 50 YES tokens. But that is not exactly how an AMM works. As the user buys YES, the pool changes.

The user's $10 is first split into a complete set of YES and NO tokens. The pool keeps the NO side, while the user receives the purchased YES exposure.

1. The NO reserve increases from 200 to 210.
2. To keep the constant product unchanged, the YES reserve adjusts: $$Y' = \frac{160{,}000}{210} = 761.90$$
3. The user receives: $$800 + 10 - 761.90 = 48.10$$ YES tokens

| State        | YES reserve | NO reserve | YES price |
| ------------ | ----------- | ---------- | --------- |
| Before trade | 800.00      | 200.00     | 20.00%    |
| After trade  | 761.90      | 210.00     | 21.61%    |

The user's average execution price is $$10 / 48.10 = 0.208$$, or about 20.8%.

| Price type              | YES price |
| ----------------------- | --------- |
| Starting price          | 20.00%    |
| Average execution price | 20.80%    |
| Final price after trade | 21.61%    |

This is slippage. The user did not buy the entire position at the starting price of 20%. Their own trade moved the market. The price started at 20%, ended at 21.61%, and the user received an average price between those two values.

This is the core logic of AMM pricing. The larger the trade relative to the pool, the more the price moves. If the pool has low liquidity, even a small trade can create meaningful slippage. If the pool has deep liquidity, the same trade barely moves the price, and the user gets an execution price much closer to the current market price.

At settlement, the logic becomes simple again. If YES wins, each YES token is redeemable for $1. If YES loses, each YES token becomes worth $0. The AMM is only responsible for pricing trades before the outcome is known.

***

## Building an AMM from Scratch

Before looking at the formula directly, let's try to build an AMM from first principles.

Imagine a simple prediction market with two side reserves:

* $$A$$ — YES-side reserve
* $$B$$ — NO-side reserve

The current YES price is $$A / (A + B)$$. For a 20% YES market:

| Side           | Reserve |
| -------------- | ------- |
| YES side $$A$$ | 200     |
| NO side $$B$$  | 800     |

$$\frac{200}{200 + 800} = 20%$$

This is the same market as before, just written from the other perspective. Previously, we looked at token reserves: many YES tokens, few NO tokens. Here, we look at side reserves: small YES-side stake, large NO-side stake.

### The key question

If a user pays $10 to buy YES at around 20%, who pays the rest if they win?

At a 20% price, $10 buys roughly 50 YES tokens. If YES wins, those tokens are worth $50. But the user only paid $10. The remaining $40 must come from somewhere.

**It must be locked from the opposite side of the market.**

This is the core intuition. When a user buys YES:

1. Their deposit increases the YES side.
2. Some amount is locked from the NO side.
3. That locked amount is what makes the user's potential payout possible.

### Deriving the locked amount

After a user deposits $$d$$, the YES side becomes $$A + d$$. How much should be locked from the NO side?

If the user receives $$q$$ YES tokens at average execution price $$p$$, then:

$$
q = \frac{d}{p}
$$

The AMM only needs to lock the profit part — the user already contributed $$d$$:

$$
\text{locked} = q - d = \frac{d}{p} - d = d \left(\frac{1}{p} - 1\right)
$$

We don't know the exact average price yet. As a working estimate, after the user adds $$d$$ to the YES side, the updated YES ratio becomes:

$$
p' = \frac{A + d}{A + B + d}
$$

Using this estimated price, the locked amount becomes:

$$
d \cdot \frac{B}{A + d}
$$

So after the trade:

$$
A' = A + d \qquad B' = B - \frac{d \cdot B}{A + d}
$$

### Worked example

With $$A = 200$$, $$B = 800$$, and $$d = 10$$:

$$
p' = \frac{210}{1010} = 20.79%
$$

The user receives $$10 / 0.2079 = 48.10$$ YES tokens. If YES wins, the AMM needs to lock $$48.10 - 10 = 38.10$$ from the NO side.

| State                       | YES side $$A$$ | NO side $$B$$ | YES price |
| --------------------------- | -------------- | ------------- | --------- |
| Before trade                | 200.00         | 800.00        | 20.00%    |
| After deposit, before lock  | 210.00         | 800.00        | 20.79%    |
| After locking opposite side | 210.00         | 761.90        | 21.61%    |

| Price type              | YES price |
| ----------------------- | --------- |
| Starting price          | 20.00%    |
| Average execution price | 20.79%    |
| Final price after trade | 21.61%    |

***

## Wait — Did We Just Rebuild Polymarket's AMM?

Let's compare the two results.

We derived the lock-based formulas from the intuition: *when a user buys one side, the AMM locks part of the opposite side to fund their potential payout*. We never started from the constant-product formula. But the numbers are identical.

Let's verify this algebraically.

**Starting from the constant-product AMM** with the translation $$A = N$$, $$B = Y$$ (our side reserves map to the token reserves in reverse):

When the user buys YES for $$d$$:

$$
N' = N + d \qquad Y' = \frac{YN}{N + d}
$$

User receives:

$$
\text{YES out} = Y + d - Y' = Y + d - \frac{YN}{N+d} = \frac{d(Y + N + d)}{N + d}
$$

Average execution price:

$$
p\_{\text{avg}} = \frac{d}{\text{YES out}} = \frac{N + d}{Y + N + d}
$$

Substituting $$A = N$$ and $$B = Y$$:

$$
p\_{\text{avg}} = \frac{A + d}{A + B + d}
$$

That is exactly the estimate we used.

**Checking the final reserves:**

Our lock-based formula gives $$B' = B - dB/(A+d)$$. Substituting $$A = N$$ and $$B = Y$$:

$$
Y' = Y - \frac{dY}{N + d} = \frac{YN}{N + d}
$$

Which is exactly the constant-product result. And the invariant holds:

$$
Y' \times N' = \frac{YN}{N+d} \times (N+d) = YN = k
$$

{% hint style="success" %}
Both models describe the same mechanism from two different perspectives. The constant-product formula is a clean mathematical encoding of the same locking logic: when a user buys YES, the AMM locks opposite-side funds to guarantee the potential payout.
{% endhint %}

The constant-product formula can feel abstract when presented as $$Y \times N = k$$. The lock-based explanation gives a more intuitive reason for why it works. The formula is not arbitrary — it is the natural result of asking: *if this user wins, where does the extra payout come from?*

The answer is: from the opposite side of the pool.

***

## Why Polymarket Moved to a CLOB — and What It Means for Praxis

Prediction markets need liquidity before they can become useful. In the early stage, this is hard: there may be few traders, markets may be niche, and users do not want to wait for someone else to take the other side of their trade. This is where AMMs shine.

But as markets grow, the tradeoff changes.

{% columns %}
{% column %}
**AMM — best for early markets**

* Always quotes a price, even with zero order flow
* Passive liquidity provision — just deposit, no active quoting
* Ideal for small and newly-created markets with thin organic flow
  {% endcolumn %}

{% column %}
**CLOB — best for mature markets**

* Capital efficiency — market makers concentrate liquidity near current prices
* Tighter spreads for large trades
* Works well once sufficient order flow arrives
  {% endcolumn %}
  {% endcolumns %}

The transition mirrors what happened in DeFi. Uniswap V2 used a full-range constant-product curve. Uniswap V3 kept the AMM model but introduced concentrated liquidity: LPs can choose the exact price ranges where they want to provide liquidity. In practice, this makes AMM liquidity more flexible and more orderbook-like, while still preserving the simplicity of a pool-based system.

This is also how we think about Praxis.

At the early stage, AMMs are the right tool. They give every market immediate liquidity, make the user experience simple, and allow Praxis to support long-tail prediction markets from day one. Users should be able to enter a market without thinking about whether there is enough order book depth.

Over time, if some markets become large enough, Praxis can evolve toward a more hybrid structure: AMM-based liquidity for bootstrapping and long-tail markets, and more CLOB-like or range-based liquidity for mature markets where active market makers can improve pricing and capital efficiency.

{% hint style="info" %}
Praxis does not need to choose between AMM and CLOB as a fixed ideology. The best path is phased: use AMMs where they create the most value, and introduce more advanced liquidity structures when the market is ready for them.
{% endhint %}

***

## Related

* [Prediction Markets](/praxis/documentation/how-it-works/prediction-markets.md) — a user-friendly introduction to how prediction markets work on Praxis
* [2 Pools](/praxis/documentation/advanced/two-pools.md) — how YES/NO pool mechanics interact with the PT/YT liquidity layer
* [Mathematical Foundations](/praxis/documentation/strategies-and-guides/mathematical-foundations.md) — formal derivations of the formulas above