Polymarket合约功能分析

快速导航

核心概念 - 预言机、AMM、订单簿基础
架构设计 - Polymarket 的5大模块与流程
合约分析 - GitHub 代码结构与复用性评估
MVP 规划 - 最小化产品设计与团队配置
开发路线 - 12 周分阶段实现计划

核心概念速查

Chainlink 是什么？

Chainlink 是一个去中心化预言机网络（Decentralized Oracle Network）。

区块链智能合约不能直接访问链外数据（例如：天气、汇率、股票价格）。Chainlink 就是解决这个问题的桥梁。

它通过一个由许多独立节点组成的网络，从现实世界或其他 API 拉取数据，再把结果提供给链上的智能合约。

例如： - DeFi 协议需要 ETH/USD 价格时，会通过 Chainlink 预言机来获取可靠报价 - NFT 游戏可以用它来获取现实天气、随机数、比赛结果等数据

Uniswap 是什么？

Uniswap 是一个基于以太坊的去中心化交易所（DEX）。它让用户可以直接在钱包里互相交换代币，而不需要中心化交易所（比如 Binance、Coinbase）。Uniswap 的交易通过智能合约自动完成，背后没有人托管你的资产。

关键机制：

AMM（自动做市商）

传统交易所有”买单”和”卖单”，而 Uniswap 用的是自动做市商算法（AMM）。

它有一个简单的公式：x * y = k
其中： - x 是池子里的代币 A 数量 - y 是池子里的代币 B 数量 - k 是常数

当有人用代币 A 去买代币 B，池子的比例就会变化，从而自动决定价格。

流动性提供者（LP）

任何人都可以往交易池里同时存入两种代币（比如 ETH 和 USDC），成为”流动性提供者”，赚取交易手续费。

Uniswap V2 和 V3 的区别？

V2 是”全区间 AMM”，V3 是”高资本效率、可调参数的专业级 AMM”。V3 在性能与效率上是 V2 的 20～4000 倍提升。

核心概念差异：

1. LP 流动性差异

V2：全区间流动性

在 Uniswap V2 中，所有流动性都分布在 0—∞ 的价格范围，大部分价格区间永远不会被用到。例如：ETH/USDC 市场中，ETH 不可能涨到 10 亿美金，但也不可能跌到 0.0000001 美金，但 LP 却必须在整个范围提供流动性。结果：资本效率极低，流动性比较差。

V3：集中流动性（自定义价格区间）

在 Uniswap V3 中，LP 可以自己选择：”我要在价格 2500–3000 USDC/ETH 之间提供流动性。” 这使得：资本集中在交易活跃的价格带，少量资金即可制造深度，LP 可以根据市场设置不同区间策略。结果：这带来了几十倍到上千倍的资本效率。

2. LP 自身的差异

V3 中流动性是 NFT，而不是 ERC20 Token，因为每个 LP 的价格区间不同，因此 LP 的仓位是”独一无二”的。在 V2 中，你得到同质化 ERC-20 LP Token；在 V3 中，你得到不可替代 NFT Position。结果：让 V3 更像”专业做市工具”。

3. LP 手续费等级可控

V2：统一 0.30%
V3：0.05%（蓝筹稳定币等低波动）、0.30%（大多数代币）、1%（高风险代币）

结果：这让 LP 能针对不同风险选择不同收益区。

4. 改进的 TWAP 预言机

V3 让预言机更加便宜、准确，并允许 DApp 使用： - 过去 10 分钟平均价格 - 过去 1 小时平均价格 - 或任何时间窗口的价格

并且 V3 的 Gas 消耗比 V2 更低。

实测资本效率提升范围： - 30× 是常见 - 100× 也不稀奇 - 极端可达 4000×

预测市场应该用 V2 还是 V3？

绝大多数预测市场（包括 Polymarket）都不适合直接用 Uniswap V3，应该使用 V2 或类似 V2 的 AMM（均匀流动性模型）。

原因如下：

1. 预测市场的交易特性与 V3 天然冲突

预测市场的代币是：YES（事件发生）NO（事件不发生），价格在 0～1 美元之间波动。并且：市场会先在 0.1～0.9 之间来回振荡，最后会”收敛”到 0 或 1。全程逻辑是二元概率变化，不是两资产之间兑换。这类结构不适合”集中流动性”。

2. 预测市场需要”被动流动性”，而不是”专业 LP”

Polymarket 的用户不是专业做市商。

如果用 V3： - 普通 LP 无法参与 - 只有套利机器人与专业 LP 能赚钱 - 市场流动性呈现”高度机构化” - 造成交易者滑点剧烈、市场内卷

预测市场对 UX 更敏感，这样会毁掉用户体验。

3. 流动性区间需要频繁移动会导致 V3 的 LP 成本过高

预测市场价格变化巨大——可能从 0.2 → 0.7 → 0.4 → 0.9。如果用 V3： - LP 必须不断”重新设置区间”（reposition） - 每次 reposition 都是高 gas 成本（V3 操作非常贵） - LP 需要实时管理，非常不适合

对于预测市场，这种”主动做市要求”太重了。

4. V3 会让价格容易被”挤压”

由于 V3 的流动性集中在窄区间，预测市场很容易出现： - 少量资金强行把价格推到区间外 - 造成流动性塌陷 - 市场短时间变成”无深度”

而预测市场要求：价格必须随概率平滑变化，不得出现极端跳动。

为什么要使用链下订单簿来提升UX？

链下订单簿（off-chain orderbook）在预测市场（如 Polymarket）或任何 AMM+订单簿混合系统中，极大提升用户体验（UX），这是当今所有专业交易系统共同采用的模式（dYdX、1inch Fusion、Polymarket、Perps 等）。因为它让用户看到”真实深度”、更低滑点、可以挂单、体验和中心化交易所差不多，同时又保持链上结算的安全性。

1. 纯 AMM 带来的问题

滑点高
大额交易会”砸穿曲线”
无法挂限价单
用户完全没法提前知道”市场深度”
被动流动性导致价格波动非常大

用户体验不如中心化交易所（CEX）。预测市场参与者往往不是 DeFi 玩家，他们需要 CEX 级别 UX。

2. 链下订单簿如何改善 UX

核心原因是：用户的交易行为在链下先被撮合，链上只做最终结算，可导致速度快、成本低、可预测性强。

提升 1：挂单（limit order）功能

AMM 只能”市场单”（Market order）。链下订单簿则允许： - Limit order - Stop order - Maker-only / post-only - IOC / FOK - 批量挂单 - 机器人做市

这让预测市场立刻变得像交易所，而不是一个滑点机器。这对用户体验的提升是质的飞跃。

提升 2：看到”深度”

AMM 没有深度图，只能靠恒定乘积曲线估计，普通人完全看不懂。订单簿可以显示： - 买盘量 - 卖盘量 - 实时价格阶梯 - 24h 委托/成交记录

用户可以”明确知道”：如果我买 $500 会不会把价格推飞？这让用户更敢下单，提高成交量。

提升 3：更低滑点（因为订单先撮合）

流程如下： 1. 用户想买 YES 代币 2. 系统先查订单簿是否能在链下完成 1:1 撮合 3. 如果能 → 成交，无需走 AMM 4. AMM 仅在”无对手盘”时兜底

效果： - 滑点大幅减少 - 市场深度大幅增加 - 智慧钱更愿意入场（不怕吃曲线）

这是 Polymarket 能做到”大额资金不怕交易”的核心原因之一。

提升 4：链下撮合 = 交易速度快

链下撮合的速度可以： - 100ms–300ms 内确认（接近 CEX） - 前端立刻显示成交 - 用户即时看到结果

链上撮合（如纯 AMM）不可避免： - 高延迟 - 必须等待区块确认（5–30 秒） - UX 很差

预测市场更偏向”Web2-like体验”，而非 DeFi 玩家用的界面。

提升 5：Gas 成本大幅降低

如果全走 AMM： - 每次 swap 都要链上交易 - Gas 昂贵，跨链/二层也不便宜 - 高频交易不可能实现

链下订单簿让用户下单是： - 免费 - 可取消免费 - 更改订单也免费 - 链上只有最终 settle 是收费的

这是吸引大量普通用户的关键。

提升 6：不会牺牲链上安全

Polymarket / dYdX 这种系统的结构通常是：

链下：撮合 + 订单簿

链上： - 最终结算 - 资产托管 - 资金安全 - 结果确认（oracle）

安全性仍然由链提供，UX 则由链下系统优化，是各取优势的最佳混合模式。

3. 典型混合模式架构（非常适用于 Polymarket 类项目）

用户 → 前端  
   ↓  
链下订单簿（挂单/撮合/撤单）  
   ↓  
撮合引擎检查是否能链下成交  
   ↓  
  不能 → 走链上 AMM（V2 或类似）兜底  
   ↓  
最终链上结算（区块确认）

链下尽量完成交易，链上只管安全性。这就是现代预测市场的主流架构。

关于Polymarket的调研

合约部分主要模块是：

用户代理钱包：为用户部署合约钱包或代理钱包，用于用户持仓ERC-1155代币和USDT抵押资产。
CTF(Conditional Token Framework框架)核心合约：负责生成条件/事件。负责发行ERC-1155结果代币，负责代币分割,赎回逻辑。
Uniswap v2: 自动市场AMM（交易/撮合系统）配合链下订单簿Orderbook 负责交易部分。用户之间交换代币（即提前出售），撮合订单，自动市场AMM机制。
预言机Adapter（结果确认）：和Chainlink/UMA Optimistic Oracle预言机交互，将现实中事件结果输入协议，触发合约的链上结算。
辅助合约：资产管理，签名验证，注册/条件管理，暂停机制等。

合约内的流程大致是：

1，首先调用CTF核心合约，注册创建新条件/事件。 2，用户将USDT等存入系统，换取对应的结果代币。 3，通过Uniswap的自动市场AMM合约，撮合订单，与其他用户买卖结果代币。 4，事件结果由预言机Adapter合约获取，进行事件结果确认。 5，将事件结果，并传入CTF核心合约，触发结算。 6，用户可以将持有的结果代币，通过CTF核心合约赎回对应的USDT等资产；持有失败代币的则失去USDT抵押。

当前缺少的功能

但这些是原型部分功能，比起polymarket还缺少如下功能： 1，限价订单 https://docs.polymarket.com/polymarket-learn/trading/limit-orders 2，持有奖励 https://docs.polymarket.com/polymarket-learn/trading/holding-rewards 3，流动性奖励 https://docs.polymarket.com/polymarket-learn/trading/liquidity-rewards 4，结果投票（即结果有争议时，进行结果的延迟确认，并进行投票机制）

合约部分细节：

1. CTF (Conditional Tokens Framework) 相关合约 - ConditionalTokens：创建、拆分、合并预测代币 (YES/NO) - Oracle Adapter / Resolution Module：从预言机写入最终结果 - Market Factory：创建市场并绑定 QuestionID - Market Manager：管理资金、手续费、市场状态

2. AMM (自动做市商) 合约 - PoolFactory：创建每个事件的 AMM 池 - Pool (AMM Pair)：支持 YES/NO 两币的定价，公式多为 CPMM - LiquidityManager：管理 LP 添加/移除流动性 - SwapRouter：统一 swap 入口（订单簿兜底交易会走这里）

3. Orderbook / Off-Chain ↔ On-Chain 桥梁相关合约 - OrderSettlement / MatchingExecutor：链下撮合后，将撮合结果一次性批量提交链上 - SignatureVerifier (EIP712)：验证链下挂单的签名是否合法 - BatchSettlement：支持一次提交多笔成交单，提高效率降低 gas

4. 资金托管 / 安全性相关 - Collateral Vault：用户抵押资产统一托管处 - Escrow / Payout Module：市场结算后根据 YES/NO 分配资金 - Fee Collector：收取市场手续费

Polymarket GitHub 代码整体分析

合约部分代码是完整的，合约可复用性高。

其合约主要结构和作用

1. uma-ctf-adapter CTF 核心合约（Conditional Tokens Framework）

用于： - 条件/市场创建 - YES/NO 结果代币拆分/合并 - 最终结算代币 payout

这是预测市场最核心的链上功能，Polymarket 使用的是 UMA 的 CTF 标准。

2. ctf-exchange（Polymarket 的交易合约）

这个仓库是 Polymarket 的最重要链上组件之一：

执行用户用 USDC ↔ YES/NO 代币的交换
支持链下订单簿撮合后链上结算
使用批量结算 batch execution
负责手续费
控制资金托管 & 安全限制
提供订单执行的链上入口

这些合约是 Polymarket 逻辑的核心。

3. UMA 适配器（Oracle 结果写入）

UMA Optimistic Oracle adapter：

接受 UMA feed 写入最终结果
将 YES/NO Token 做最终结算（赎回）

4. 其他补充模块（少量）

Polymarket 公开的仓库中还有： - Fee module（手续费配置） - Proxy wallet factory（可选，用于用户操作代理的钱包） - 部分管理工具

虽然缺失了如下功能： - 链下撮合逻辑 - 链下订单簿的数据结构 - Relayer 服务端 - MEV 防护机制 - 清算服务 - 审计后的生产参数

但这些都不是合约内容，所以，合约内容部分是完整的

其复用性很高，因为：

1. CTF 本身就是 UMA 的开源标准（可直接复用） - 是预测市场最成熟的条件代币系统 - 市面 70% 预测市场都基于 UMA CTF

2. ctf-exchange 合约具有高模块化

可以复用以下模块： - swap 逻辑（YES↔NO, USDC↔YES/NO） - fee 模块 - batch trade execution - collateral vault - 合约风险控制（max slippage、execution delay 等）

智能合约全部经过 ChainSecurity 审计（质量高）

3. UMA Adapter 是通用的

可以自由替换成 Chainlink / Pyth / 自己的多签预言机，逻辑独立，替换简单

但替换难度在于：

Polymarket 使用的是 ERC-1155 条件代币（CTF），如果希望做 ERC-20 个人市场，可能需要改造。
ctf-exchange 强依赖 UMA CTF 的数据结构，市场要兼容 CTF 的 conditionId/collectionId 结构。
不含完整 AMM（没有 Uniswap v2/v3 pool），因为Polymarket 已经不使用 AMM，全都通过订单簿撮合 + batch 结算，AMM 只在早期版本使用。

可能需要修改的点：

场景 A — 你想做”与 Polymarket 相同功能”：直接复用：CTF Core（通常来自 Gnosis/UMA） + ctf-exchange + uma-ctf-adapter + exchange-fee-module。几乎无需删减。
场景 B — 你想增加”AMM 兜底”或更贴近 AMM 的 UX：增加：AMM Pool 合约（V2-like CPMM for YES/NO 或自定义 pricing curve）。需要 Exchange 支持 fillFromAMM(…)。改造：CollateralVault 要支持 AMM 与 Exchange 两种清算路径（权限与会计分离）。
场景 C — 你想支持”多结果/分布式赔率”。增加/替换：neg-risk-ctf-adapter（已开源）用以把多个二元合并为多结果；同时 Exchange 要处理多 outcome 的 positionId。
场景 D — 安全 / 合规 / 审计考虑（必须做）。增加：Timelock、Governance、Pausable、Circuit Breaker 合约（在市场异常时能暂停交易 / 提取保证金）。增加：强化 SignatureVerifier 的 replay 防护（nonce、deadline）与 BatchSettlement 的回滚补偿逻辑。
场景 E — 若你要在其它链 / L2 上部署。改造：对 ERC-20/721/1155 的地址常量、gas 逻辑、预言机适配器（UMA 在部分链上没有部署）做替换。

最小MVP原型的合约组合清单

CTF Core（ConditionalTokens） - 最小功能：createCondition / splitPosition / redeemPosition。 - 验收条件：能针对单个 market 生成两个 ERC-1155 position（YES、NO）并在合约中赎回。 - 复用：直接复用 Gnosis / UMA 的实现（开源）。

Exchange（简单版） - 最小功能：swapExactCollateralForPosition / swapExactPositionForCollateral（market swap），并能接受链下签名的 matchOrders（可先实现直接 market swap，后续加 batch）。 - 验收条件：用户用 USDC 购买 YES/NO；合约正确转移 ERC-1155 / ERC-20。 - 备注：不要在 MVP 里一开始实现复杂的 off-chain Merkle 批量结算；先做单笔 on-chain swap。

CollateralVault（或在 Exchange 中集成最小托管） - 最小功能：接收 USDC 并记录余额，供 Exchange 扣款。 - 验收条件：抵押资产能被正确释放到 winner。

UmaCtfAdapter（简化版/手工触发） - 最小功能：外部接口 settleMarket(conditionId, payout) 能被预设的 oracleOwner 调用，把结果写入 CTF（在 MVP 可用一个 admin account 代替真实 UMA OO）。 - 验收条件：调用后，CTF 的 redeem 能正确按 payout 分配资金。

SignatureVerifier（最小 EIP-712 支持） - 最小功能：对单笔订单的签名校验（用于未来链下撮合）。 - 验收条件：能通过样例签名验证签名者地址。

FeeModule（可选但强烈建议） - 最小功能：对交易收取固定比例手续费并转入 feeCollector。 - 验收条件：交易执行扣除 fee 并记录。

环境 - 推荐：Foundry 或 Hardhat（任何支持 solidity ^0.8.19） - 本地测试网：Anvil / Hardhat node / Ganache

Polymarket仓库合约细节分析

1) ctf-exchange（核心交换 / 结算合约）

在 Polymarket 中负责：把 ERC-1155 条件代币（CTF position）与 ERC-20 抵押资产（如 USDC）之间做原子交换；实现链下撮合后批量上链结算；管理手续费与托管。

核心合约 / 模块：

Exchange.sol（或 CTFExchange.sol） - 功能：对外入口，执行 matchOrders / fillOrder / swap 操作，检查签名证明并发起资产划转。 - 典型函数： - matchOrders(Order[] calldata orders, bytes[] signatures) → 批量执行链下撮合结果并触发托管/转账。 - 输入：orders（卖方/买方、assetId、amount、price、maker、taker限制等）、签名数组（EIP-712） - 输出：事件 logs（OrderMatched / OrderFilled），返回成交汇总 - fillFromAMM(PositionId, amount, minReceived) → 当链下撮合不足时走 AMM 路径（若实现了 AMM 兜底）。 - 流程：接收由撮合节点准备好的签名成交信息 → 验证签名 & 非重复 → 执行 ERC-20/ERC-1155 转移 → Emit 事件 → 资金留在 CollateralVault / 或直接转给 taker。

BatchSettlement.sol / OrderSettlement.sol - 功能：把多个链下成交打包上链，统一验证并结算（gas 优化）。 - 典型函数： - batchSettle( bytes32[] tradeRoots, bytes calldata proofBundle ) - 输入：Merkle root 或签名集合，证明构造； - 输出：一系列 TradeExecuted 事件。 - 流程：撮合引擎把撮合结果生成 Merkle 树或签名列表 → 提交给 batchSettle → 合约逐笔执行并在失败时可回滚/退款。

CollateralVault.sol / TokenVault.sol - 功能：集中托管抵押资产 (USDC)，管理拉取/释放权限。 - 典型函数： - deposit(address token, uint256 amount) - withdraw(address token, address to, uint256 amount) （仅限 Exchange/owner） - 安全：可加入 timelock / governance 控制

SignatureVerifier.sol / 验证模块（EIP-712） - 功能：验证链下签名（maker/taker/operator），防重放（nonce/timestamp）。 - 典型函数： - verifyOrderSignature(Order calldata order, bytes signature) returns (bool) - 工作流程：合约对提交的订单数据计算 EIP-712 digest → ecrecover → 对比 maker 地址。

FeeModule.sol - 功能：在执行交易时计算并收取手续费、refund 逻辑（如果多收则退回）

2) uma-ctf-adapter（预言机 / 结果写入）

连接 UMA Optimistic Oracle（OO），在市场到期时把外部结果写入到 CTF（Conditional Tokens）以触发赎回/结算。

核心合约 / 模块：

UmaCtfAdapter.sol - 功能：为每个市场在 OO 提交 request，监听 dispute/settlement，最终调用 CTF 的 reportPayouts / adapter 接口。 - 典型函数： - initializeMarket(questionMetadata, bond, rewardToken, reward) → 初始化并在 OO 上创建 request - settleMarket(bytes32 questionId) → 从 OO 拉取 resolution → 调用 CTF 的 reportPayouts 或 resolveCondition - 输入/输出： - 输入：marketId/conditionId、UMA 的 response 数据（通常是 bytes 或 uint256） - 输出：调用 CTF 的 resolve 方法并 emit MarketResolved 事件。

DisputeGuard / VigilantMode - 功能：在被挑战或仲裁期间保护资金路径、记录仲裁信息、允许手动介入（治理）。

3) neg-risk-ctf-adapter（多结果 / multi-outcome 适配）

将多个互斥二元市场合并为单一多结果市场的适配器，处理 payout 矩阵转换与复杂赎回逻辑。常用于多选题或分段市场。

4) exchange-fee-module（手续费代理）

FeeModule 会代理 matchOrders 调用，计算应收费用并在超额收费时退款，保证 operator 不得多收。常设计为可插拔模块

5) 其他仓库 / 合约（proxy/registry/manager）

proxy-wallet-factory / proxy-wallet：Polymarket 支持用户代理钱包（用于托管 position 与简化 UX），工厂合约用于批量部署；合约需实现对 Exchange 的最小交互权限。

registry / market-factory：管理市场注册、market → conditionId 的映射、市场参数（bond、expiry、oracle）等。通常提供 createMarket(…) 与 setMarketParams(…) 接口。

预测市场结构模块

事件市场合约（核心）
- 功能：创建事件（market）、管理 outcomes（tokenId）、mint/burn outcome tokens、结算（resolve）。
- 技术点：可用 ERC-1155、outcomes accounting、resolution oracle 接入。
定价引擎（AMM / CFMM / LMSR）
- 功能：为 outcome token 定价与撮合（CPMM、LMSR、Logarithmic Market Scoring Rule）。
- 技术点：数学模型实现、滑点、资金池管理。
流动性提供者 / 奖励模块
- 功能：鼓励 LP 放资产（买卖保证金、做市者奖励）、计费分配。
- 技术点：激励/vesting、手续费分配、LP 会计。
事件创建/治理/验证（Oracle）
- 功能：定义事件参数、谁有权限 resolve、oracle 集成（多源/仲裁）。
- 技术点：EIP-712 签名、oracle 接口、多签仲裁、deadline 管理。
结算机制
- 功能：事件结果上链后 payout 逻辑（winner claim、burn losers）。
- 技术点：可验证结果、claim 过程、手续费/treasury 切分。
用户下注/下单模块（前端+合约）
- 功能：支持押注、partial bets、market cap、min/max。
- 技术点：UX 友好、gas 优化、批量交易支持。
市场生命周期管理（开盘/关盘/取消）
- 功能：market 状态机（Open, Trading, PendingResolution, Resolved, Cancelled）。
- 技术点：状态转换规则、权限校验。
ERC-1155 / token 会计
- 功能：管理 outcome token 的 mint/burn、balances、转移。
- 技术点：batch 操作、gas 优化、兼容 AMM。
前端展示与概率可视化
- 功能：事件页面、赔率曲线、历史走势、事件描述。
- 技术点：React、charts、i18n（事件文本多语言）。
索引器与历史数据（The Graph）
- 功能：索引 market 创建、trades、resolves、TVL、liquidity depth。
- 技术点：Subgraph、API、后端查询。
风控与合规（敏感事件过滤）
- 功能：屏蔽非法/敏感市场（如暴力/违法主题）、年龄/地域限制。
- 技术点：内容审核流程、KYC/地理限制策略（若需要）。
套利/清算/自动化做市工具
- 功能：提供做市 bot、套利 bot，或提供 AMM 费率调优策略。
- 技术点：策略脚本、回测框架。
费用与国库（Treasury）
- 功能：手续费收集、项目方分成、奖励分配。
- 技术点：treasury 管理、治理接口。
诈骗/攻击检测与防护
- 功能：防止 oracle 操纵、重复解析、闪电贷滥用。
- 技术点：delay window、dispute window、仲裁机制、staking for reporters。
治理/投票/仲裁子系统
- 功能：社区决定哪些 market 可上线、特殊争议仲裁、参数变更。
- 技术点：DAO 接入、提案执行流程、冷却期。

预测市场人员配备

后端（Golang）

后端工程师（Golang） 2–3人，负责API、用户系统、订单系统、撮合器接口、清算系统
撮合引擎工程师（高性能 Golang / Rust） 1人，负责构建离线撮合 engine
数据库工程师（可兼任） 0.5人，负责侧重 Postgres / Redis / Caching 等

智能合约

Solidity 工程师 1–2人，负责ERC-1155、ERC-20、AMM/池子、清算合约
Audit 联络/安全负责人 0.5人，负责内部 review / 外部审计沟通

前端

前端工程师（React/Web3） 2人，负责网页、钱包交互、盘口 UI、订单簿 UI

PM / 产品 / QA

产品经理 1人，需求、排期、协调
QA 1人，自动化测试、压力测试

大约3-4个月可以出MVP原型。

后端 Golang 20 个模块功能

用户系统 - 注册、登录（email/Web3）、KYC（可选）、JWT Token
钱包绑定模块 - EOA 绑定、nonce 防重放
订单模型设计 - BUY / SELL / LIMIT / CANCEL、价格、数量、市场 ID
链下订单簿数据库 - Postgres / Redis、深度图数据结构
撮合引擎（核心） - Order matching（按价格优先、时间优先）、partial fill、执行记录 Match Event、撮合成功后 → 生成 Off-chain trade
风险控制 / 余额检查 - 用户资产状态来自链上快照、下单时锁定额度
结算批处理系统 - 定期打包订单、签名批次（aggregated batch）、触发链上 settle()
市场管理 - market metadata、startTime, endTime、resolution source
活动/赛事抓取 - Oracles（Chainlink、UMA、Gnosis）
市场价格订阅（Websocket） - 实时盘口、ticker、depth
压力测试工具 - 模拟 1,000–50,000 并发订单
管理后台 - 创建市场、修改参数、监控撮合延迟
审计日志 - 所有订单、撮合行为有不可篡改日志
定序服务 - 避免 bot 洗单、统一 nonce、顺序执行
Chain Listener - deposit、withdraw、settle、payout
Gas Station 服务 - meta-tx、relayer
系统监控 - Grafana、Prometheus
部署自动化 - CI/CD
防作弊检测 - wash trading 检测、僵尸账户、高频套利 bot 行为
风控限额 - 用户最大仓位、最大盈利、赔率上限

智能合约模块

ERC-²⁰⁄₁₁₅₅ 代币合约 - 单一事件 = 两个 token（Yes/No）
用户资金托管（Vault） - deposit、withdraw
市场 factory - newMarket(question, oracle, …)
市场合约（核心） - buy / sell、redeem、resolve()
卷积规则（可选） - CPMM（恒定乘积）、CLOB + AMM 混合
订单结算入口 - settleBatch()
针对订单数据的签名验证 - EIP-712、orderHash = keccak256…
Oracle 模块 - 外部预言机、dispute window
清算/赎回模块 - redeem YES/NO for payout
管理权限模块 - Ownable / AccessControl

前端模块

钱包连接
市场列表
盘口（Orderbook）
下单界面
订单管理
历史记录
KYC / 登录
市场详情
结果显示
资产页面

开发顺序

阶段 1（第1–3周）最底层基础

目标： 用户能看到市场列表，绑定钱包，deposit。

顺序非常重要： - 资产托管合约（Vault） - Market 事件合约（未接入 Oracle） - 后端 API 框架搭建（Golang） - 用户登录 & 钱包绑定 - Off-chain Order Model + DB

阶段 2（第4–8周）交易核心

目标： 用户能买卖 YES/NO token。

撮合引擎（简化版：限价单即可）
深度图与订单薄
batch settle 合约
Golang settlement job
前端下单流程打通

阶段 3（第9–12周）MVP 完成

目标： 第一版可用的完整产品

Oracle 接入（可 mock）
resolution 流程
赎回 payout
手续费模块（项目方收入来源）
风控
部署 / 测试网上线
审计（内部）

Polymarket合约功能分析

快速导航

核心概念速查

Chainlink 是什么？

Uniswap 是什么？

Uniswap V2 和 V3 的区别？

预测市场应该用 V2 还是 V3？

为什么要使用链下订单簿来提升UX？

关于Polymarket的调研

合约部分主要模块是：

合约内的流程大致是：

当前缺少的功能

合约部分细节：

Polymarket GitHub 代码整体分析

其合约主要结构和作用

1. uma-ctf-adapter CTF 核心合约（Conditional Tokens Framework）

2. ctf-exchange（Polymarket 的交易合约）

3. UMA 适配器（Oracle 结果写入）

4. 其他补充模块（少量）

其复用性很高，因为：

但替换难度在于：

可能需要修改的点：

最小MVP原型的合约组合清单

Polymarket仓库合约细节分析

1) ctf-exchange（核心交换 / 结算合约）

2) uma-ctf-adapter（预言机 / 结果写入）

3) neg-risk-ctf-adapter（多结果 / multi-outcome 适配）

4) exchange-fee-module（手续费代理）

5) 其他仓库 / 合约（proxy/registry/manager）

预测市场结构模块

预测市场人员配备

后端（Golang）

智能合约

前端

PM / 产品 / QA

后端 Golang 20 个模块功能

智能合约模块

前端模块

开发顺序

阶段 1（第1–3周）最底层基础

阶段 2（第4–8周）交易核心

阶段 3（第9–12周）MVP 完成

Frankie

月记202512

月记202511

Polymarket合约功能分析

快速导航

[计划]2026年五年计划

月记202510

月记202509

月记202508

Flutter学习记录

[计划]总结2025上半年,展望2025下半年

月记202507