Polymarket订单已匹配或撤销，余额为何仍对不上：核部分成交、结算与净数量
链小知 · 进阶 · 核验 · 依官方文档整理
对本人已有订单与成交导出，区分账户钱包/签名者、原单份额、maker/taker成交、重试状态、费用和同笔资产接收。
开始前准备
- 准备已有Global order ID、原订单/成交导出及其客户端或API版本、过滤条件/分页资料、取得时间；如已有原链上回执，准备账本/交易哈希及资产钱包，不含API secret、签名或私钥。
- 只对照已有资料及官方Manage Orders/OpenAPI正文，不发订单/账户查询、撤单、补授权或重试；US订单、来源单位不清或只有截图的缺失部分要保留待核。
1. 确认资料属于哪个账户钱包和读取权限
先记原maker_address/资产钱包、signer、order ID与客户端类型；Deposit、旧Proxy、旧Safe钱包不同，owner或交易签名者地址不一定就是资金持有地址。原订单owner字段还可能是账户UUID，不拿它当钱包接收地址。
官方Manage Orders说明Session Key只读自身关联订单/交易，Deposit owner不能直接读取其授权Session Key订单。已有401是认证/权限线索，404是订单未找到，不能用这些错误推断订单取消、零持仓或本金遗失。
检查结果：原订单所属资金钱包、签名者与读取身份分开，错误没有被当成资金结论。
2. 读原单状态和归一化份额
按原接口记录market(condition ID)、asset_id、side、price、original_size、size_matched、order_type、status和associate_trades。SDK可能改为conditionId/assetId/originalSize/sizeMatched，须先确认来源而非混字段。
单笔订单OpenAPI明确original_size和size_matched是已归一化shares十进制字符串，不再÷1e6；size_matched取消后仍保留，也不是当前仓位余额。保留完整ID与原精确数量，created_at/expiration按原Unix时间，SDK ISO日期另列；expiration为0是GTC无定时到期。
检查结果：原单数量/单位/状态来源清楚，未把size_matched等同最终当前余额。
3. 拆已成交部分与未成交取消部分
对已有记录算原委托份额减matched份额的剩余数量，并对照GTC/GTD/FOK/FAK。GTC/GTD BUY目标是份额，FOK/FAK BUY目标是collateral预算；不能把下单按钮金额当同一种size。
订单取消只能影响未成交部分；原CANCELED_MARKET_RESOLVED也是市场结算后取消剩余，并不撤销已结算的fills。FAK可部分成交后取消剩余，不能见CANCELED就断言整单没有花费或收到资产。
检查结果：原委托、撮合量、剩余取消量分别记；各目标单位没有混成份额。
4. 逐成交关联原单并核导出是否齐全
从原associate_trades或已保存成交表关联trade id、market/asset_id和角色：作为taker核taker_order_id，作为maker核maker_orders里自己的order_id和matched_amount。不要把一个taker总量全算给某一个maker，也不要因顶层side就忽略maker条目的side。
官方Get trades规范要求maker_address，market过滤是condition ID；原时间过滤after/before为Unix时间。新规范响应为limit/next_cursor/count/data，LTE=表示没有下一页；缺后续页或过滤条件时不宣布全部成交已齐。
Manage Orders仍有直接数组wire示例，不能把它当新分页对象；成交size/matched_amount的规范未给完整尺度，例子100000000也不能证明它就是100份。先核原schema/版本/单位；缺说明就只保留原量，不与原单shares直接加减。
检查结果：每个fill关联自身原单和角色，分页/过滤与数量尺度缺口明确，未重复算同一trade。
5. 区分订单撮合提示与每笔交易结算
订单提交页live/matched/delayed/unmatched与单单查询LIVE/CANCELED/MATCHED不是交易终态表。对每笔已有trade保留原status；概念文MATCHED/MINED/CONFIRMED/RETRYING/FAILED分别是撮合、已上链、已终局、待重试、永久失败。
当前Get trades规范使用TRADE_STATUS_MATCHED/MINED/CONFIRMED/RETRYING/FAILED，Manage Orders旧wire例用MATCHED；按来源保存原格式，不生成未有的枚举。只有MATCHED不证明链上接收，MINED也未达到文档CONFIRMED层；RETRYING不能当重复成功成交。
同一trade后续更新按trade id及last_update对照，另记transaction_hash。该字段可缺失，不拿占位哈希或只有发出提示当成功回执。
检查结果：逐trade能分撮合/执行/终局或失败，更新不被重复计成交。
6. 按原角色和市场配置拆费用与数量
保留原feesEnabled/feeSchedule、maker/taker角色、价格与份额。官方Fees基础公式C×rate×p×(1-p)中的C是成交份额，rate不是直接对全部本金的百分比；不能用榜单类别表代替这笔市场原配置。
V2迁移说明BUY费用增加collateral支出，SELL费用从proceeds扣除；与页面均价、最初委托预算分开。Fees页仍用USDC展示计费，pUSD账上原量六位，另有fee_rate_bps字段；先认资产和尺度再核，未证完整单位就不强算净额。
只对已确认且单位明确的原fills做精确小数/整数对账，不用普通浮点数处理长ID或金额。链费、第三方费用及返佣到账另列，返佣资格/公式不等已返还。
检查结果：成交金额、协议费用、链费和返佣分别有依据；未凭样例/通用费率补具体扣款。
7. 用同笔资产移动给出最终差异结论
按原交易所在Polygon账本/Exchange地址核CTF域2或V2 ExchangeV3域3；原order.tokenId在V2可存position ID，字段同名不证明同一协议。沿原ERC1155与pUSD实际转移，核资产钱包、结果ID、原量和时点；OrderFilled/OrdersMatched/费用事件只能作相应上下文，不再把它们各加一次余额。
若该时段还发生卖出、split/merge、redeem或迁移，成交matched总量也不会等于期末余额。对已有收支逐项列出，只有订单/成交导出而无资产移动资料就写结算状态已核、最终钱包净增待核。
汇总身份/权限、部分成交、分页/单位、交易终态和费用五类差异；不靠放大金额、重新签单或补发交易来证明对账。
检查结果：原单、每笔成交和实际资金结果能对应，或准确指出缺少哪条原资料。
怎样确认完成
- 得到逐单/逐trade可复查的成交与资产对账，已成交、未成交取消、等待结算和待核金额分列。
- 所有结论限定已有资料和所读官方规范；未执行认证查询、订单/撤单、签名或资产操作，不算交易实测。
常见错误与边界
- Order状态、Trade状态、份额余额和现金接收是不同层；取消不会冲回已成功fills。
- 订单数量明确归一化，不代表所有Trade样例都是同尺度；旧数组与新分页对象、状态前缀分别保留。