预测市场网站是一个承担多种工作的系统入口。界面展示市场，交易系统撮合订单，合约结算资产变动，数据服务让结果可读。预言机通过配置好的结果判定流程，为市场提供最终答案。
这些工作在不同位置发生。点击按钮、订单被接受和交易已结算，是不同的里程碑。理解这些边界，就能解释为什么市场页面可见却无法交易，或者为什么已完成的交易还需要一段时间才出现在持仓中。
这是《Polymarket 与 Kuest 运作原理》的第二篇。如果你还不熟悉价格与支付金额，请先阅读预测市场的价格究竟意味着什么。
四个层次，四种责任
| 层次 | 作用 |
|---|---|
| 界面 | 展示问题、规则与账户操作 |
| 交易系统 | 验证订单，寻找条件匹配的买卖需求 |
| 合约 | 执行所选路径的资产与权限规则 |
| 数据服务 | 为应用整理元数据、余额和活动记录 |
Polymarket 的 API 概览体现了这种分工：Gamma 支持市场发现，CLOB 支持订单和实时市场状态，Data API 支持账户与市场活动。WebSocket 提供更新，但不会取代底层的结算规则。
页面地址不是仓位标识符
事件将相关市场组合起来展示。二元市场提出一个具体且可判定的问题，并分别提供 YES 和 NO 结果。一个事件可以包含多个市场，因此仅靠页面地址不足以指定订单。参见 Polymarket 的市场与事件模型。
在 Conditional Tokens Framework，即 CTF 中，问题 ID 标识结果判定的输入。条件 ID 由预言机地址、问题 ID 和结果槽位数量派生而来。结果仓位 ID 还取决于抵押品和集合路径。这些标识符不能随意互换。
这是一张分组关系图，不是哈希计算公式。读取订单簿或下单前，先选定准确的市场和结果。
Polymarket 的链上数据指南区分了这些 CTF 派生方式与 Protocol V2 标识符。另一网站上的标题相同，并不能证明资产相同。
跟随一笔订单走完整个系统
首先，界面找到市场，获取其结果标识符和交易配置。客户端准备订单，由对应签名者授权订单条款。签署订单与广播区块链交易不是同一个操作。
签名后的指令到达中央限价订单簿，即 CLOB。服务检查订单是否符合接受条件，并寻找可匹配订单。符合要求的订单如果不能立即执行，可以保持未成交状态。撮合表示按照交易规则达成交易条件，尚不是资产已经交付的证明。
下一步是交易结算。执行服务向 Polygon 上的对应合约提交交易。结算路径验证已授权交易，执行成功后更新资产。即使 API 之前报告已撮合，失败的链上交易也不会因此变成成功购买。
实线箭头表示指令前往结算的路径。虚线箭头表示记录后的数据返回界面， 并不转移抵押品。
Polymarket 介绍了订单生命周期，并另行要求集成应用先等待成交结算，再检查产生的仓位。交易被收录以及达到要求的确认状态都很重要；只有订单 ID 并不够。
最后，索引器处理已记录的变更，API 提供更新后的视图。界面此时可以显示仓位和活动。这些阶段需要各自的状态提示，不能统称为含糊的“成功”。
合约是一组分工，而非单个黑箱
基于 CTF 的系统在多组合约之间分配责任。以下名称描述的是角色；具体合约和权限取决于所选路径。
这是一张职责图，并不表示每笔交易都会调用全部五组合约。
| 合约组 | 作用 |
|---|---|
| 钱包、工厂与升级基础设施 | 持有资产，执行所有权、签名和实现版本规则 |
| CTF Exchange 或负风险交易路径 | 验证并结算适用的已撮合订单 |
| Conditional Tokens | 记录 CTF 结果余额，支持拆分、合并与赎回 |
| 预言机适配器与结果判定路径 | 将已接受的答案转换为某个条件记录的支付金额 |
| 手续费、奖励与托管辅助合约 | 在配置相应功能时，承担额外的记账、激励或资金流程 |
交易结算与结果判定回答不同的问题。 交易结算判断这笔交易能否移动资产。结果判定判断市场规则对应哪种支付。Polymarket 当前的结果判定文档区分了基于 UMA 的市场和基于 Chainlink TWAP 的涨跌市场；撮合引擎不会通过选择成交价格来决定结果。
版本很重要。Polymarket 当前同时介绍 CTF 和 Protocol V2 仓位系统。Protocol V2 使用 PositionManager，CTF 使用 Conditional Tokens。其合约列表列出了不同的结算组件。“Exchange V2”不能与“Protocol V2”互换；应同时确认市场版本、账本与路径。
数据让账本可用，但也可能滞后
索引器将合约事件转换为可查询的记录。API 可以把这些记录与市场元数据、价格或计算结果结合起来。这些应用数据很有用，但更新时间可能不同于交易回执或实时订单数据流。
Polymarket 的链上数据指南描述了转账和交易成交事件。这些记录不包含所有留在链下订单簿中的挂单。同样，把索引器称为“订单簿子图”，也不会让它变成实时订单簿。当前报价和历史成交属于不同记录。
如果持仓看起来没有更新，应将其更新时间与交易和对应账本对照。如果报价消失，应检查当前订单簿。这是不同的排查；刷新市场目录不能证明订单未成交，也不能证明资金缺失。
中继器协助提交交易，但不会消除依赖
中继器可以提交受支持的钱包操作，例如部署或授权。Polymarket 的钱包文档描述了由其他方支付费用的操作，让账户在这些调用中无需自己持有原生 Gas 代币。Gas 仍然会消耗，只是费用由别处支付。
钱包中继器与交易系统的撮合、结算服务承担不同工作。服务可用性、支持的调用和费用赞助政策都很重要。不要假设每笔交易都经过钱包中继器，也不要认为费用由他人支付就证明了资产托管方式、升级权限或预言机的正确性。
Kuest 的区别：品牌界面可变，执行路径可以共享
Kuest 的公开架构指南将运营方的品牌和目录与共享交易基础设施区分开来。运营方可以为自己的受众选择市场，同时使用兼容的共享执行服务。
共享执行需要服务、网络与资产匹配。独立品牌不会创造或保证 流动性。
使用相同 Kuest 服务与资产的两个品牌网站，可以展示不同目录，同时接触共同的买卖需求。对运营方而言，这意味着复用交易执行基础设施，同时为特定受众策划集中的使用体验。
运营方向交易者展示市场；做市商通过订单提供买卖需求。这些参与者角色不同于撮合和结算交易的服务。创建市场本身不会带来愿意交易的对手方，也不会创造可成交数量。
共享 Kuest 服务不会把它的订单簿与 Polymarket 合并，镜像问题也不会让两个交易场所的余额可以相互转移。
上面的合约组解释的是职责，并非完整的部署清单。运营市场之前，应验证实际网络、合约地址、公开代码、权限和支持的仓位系统。上游审计不会自动覆盖另一个部署或自定义改动。
对运营方来说，有用的检查应该具体到：网站展示哪些市场资产，哪些服务接受订单，哪些合约负责结算，显示的记录有多新？新的品牌应该让这些答案更容易找到。
想为你的受众构建这样的体验吗？通过 Kuest 的引导式设置，创建自己的预测市场。