Polymarket市场关了为何还不能对上兑付：核版本、结果ID与结算记录
链小知 · 进阶 · 核验 · 依官方文档整理
按已有Global市场/持仓资料，区分event与子市场、CTF token与V2 position、关盘与最终结果，再核兑付到哪个资产钱包。
开始前准备
- 准备本人已保存的Global市场链接/slug、市场说明与规则、Gamma市场资料及取得时间；若涉及原持仓或兑付，再准备对应合约/链、结果ID、资产钱包地址、数量和原回执，不含秘密或API凭据。
- 入口是docs.polymarket.com的Market Details、Resolution及本页来源。步骤对照已保存记录，不新连接账户/查询真实钱包或发赎回；US、Combo和跨链记录须另核，不能套本二元市场任务。
1. 从事件页定位具体子市场
打开原市场资料，先记event slug，再逐项找到实际market slug、Gamma id、conditionId与问题原文。一个event可含多个Yes/No子市场；不能把整场事件名字或同名页面当某一持仓的条件ID。
在官方Market Details的Market Identifiers/Outcomes说明中对照字段；原JSON若只有标题或缺对应子市场，就停在身份待核。记录是Global还是US，US入口和字段不直接套这里。
检查结果：可列出一个具体子市场的链接/slug、Gamma id与conditionId，且产品范围明确。
2. 按version选择结果ID并保留完整字符串
读取原Gamma version：v2使用positionIds数组；v1先解析clobTokenIds的JSON字符串。outcomes和outcomePrices也是JSON文本，按同一数组索引配对标签、价格与ID；在这类二元市场0为Yes、1为No。
两类ID可同时出现，不能凭“有positionIds”就选V2。保留大整数ID的十进制字符串，勿转普通浮点数；版本未知、数组长度对不上、ID缺失或非十进制时不要硬填。
对照原ledger合约和官方Polygon部署表：v1余额在Conditional Tokens，v2在PositionManager。原CTF持仓不自动转；若已有迁移记录，需MigrationConditionRegistered/PositionMigrated等映射及两账本资产变动。
检查结果：version、标签、结果ID、ledger四项一致；缺映射的旧新ID不合并。
3. 把关盘时间与结算进度分开
核原active、closed、archived、acceptingOrders和enableOrderBook及数据取得时间。closed也可指已关闭，不能仅凭它认定最终payout已公布；市场存在或显示价格也不代表订单簿仍开放。
已有V2 Gamma结算记录用resolutionStatus的inactive/active/resolved；V1用原umaResolutionStatus，不把两者当同一字段。已有Data API v2 resolution记录无匹配时data可为空，空行不等输了或已赎回。
若原记录带expected_settlement_time，它是RFC3339 UTC的最早可能结算时刻，按settlement_time_basis看提案/争议/liveness依据；可延期或已过时仍待finalize，不是到账期限。
检查结果：关闭/停止接单、结算进度与原记录时间分别列出；空结果和过去的估计仍保留待核。
4. 回到原规则核最终结果依据
逐条保存resolution source、结束时刻、边缘情形和Additional context，按原资料对照；问题标题和页面概率只描述问题/市场定价，不能替规则。UMA提案或挑战中记录不等已接受最终结果，也不把文档约两小时当所有市场完成保证。
若是Chainlink TWAP Up/Down市场，原窗口起点price to beat与终点final price须来自规则所指同一stream；官方此类说明Up为final>=起点、Down为小于，不拿任意交易所现货K线代替。其他规则/旧版本不自动沿用这个比较。
检查结果：最终结论能指向原规则和同一窗口/来源；只有提案、报价或不同价格源时不写最终胜负。
5. 核份额数量和实际payout，别把市值当可领金额
先确认原余额是哪一个结果ID和资产持有者。页面price×balance是估值；二元市场允许split payout，不能强写每个结果必为0或1。CTF按该condition的payoutNumerators/payoutDenominator；V2 Binary/NegRisk记录结果为ppm、分母1,000,000。
已有V2 getPayout记录须对应同一positionId和amount，返回是pUSD六位原量；未resolved可revert，零也可能是有效的失败结果，不能把所有0/报错当持仓丢失。V2 Router amount的1,000,000才是1份或1pUSD，不能把原API已经归一化的显示数量再除一次。
若原资料属于Combo或负风险迁移的特殊结果推导，停止套简单二元计算：Combo看各leg；旧CTF注册迁移结果不得由普通同组NO推导替代。
检查结果：结果和数量属于同一账本/条件，比例与单位明确；可领估算、估值和实际转移分列。
6. 沿原兑付回执核最终接收并保留待核层
已有兑付资料先核合约/方法/调用者，再核同笔ERC1155减少和pUSD接收，Router与module事件只是同一操作上下文，不再重复加一次资产变化。V2 Router把输出返调用者；AutoRedeemer授权不自动排期，已有自动兑付记录仍要核实际holder接收。
pUSD、USDC.e和银行美元分别记。官方具体unwrap要求USDC.e资产和_to接收方，不能把“赎回成功”写成USDC.e或银行卡已收到；只有pUSD记录就把后续转换列为未核。
汇总原规则、version/ID、结算、可领口径、实际接收五层。缺转移或原后续收款资料时，结论停在已结算/兑付待核。
检查结果：能证明具体资产和接收方实际增加，或明确哪一层仍无记录；没有把授权、payout读值或关盘提示当到账。
怎样确认完成
- 形成具体市场/结果ID、规则、结算结果和兑付接收的可复查对照；缺证据的层保留待核。
- 本任务完成于原记录与官方方法核对；没有对任何真实市场、账户或链上兑付作实测。
常见错误与边界
- CTF Exchange V2和Polymarket Protocol V2命名接近，但签名域/持仓账本不同；按原version与合约核。
- 未知ID/缺行/null不等0持仓或败方；不同数据取得时间不能拼成同一时点结论。