Relay 充值后一直 waiting：按地址找新请求并核对退款
链小知 · 进阶 · 核验 · 依官方文档整理
针对已有 deposit-address 记录追踪重报价、少付多付、原链退款与恢复限制，不重复充值试错。
开始前准备
- 准备原 deposit address、来源链/token/实际充值 hash 与数量、open/strict 类型、quote-time requestId 和已保存 requests/v3/status 结果。
- 只查看已有平台与浏览器记录；不触发 reindex、withdraw、claim、退款测试或新交易。当前文档将 requests/v2 标为将于2026-11-24退役，本篇用v3记录。
1. 确认充值地址模式与原始资金
先核对 useDepositAddress、depositAddress.address/type、注册来源链、实际转入链和币，以及 user/recipient/refundTo/recoveryAddress。open 可同路线复用而每次存款产生请求；strict 是原订单单次付款指令，不能当永久收款地址。
原 hash 是来源存款交易，用它在来源浏览器核对成功、地址、币与金额；它不能直接代替 requestId 查询跨链状态。少付/错币/错链先记录，不用同地址再转一次“补全”。
检查结果：取得一笔实际存款与地址模式的对应表，付款与订单标识分开。
2. 按地址查重报价而非只等旧 requestId
当前requests/v3方法schema要求x-api-key；status/v3该头仍标optional，不能互推权限。已有 GET /requests/v3?depositAddress=... 记录逐条核 requests[].id、depositAddress.depositTxHash、sender/recipient、data.inTxs 的链和 hash，按实际存款匹配拥有fill的请求。分页limit默认20、1–100，continuation来自上一页，缺页标覆盖不全。
open 地址不同数量/支持币/同VM错链或再次存款可新报价，甚至精确同额也可能在 sweep 时重报价。Bitcoin 原请求可能 pending，supersededByRequestId 仅当前BVM可作线索；其他链旧请求可从 requests 消失而 status 一直 waiting。空结果也可能权限/过滤限制，不证明没存款。
检查结果：记录稳定地址、实际存款和新的 requestId，旧waiting不再单独作为卡住依据。
3. 把状态与目的链交易对应
对匹配请求保存 status 的时间序列：waiting 是等存款确认，pending 是已确认待目标提交，submitted 已提交仍未成功，success 表示 fill，refund 是退款，failure 是未完成。正文有 delayed，而当前 enum 没有，看到原值应保留处理中不抹掉。
用 data.inTxs/outTxs 的 chainId/txHash/status 与已有目的链浏览器记录对应，确认目标收款地址和资产。quote-time check 的旧请求不能覆盖新请求；对象updatedAt字段单位描述不足，不统一将所有数值按秒或毫秒转换。
检查结果：状态属于真正fill请求；成功、提交与到账证据分别记录。
4. 按模式处理少付、多付与退款条件
strict少付退款；EXACT_INPUT多付全部参与fill、超额不退，EXACT_OUTPUT按原量fill并另退超额。open按实际数量重报价，太小可能无法处理：当前正文$0.05及以下不sweep，阈值按USD转换，不是固定0.05ETH或USDC。
退款正文和deposit-address规则要求refundTo；open缺省则禁自动退款无回退，strict必填。通用quote schema却描述默认recipient/user，不能据此补造本单退款地址，查看实际记录。origin swap后的可退资产是存入depository的币，扣退款Gas，非承诺全额原币。
检查结果：少付/多付结论依模式和tradeType，退款地址、币和扣费均有证据。
5. 区分退款转账、失败原因与恢复权限
看 failReason 与 refundFailReason：BLOCKED_WALLET可阻止自动退款需支持审查，AMOUNT_TOO_LOW_TO_REFUND、NEGATIVE_NEW_AMOUNT_AFTER_FEES、VASP等需单列；字段null/N/A或未知不强制改成“无问题”。TRANSACTION_NOT_INCLUDED已有hash还可能以后确认，SUBMISSION_FAILED可能根本无hash。
auto-depositor退款的两个outTxs中，正文第一个才实际返还资金、第二个是内部settlement；对实际hash/链/收款人核对，别计两次。退款到CEX热钱包或集成方地址不证明用户余额已入账；recoveryAddress仅有withdraw恢复权限，不是退款接收地址。data.claimStatus=claimed只是claimAPI处理，不是链上提款确认。
检查结果：用户退款腿与内部记录分开，恢复权限、已处理和真实到账不同。
6. 标出无法自动恢复的范围并收集支持材料
non-solver币或NFT不属正常恢复；sameVM错链的open地址可能需reindex，strict没有自动wrongchain恢复，不能把接口能发现资金当可退保证。需要支持排查时提供地址模式、原/新requestId、两侧链、币、hash、数量、失败字段和时间，不提供秘密或key。
比较现有 data.fees.quoted/actual 与 data.route.quoted/actual，未知/null不填零，费用按execution/swap/platform/app/sponsored分项。将结论写为已fill、已退款到哪个地址、处理中或待人工恢复；官方withdraw/reindex是有行为的恢复流程，不作为只读诊断按钮执行。
检查结果：输出该存款的追踪结果、费用/退款范围和需人工处理的具体证据。
怎样确认完成
- 每条结论绑定充值地址、存款hash和实际fill/退款请求，未覆盖页与权限空值保留。
- 文档核验完成，不是实际存款、状态API、reindex/withdraw/claim、退款或余额验收。
常见错误与边界
- 旧requestId长期waiting不证明未fill；重报价订单按depositAddress查。
- 充值地址可复用不等于任何币/链都可恢复，strict不应复用。
- 退款可扣Gas、改资产或被筛查阻止；CEX退款和claimed标记不是用户到账证明。