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

# AMM Risks

AMMs are a suitable structure for providing immediate liquidity so that transactions can be concluded without interruption, even when the initial user base is small or there are insufficient counterparties.

The first model to emerge when introducing AMMs in prediction markets was the LMSR AMM. \
The biggest difference between LMSR and the CPMM used in existing DEXs lies in how the two tokens are interpreted.

* **CPMM**: Completely independent assets
* **LMSR**: Complementary outcomes for a single event, such as a Yes/No share (outcome)

As a result, while CPMMs simply set prices based on the proportion of assets in the pool, LMSR automatically adjusts the cost function so that the sum of all outcome prices remains 1 (=100%) regardless of changes in trading volume. Because of this, LMSR is closer to an “AMM dedicated to prediction markets.”

Prediction market protocols are not satisfied with LMSR, and are introducing various AMM designs tailored to their purposes, rather than relying solely on pure LMSR, to reduce gas costs and simplify the structure.

As a representative example, LP-based FPMM (CPMM variant model) is a widely used method because it has a simpler computational structure and lower gas costs than LMSR.

Furthermore, some protocols adopt a Pure Bonding Curve model, which generates prices using a single Bonding Curve without any LPs themselves, thereby minimizing on-chain state management and operational complexity.

However, regardless of the formula used, prediction markets that process swaps with on-chain AMMs carry the same risk of slippage and sandwich attacks as existing DeFi AMMs.

### DeFi AMM(CPMM) vs PM AMM(LMSR)

<table><thead><tr><th width="162.9296875">Assortment</th><th>DeFi AMM (CPMM)</th><th>PM AMM (LMSR / FPMM)</th></tr></thead><tbody><tr><td>Design Purpose</td><td>Exchange between independent assets (swap)</td><td>Outcome probability-based pricing</td></tr><tr><td>Asset structure</td><td>Uncorrelated assets like ETH–USDC</td><td>A set of complementary outcomes for a single event (Yes/No, A/B/C)</td></tr><tr><td>Meaning of price</td><td>Asset exchange rate</td><td>probability of an event occurring</td></tr><tr><td>Pricing method</td><td><code>x * y = k</code> Curve-based (CPMM)</td><td>Cost function-based, such as LMSR and FPMM</td></tr><tr><td>Price constraints</td><td>None (0 ~ ∞)</td><td>Probability sum = 1</td></tr><tr><td>Price correlation</td><td>Both prices can rise or fall simultaneously. <br>→ No probabilistic constraints.</td><td>If one goes up, the other will inevitably go down. <br>→ Maintaining consistency in probability.</td></tr><tr><td>Liquidity sensitivity</td><td>Price volatility is high in low liquidity environments.</td><td>Smooth probability adjustment even with small liquidity</td></tr><tr><td>Prediction Market Suitability</td><td>Low — structurally uninterpretable probability</td><td>Very High — Designed exclusively for prediction markets</td></tr></tbody></table>

### Slippage issue

AMM-based prediction markets have the advantage of being able to execute trades without liquidity gaps, but slippage exists as a structural element because prices fluctuate continuously with each trade.

The following pages detail why slippage verification is required, how it should be enforced on-chain, and how slippage failure can lead to real-world attacks.

### Permanent Loss

In a typical decentralized exchange (DEX) AMM environment, liquidity providers experience "impermanent loss (IL)" due to price fluctuations. This is because losses can be recovered if the token price recovers, and because the market is not forcibly closed, losses are not necessarily guaranteed.

However, prediction markets, which utilize AMMs, present a different situation. All markets inevitably resolve, and the price (0 or 1) and position at that point determine the final profit or loss. In other words, providing liquidity in prediction markets carries with it the structural risk of "permanent loss," beyond price fluctuations.

The following pages analyze the specific mechanisms by which these permanent losses occur, along with mathematical formulas, to provide a detailed explanation of the risks ordinary users must assume as market makers.

### Fee bypass

{% hint style="info" %}
**If you understand "Permanent Loss - Unequal market state", it will be more easily understanding this page.**
{% endhint %}

This vulnerability arises from the flow processed by PM's AMM liquidity provide. If the market meets the three conditions below, it can take a poistion without incurring fees:

* The market must be unequal (a situation where the ratio of yes to no value is different).
* Anyone should be able to provide liquidity.
* There is no logic to assign a fee to Sell among Buy and Sell, which are either Yes or No shares.

This page explains how liquidity providers can suffer asset losses due to Permanent Loss if fee payment logic is not properly implemented.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://funarchy.gitbook.io/funarchy/security-for-prediction-market/trading-mechanism/amm-risks.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.