deBridge 显示已成交，源链为何仍锁定：核对DLN订单与解锁阶段
链小知 · 进阶 · 核验 · 依官方文档整理
按订单ID对照目标链付款、源链solver结算和hook状态，避免把仍未ClaimedUnlock的订单误判为用户没有收到目标资产。
开始前准备
- 准备已有脱敏的源创建交易、orderId、give/take链与目标接收人；可用官方schema建立字段表，但没有实际记录不能宣称订单成功。
- 如有订单API记录，保留完整baseURL/方法、HTTP与响应时间；订单ID、交易hash、DMP submissionId分开，凭据不分享。
- 适用DLN Tracking stats API v1文档，不是dePort包装资产、DMP普通消息或Swap quote/create-tx的执行教程。
1. 从创建交易对应全部订单ID
记录源链创建交易和orderId，而非仅钱包地址或网页显示名称。Tracking说明GET /api/Orders/creationTxHash/{hash}在一交易多订单时只返回第一个；如果既有记录来自此方法，要检查是否遗漏同一交易的其他订单。
完整ID列表对应GET /api/Transaction/{hash}/orderIds的orderIds数组。只核对已有列表，不把一个hash当唯一orderId；原Order或CreatedOrder中give/take参数与接收人必须对上。链表的internal ID不一定是native ID，例如HyperEVM999与100000022不同。
检查结果：每条目标转移都有自身orderId及源/目标链，批量创建的遗漏保持未知。
2. 按具体方法读取状态形状
Tracking基址是https://dln-api.debridge.finance，Swap基址是https://dln.debridge.finance，两者路径不能混接。当前GET /api/Orders/{orderId}/state的200 schema直接返回OrderState字符串；GET /api/Orders/{orderId}定义为OrderDTO，状态字段为state。
Tracking快速示例却用status。先保存原响应形状与字段，不固定读response.status或把缺state改为Created。None、null、缺字段或未识别枚举分别标待核；它们不等于源链交易失败或链上不存在。
检查结果：核对表明确方法、版本、实际字段与原状态，不以示例外壳覆盖真实记录。
3. 对照目标付款的身份、数量和事件
Fulfilled按状态正文表示solver已将所需目标资产交给dstChainTokenOutRecipient。完整OrderDTO中核对receiverDst.stringValue、takeOfferWithMetadata.chainId/tokenAddress、actualFulfillAmount和fulfilledDstEventMetadata.transactionHash.stringValue。
数量字段可能是带stringValue/bigIntegerValue的DTO，保留精确十进制字符串并与该token的decimals核对，不用JavaScript Number截断大整数。目标tx hash属于take链；事件缺失/null时不能根据主状态补出一笔交易或认定目标付款已经独立复验。
检查结果：目标接收人、token、chain、原始数量和履约交易可追溯；API表述与另行已有链上结果分别记录。
4. 把源锁定与solver结算拆开
Fulfilled是目标已履约，SentUnlock是solver发送DMP消息，ClaimedUnlock才是源锁资产被solver领取。用户是否取得目标资产与solver是否完成源结算是两件事，源锁仍存在不能单独推翻目标履约。
分别对照sentUnlockDstEventInfo、claimedUnlockSrcEventInfo的transactionMetadata与submissionId。只出现发送消息不代表源领取；源claim交易不等于目标给用户的tx。若参数不同导致orderId不匹配，不能把另一笔solver转账套作本订单解锁。
检查结果：每个阶段都有对应链和原事件，缺源claim写“源结算待核”，不直接写“用户未成交”。
5. 另查hook是否执行完成
主state与externalCallState分列。Fulfilled不自动等于额外hook Completed；externalCallState有NoExtCall、AwaitingExecution、Executing、Completed、Failed、Cancelled等，具体失败应保留实际错误与外部执行证据。
Tracking的完成订单列表示例用了externalCallStates:['NoExtCall']，这种过滤会排除带hook的订单，不适合汇总全部成交。externalCallData在只有create事件时可能为hash、已tracked fulfill时为完整结构；不能将hash当已执行结果。
检查结果：主履约、源结算、hook三栏独立，没有将NoExtCall过滤漏项说成订单消失。
6. 按错误和分页范围结束排查
状态/详情方法列400、422、500；保存message与errorCode，422业务码可异于HTTP码。官方Status&Limits列429、公共50RPM/认证300RPM及各endpoint独立额度；不要将限速/权限失败转换为空订单或0金额。
若记录来自POST filteredList，检查skip/take（方法最大页100）、orders（可null）、totalCount以及maker/filter与状态条件；时间过滤blockTimestampFrom/To为创建事件秒、含>=/<=边界。缺页、不同条件或滚动排序只说明记录范围不足，不拿totalCount替代逐订单履约核对。
检查结果：结论区分目标履约、源solver结算、hook、错误与列表缺口；未知原因有具体补证字段。
怎样确认完成
- 输出按orderId的目标履约、源结算、hook与原错误表；无独立目标交易证据时明确只取得API/文档状态。
- 列表/批量交易范围、时间与未知阶段明确；没有发送新API/quote或执行解锁。
常见错误与边界
- 把源链Created/锁定余额当目标未成交，或把ClaimedUnlock当给用户的目标收款。
- 同一创建交易只取首个order；固定读status而忽略当前OrderDTO.state与字符串state方法。
- 将NoExtCall示例当全订单查询，或把fulfilledDstEventMetadata的目标hash放进源链查。
- blockTimeStamp在详情schema只说明事件时间而未注明单位；不要把列表明确seconds规则自动推广所有返回时间。