Superstate申赎仍在pending：核USTB/USCC计价时点和收款路径
链小知 · 进阶 · 核验 · 依官方文档整理
对原Purchase/Redeem记录核现金或份额输入、NAV时间、目的地和基金日历，区分普通赎回与Ethereum原子流动性路径。
开始前准备
- 准备本人已有USTB或USCC的原Purchase/Redeem记录、时间及所用时区、支付/交付方式、金额/份额、目的地、状态和官方确认资料。
- 依据当前公开基金及门户文档，未实际登录、发送款项、执行合约或查询实时NAV。其他基金尤其CUSHY不沿用本教程时点。
1. 选定基金与原订单类型
在Portfolio按具体实体与资产查看原Purchase或Redeem，并在Transactions关联金额、美元价值、NAV、日期和status。USTB现名Invesco Short Duration US Government Securities Fund，USCC现名Bitwise Crypto Carry Fund；基金、token与平台角色分别确认。
Purchase买入份额，Redeem销毁/兑出份额后付款；tokenizing book-entry只改持有方式。组织合计、转让、mint或桥接记录不能替代本次申赎。CUSHY由Northern Trust办理且为周期申赎，不能套USTB即时或USCC T+1。
检查结果：实体、基金与申购/赎回记录唯一关联，没有将持有方式变更当资金兑付。
2. 核现金输入、份额输入及目的地
原申购官方路径是Portfolio→Purchase→Pay with选USD wire或支持链USDC，交付使用default purchase destination：allowlisted token地址或book-entry。比较原支付网络、币种、金额与指定交付方式，不因为USDC转出成功就断言基金份额已发。
原赎回路径是Portfolio→Redeem选择token或book-entry，再在Receive选择USD银行或支持链USDC。token路径向门户指定赎回地址发送，Ethereum还可有offchainRedeem方法；它们启动普通赎回，不等于立刻收到USDC。核原接收目的地而不是默认原持币地址。
检查结果：付款/份额来源与交付目的地相匹配，普通赎回启动和付款处理分开。
3. 按USTB或USCC确定NAV时点
USTB正文为连续计价，申购按资金收到时NAV/S，赎回按份额收到时NAV/S；自己点击/发起或原链广播时间不自动等于平台收到时点。USCC按market day每日5pm ET计价；5pm前后订单的定价与交付日不同。
USCC FAQ另说持仓市场marks采用4pm ET，这与5pm ET订单cutoff是不同字段，不能互换。ET包含季节性时差，保留原时区和日期；30日收益率不是单笔NAV。数量乘对应时点NAV只是该口径估值，最终按原订单/基金文件核。
检查结果：NAV定价时点、市场mark及订单cutoff分开，UTC换算没有固定假定ET偏移。
4. 分清交付日、资金方式及地址等待
USTB产品页写USDC申赎可非营业日即时处理但赎回受可用流动性限制；USD申购写收到wire的5pm ET，通用Subscribe例子又写1pm ET前发wire可当天收到。发汇与收到不是同一时点，不合成一个统一截止；USD赎回产品页写1pm ET前收到请求的当日路径，仍需核本人订单。
USCC产品页写5pm ET前T+1、之后T+2；T按market day，不按自然日24小时。通用假期表未标年份且列固定月日，不能直接用来推当前日期的结算日。payout新增/修改有24小时等待；原持币链支持也不自动证明该基金款项能在同链接收。
检查结果：日历、ET时点、USDC/USD路径和目的地等待按实际产品分别核，不作固定到账承诺。
5. 区别普通赎回与Ethereum流动性合约
若本人原材料是USTB Ethereum RedemptionIdle.redeem，官方方法描述在一笔交易烧USTB并收USDC；需要相应allowance和合约USDC流动性，流动性不足会revert。它与token.offchainRedeem的普通赎回及付款流程不同，不能把任一fund的Redeem都标原子完成。
方法calculateUstbIn按目标USDC返回所需USTB并向上舍入，返回量不是另一次已执行赎回。合约页的费用为0只限定撰写时此路径；通用申赎还明确链Gas与银行费由投资者负担，管理费体现在NAV。没有原参数/结果就不猜当前手续费、实际输出或可用流动性。
检查结果：原调用或门户路径已区分，预估、allowance、流动性与真实执行结果分别核。
6. 以份额或款项交付关闭pending排错
Overview写Transactions在token/shares交付或付款处理前保持pending；申赎文档说启动与完成分别有确认邮件。把原状态、邮件、对应份额数量或收款资料按同一订单整理，不用另一笔转账或钱包总余额变化证明本单完成。
最终结论定位为未获对应产品许可、目的地/等待不符、资金或份额尚未收到、计价日未到、流动性/执行失败或已有交付结果。当前公开门户文档没有逐状态机枚举，保留原status而不造COMPLETE等字段；银行实际入账与平台付款处理的证据边界分别写清。
检查结果：pending原因与原记录字段相符；份额或款项交付可核，证据不足的实际收款明确待核。
怎样确认完成
- 原订单的基金、资金/份额输入、NAV时间与交付目的地可复查。
- 能按普通门户申赎或特定Ethereum方法定位阶段；仅有pending、申请或预估时不写已兑付/到账。
常见错误与边界
- USTB、USCC、CUSHY计价与结算安排不同，不按品牌统一套即时赎回。
- ET、market day、发汇和平台收到时点不混；假期固定日期表不冒充当年日历。
- USCC说明NAV可能下降，基金份额和管理费口径不能解释成稳定币1:1或保本收益。