> 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/zh/shi-chang/what-is-0ys-lmsr/comparison.md).
# 对比
0Y 与其他方案的对比
在选择 LMSR 之前，0Y 评估了所有主流的 AMM 定价模型。以下是它们在我们具体需求下的对比。
#### 功能对比
| | | | | |
|---|
| 定价模型 | 亏损有上限？ | 能防范老练交易者？ | 适合快速市场？ | 易于构建？ | 兼容预言机？ |
| LMSR | 是——始终有上限 | 高 | 非常好 | 是 | 原生支持 |
| CPMM（x*y=k） | 否——无上限 | 低 | 差 | 是 | 部分 |
| PMM（主动做市） | 部分 | 中 | 好 | 中 | 必需 |
| 限价订单簿 | 否 | 低（订单簿稀薄） | 上线初期差 | 复杂 | 部分 |
| 动态彩池 | 是——自筹资金 | 中 | 差 | 中 | 后期附加 |
| P2P 撮合 | 无协议风险 | 低 | 非常差 | 简单 | 不需要 |
| 彩池 + TWAP | 是——基于资金池 | 高 | 中 | 中 | 必需 |
#### 我们为什么放弃其他方案
**CPMM（x\*y=k）——Uniswap 使用的模型**
CPMM 是大多数 DeFi 流动性池背后的引擎。我们最初确实用过它的一个版本，但它并不适合我们的场景。问题在于：亏损没有上限。如果用户大量押注某一边，协议的风险敞口会无限增长。对于有 AI 下注者参与的快速市场来说，这是灾难性的。我们是吃过亏才明白的。
**限价订单簿——传统交易所使用的模型**
订单簿在币安上运作得非常好，因为同时有数百万交易者在活跃交易。但在一个只有 50 名用户的 1 分钟预测市场里，根本没有足够的买家和卖家来形成有效的订单簿。结果就是：点差很大、价格很差、用户沮丧、市场冷清。在我们目前的阶段并不可行。
**动态彩池（DPM）**
DPM 把所有下注汇入资金池，在结算时重新分配——类似赛马。它的优点是协议零风险。但对我们来说，致命缺陷是：价格只有在最后才真正确定。在 1 分钟市场中，用户看不到有意义的实时赔率变化。即使数学上没问题，产品体验也会让人觉得出了故障。
**P2P 撮合**
纯点对点撮合要求每一笔下注都有两个愿意交易的对手方。在交易稀薄的市场里，这意味着很多用户下注后只能等待——有时等完整整 1 分钟也匹配不到。这对快速市场产品来说是不可接受的。将来 P2P 也许可以作为大额仓位的高级功能，但不能作为核心引擎。
**彩池 + TWAP 混合模型**
这是一个确实很有意思的模型，抗操纵能力非常强。我们目前在慢速市场（足球、叙事类事件）中使用它的一个版本，很快会迁移到 LMSR。但 TWAP（时间加权平均价格）需要足够的时间才有意义。在 1 分钟市场上使用 1 分钟 TWAP，基本上起不到任何防操纵作用。这个模型并不适合快速市场。
---
# 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/zh/shi-chang/what-is-0ys-lmsr/comparison.md?ask=&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.