签署订单，是允许按照指定条款交易，并不意味着交易已经发生。API 可以接受订单，订单簿可以撮合其中一部分，但结算交易仍可能失败。
《Polymarket 与 Kuest 运作原理》第五篇，追踪相连的 YES 和 NO 订单簿背后的授权。我们沿着系统中各个独立层次，区分参与者签署了什么、撮合服务执行什么，以及区块链实际记录什么。
从指令开始，再追踪资产
继续使用假设问题：“A 观测站是否会公布，B 城在日期 C 的 12:00 UTC 气温至少为 30.0°C？”买入其 YES 代币，意味着取得指定结果资产；签署 BUY 订单，只是授权取得它。
我们使用标准的二元 Conditional Tokens Framework（CTF）市场和一般抵押品单位。金额示例假设资产有六位小数、资金和权限充足，不计 Gas 与融资成本；涉及手续费时会单独注明。
以下解释使用公开签名标准、公开的 CTF Exchange 示例和假设资产流动。各平台支持的钱包、订单类型和手续费，应以其当前的公开集成文档为准。
三种授权承担不同工作
订单签名授权一项特定交易指令。API 身份验证向服务表明请求者已获授权。 钱包批量签名则授权另一组钱包调用，例如设置支出额度。
API 凭证向服务标识已获授权的请求者；它不是参与者的私钥，也不会取代订单签名。Polymarket 的公开钱包与身份验证指南提供了一个有文档依据的产品例子。
不同对象需要不同检查。钱包批次有自己的 nonce 和截止时间；这些字段不会变成 交易订单的一部分。
EIP-712定义结构化消息的哈希与签名。其域可以把指令绑定到链、应用名称、版本和验证合约，从而防止针对一个域的签名在另一个域下通过验证。
公开的 CTF Exchange V2 签名代码展示了应用专用的 EIP-712 域。域名称或版本属于签名上下文，并不能证明另一交易系统会接受相同消息。防重放的限制还取决于实际合约状态和验证规则。
金额本身包含价格
在公开的 CTF Exchange V2 订单定义中，签名指令包括代币、方向、maker 和 taker 金额、账户身份等字段。签名授权的是这条定义明确的消息，而不是此后界面碰巧显示的价格。
这里的 maker 指提供资产的账户，即使它的订单立即吃单也是如此。这个字段名不同于交易角色中的挂单方（maker），后者指订单先留在簿中，之后由另一订单与其成交。
对于 BUY，makerAmount 是愿意支付的抵押品，takerAmount 是请求的份额。用 60 换取 100 YES 的订单，编码出的限价为 60 ÷ 100 = 0.60；对于提供 100 YES、要求 60 的 SELL，价格则为 takerAmount ÷ makerAmount。
没有独立的签名价格字段可以覆盖这个比率。不重新构建并签署对应金额，只修改显示价格，不能改变已授权条款。
时间戳可以描述订单创建时间，却不一定是可执行的到期截止时间。集成时必须区分签名字段与服务指令，并按照当前公开订单规范检查其含义。
验证决定订单能否进入订单簿
下单前，确认目标资产、价格限制、数量、账户和支持的订单类型。客户端检查与 API 确认不能取代合约结算成功。
价格刻度是报价之间允许的变化单位。签名前应核对当前公布的市场规格。客户端检查、服务响应和合约规则证明的是不同事情；只显示一个最小值，不能证明链上存在相应约束。
资金与权限是不同检查：BUY 需要可用抵押品，以及向结算合约授予足够支出额度；SELL 需要结果代币和转移授权。签名本身两者都不能提供，接受订单时的余额检查也无法冻结账户之后的所有变化。
Post-only 表示指令意在增加挂单需求，而不是立即吃单。应检查交易场所文档支持的组合和拒绝行为；仅凭这个标签无法定义所有实现。
有效期指令告诉撮合服务如何处理未成交数量：
- GTC — good till cancelled：让符合条件的剩余数量继续留在订单簿。
- GTD — good till date：允许挂单保留到指定到期时间。
- FAK — fill and kill：立即成交可用数量，取消其余部分。
- FOK — fill or kill：要求全部请求数量均可成交，否则完全不成交。
服务层的到期订单与签名中的合约截止时间，是不同承诺。应验证当前规范在哪里执行到期限制，以及已提交交易如何处理。请求中存在某个字段，本身不能证明合约提供相应保证。
撮合之后，仍需成功结算
可以用这些教学检查点理解流程：已签名 → 已接受／挂单中 → 已撮合 → 已提交 → 已确认。订单可能在进入簿前被拒绝；一个已接受订单也可能产生多次部分撮合和结算交易。这些标签解释的是责任，不是在定义通用 API 枚举。
有效期指令允许时，部分撮合后的剩余数量可继续等待撮合。结算失败后，必须先 核对实际状态，再考虑重试。
公开的 CTF Exchange V2 合约展示了资产移动前的授权撮合与合约检查。第 4 篇的直接、铸造和合并示例解释了可能发生的资产变动和所需资金。
链上交易是原子的：如果必要的转移或检查回滚，其状态变更会撤销。但这不会撤销另一笔已经成功的交易，回滚的交易也仍可能消耗 Gas。
交易哈希标识已提交交易，不代表购买成功。应检查回执以及所选网络要求的确认状态。结果未明时，界面应保留这种不确定性，而不是报告资产已交付。
运营方界面应分别保留订单标识符、已撮合数量和交易引用。交易失败或状态不明时，应先核对其实际结果，再重试；修改本地标签不能移动资产。
部分成交消耗的是订单所提供的资产
假设挂单 BUY 提供 60 抵押品换取 100 YES，首次恰好以 0.60 成交并收到 40 YES。不计手续费，它消耗 24 抵押品，留下已签名额度中的 36 抵押品，相当于同价的 60 YES。
挂单 SELL 提供 100 YES 换取 60 抵押品，同样一次成交会消耗 40 YES，收到 24 抵押品。它剩余的 maker 金额是 60 份，不是 36 抵押品。两笔订单都还可交易 60 YES，但链上剩余计数使用不同资产单位。
同样成交 40 份，计数单位不同。假设恰好按限价执行，未计手续费。
公开的 CTF Exchange V2 运算代码使用整数基础单位。在以下采用的比例向下取整模型中，取得金额等于提供金额 × 签名中的 taker 金额 ÷ 签名中的 maker 金额，再向下取整。精确核对需要实际路径的舍入规则。
例如，一笔签名卖单用 3 份换 1.8 抵押品，其中卖出 1.000001 份时，计算为 1,000,001 × 1,800,000 ÷ 3,000,000，向下取整为 600,000 个抵押品基础单位。因此，小额成交和手续费需要遵循实现的舍入规则；仅用已舍入的显示价格相乘，不足以精确核对。
手续费应单独记账
假设直接购买 100 YES 花费 60 抵押品，并假设双方各付 0.60 手续费。买家需要 60.60 抵押品，卖家收到 59.40。剩余 1.20 是总手续费，因此买方的全部资金都有去向。
假设费用，不是当前费率。买方流出 60.60 = 卖方收款 59.40 + 总手续费 1.20；现有的 100 YES 转给买家。
在这个明确的例子中，BUY 手续费加在买家所需资金之上，SELL 手续费从卖出所得中扣除。实际收费、接收方和舍入必须按所选交易场所与路径检查；示例不是收费表。
取消有其边界
移除未成交订单的请求，针对的是尚未执行的剩余数量，不会撤销已完成的成交。应把取消确认与尚未完成的结算交易分别记录；重新使用资金前，两者都要检查。
如果结算已经提交，之后在订单簿取消，不能保证阻止它。假设资产仍可使用前，应先检查交易结果，尤其是原订单已部分成交时。
取消剩余订单与结算先前撮合可以同时发生。两种有延迟的保护都不会撤销 已经成功的交易。
更广泛的账户限制不等于取消一笔订单。恢复控制可以有不同范围、延迟与权限主体。应使用实际账户对应的公开合约和产品文档，不要假定所有控制都能立即停止交易。
Deposit Wallet 在紧急提款或撤销授权前，有单独的暂停与紧急等待期。在该代码中，仅暂停钱包不会禁用批量执行或签名验证，因此不是即时停止交易的开关。
版本名称不能定义集成方式
Polymarket 的旧版 CTF 订单签署 taker、expiration、nonce 和 feeRateBps。另一个独立的 CTF Exchange V2 订单移除了这些字段，加入 timestamp、metadata 和 builder；价格仍是金额比率。
V2 仓库还移除了 fillOrder/fillOrders，保留通过 matchOrders 进行运营方撮合。这个 CTF Exchange V2 不同于 polymarket-v2-external 中的 Protocol V2 仓位架构；Kuest 不会自动继承任一仓库的更新。
合约结构体没有到期字段，不代表产品没有到期订单。Polymarket 的当前生命周期文档在产品层面描述了 GTD，其仓位指南区分 CTF 和 Protocol V2 账本。构建集成前，应验证实际市场的路径。
Kuest 运营方应披露什么
Kuest 的公开运营方指南区分了运营方应用与共享服务。应向参与者说明支持的账户流程、完整费用估计，以及不同的已接受、已撮合和已确认状态；这些是可观察的产品要求，而非内部实现细节。
Kuest 的公开手续费文档描述了运营方参与交易费用分配，以及可配置的推广方分成。分配一笔手续费，不同于额外按交易名义金额收费。解释参与者支付什么时，应使用当前公开配置和结算记录。
对品牌运营方来说，这形成了具体的集成要求：保留正确的 builder 身份，显示实际总费用，并对照结算记录核对分配。仅有一个代码标识或品牌前端，都不保证订单被接受、获得费用权利或取得收入。
带着参与者能够理解的执行政策，通过 Kuest 上线自己的预测市场：明确目标受众的司法辖区、精确市场规则与结果判定路径、所需交易数量、支持的钱包流程、费用披露，以及分别展示的已接受、已撮合和已确认状态。