Kraken 与 Deribit 断线撤单雷达：超时、作用域与故障状态控制

已核验的来源事实

1. Kraken Futures 说明，其倒计时超时后会撤销用户订单，除非客户端续期或关闭该功能。 2. Kraken 建议采用每 15–20 秒刷新一次、超时 60 秒的示例运行方式。 3. Deribit 说明断线撤单仅用于 WebSocket，并提供连接与账户作用域；连接作用域不会影响其他连接创建的订单。 4. Deribit 表示心跳可以改善断线触发，且 private logout 不会触发断线撤单。

对照表

1. 控制测试：激活

交易控制披露只有转换成可测试规则才有意义。激活需要检查倒计时请求或 WebSocket 设置。应使用沙箱、非生产环境或最小可逆测试，然后明确执行激活。可以保存配置和事件证据，但绝不能记录凭据，并应验证文档所述的撤单、拒绝、减量或历史记录行为。

审计要模拟失败路径，而不只看设置流程。需要追问哪套策略拥有 maker 与 taker 订单、平台按哪个账户边界判断、哪个消息能证明干预，以及部分成交或断线后如何对账。平台文档只能说明支持什么，不能证明操作者配置正确。账户默认值因此必须保留为明确缺口。

激活这一行最终应形成一条与倒计时请求或 WebSocket 设置绑定的监控规则。执行者应明确执行激活，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，账户默认值仍是独立生产风险。

2. 控制测试：作用域

作用域需要检查用户、账户或连接的订单归属。应使用沙箱、非生产环境或最小可逆测试，然后按会话标记每个订单。

审计要模拟失败路径，而不只看设置流程。跨会话行为因此必须保留为明确缺口。

作用域这一行最终应形成一条与用户、账户或连接的订单归属绑定的监控规则。执行者应按会话标记每个订单，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，跨会话行为仍是独立生产风险。

3. 控制测试：超时

超时需要检查撤单前延迟。应使用沙箱、非生产环境或最小可逆测试，然后用可测网络故障测试。

审计要模拟失败路径，而不只看设置流程。交易所端调度因此必须保留为明确缺口。

超时这一行最终应形成一条与撤单前延迟绑定的监控规则。执行者应用可测网络故障测试，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，交易所端调度仍是独立生产风险。

4. 控制测试：心跳

心跳需要检查失效连接检测。应使用沙箱、非生产环境或最小可逆测试，然后监控请求与响应频率。

审计要模拟失败路径，而不只看设置流程。静默网络分区因此必须保留为明确缺口。

心跳这一行最终应形成一条与失效连接检测绑定的监控规则。执行者应监控请求与响应频率，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，静默网络分区仍是独立生产风险。

5. 控制测试：正常关闭

正常关闭需要检查logout 与异常断线。应使用沙箱、非生产环境或最小可逆测试，然后分别测试两个分支。

审计要模拟失败路径，而不只看设置流程。客户端库行为因此必须保留为明确缺口。

正常关闭这一行最终应形成一条与logout 与异常断线绑定的监控规则。执行者应分别测试两个分支，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，客户端库行为仍是独立生产风险。

6. 控制测试：部分成交

部分成交需要检查撤单前已经成交的数量。应使用沙箱、非生产环境或最小可逆测试，然后替换前核对成交。

审计要模拟失败路径，而不只看设置流程。竞态时间因此必须保留为明确缺口。

部分成交这一行最终应形成一条与撤单前已经成交的数量绑定的监控规则。执行者应替换前核对成交，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，竞态时间仍是独立生产风险。

7. 控制测试：订单类别

订单类别需要检查普通、触发及其他挂单。应使用沙箱、非生产环境或最小可逆测试，然后建立明确覆盖矩阵。

审计要模拟失败路径，而不只看设置流程。未来产品增加因此必须保留为明确缺口。

订单类别这一行最终应形成一条与普通、触发及其他挂单绑定的监控规则。执行者应建立明确覆盖矩阵，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，未来产品增加仍是独立生产风险。

8. 控制测试：重连

重连需要检查新会话建立后的状态。应使用沙箱、非生产环境或最小可逆测试，然后查询权威未完成订单。

审计要模拟失败路径，而不只看设置流程。延迟撤单因此必须保留为明确缺口。

重连这一行最终应形成一条与新会话建立后的状态绑定的监控规则。执行者应查询权威未完成订单，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，延迟撤单仍是独立生产风险。

9. 控制测试：权限

权限需要检查管理订单所需 API 范围。应使用沙箱、非生产环境或最小可逆测试，然后应用最小权限。

审计要模拟失败路径，而不只看设置流程。凭据泄露因此必须保留为明确缺口。

权限这一行最终应形成一条与管理订单所需 API 范围绑定的监控规则。执行者应应用最小权限，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，凭据泄露仍是独立生产风险。

10. 控制测试：证据

证据需要检查触发时间、撤单结果与剩余订单。应使用沙箱、非生产环境或最小可逆测试，然后保留非秘密事件记录。

审计要模拟失败路径，而不只看设置流程。保存期限因此必须保留为明确缺口。

证据这一行最终应形成一条与触发时间、撤单结果与剩余订单绑定的监控规则。执行者应保留非秘密事件记录，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，保存期限仍是独立生产风险。

决策场景

场景 1：当激活成为关键约束

假设读者最关心的是倒计时请求或 WebSocket 设置，正确做法不是寻找一个适用于所有人的赢家，而是明确执行激活，保存证据，并在投入资金或权限前定义停止条件。只要证据变化，就重新打开决策，而不是继续沿用旧结论。这样得到的是一条能够重复执行的操作规则，而不是一次性的主观看法。

场景 2：当作用域成为关键约束

假设读者最关心的是用户、账户或连接的订单归属，正确做法不是寻找一个适用于所有人的赢家，而是按会话标记每个订单，保存证据，并在投入资金或权限前定义停止条件。

场景 3：当超时成为关键约束

假设读者最关心的是撤单前延迟，正确做法不是寻找一个适用于所有人的赢家，而是用可测网络故障测试，保存证据，并在投入资金或权限前定义停止条件。

场景 4：当心跳成为关键约束

假设读者最关心的是失效连接检测，正确做法不是寻找一个适用于所有人的赢家，而是监控请求与响应频率，保存证据，并在投入资金或权限前定义停止条件。

场景 5：当正常关闭成为关键约束

假设读者最关心的是logout 与异常断线，正确做法不是寻找一个适用于所有人的赢家，而是分别测试两个分支，保存证据，并在投入资金或权限前定义停止条件。

场景 6：当部分成交成为关键约束

假设读者最关心的是撤单前已经成交的数量，正确做法不是寻找一个适用于所有人的赢家，而是替换前核对成交，保存证据，并在投入资金或权限前定义停止条件。

常见问题

本文是否建议使用或避开某个平台或产品？

不是。它是一套基于来源的决策框架。最终结论取决于用户地区、签约实体、账户、产品、交易规模、风险承受能力与实时条款。

公布的费率或控制措施是否永久有效？

不是。公开费率和控制规则会变化，实际条款也可能针对账户。应核对登录后的实时页面。

页面返回 HTTP 200 是否证明产品正常可用？

不能。公开页面存在，不代表特定地区或账户一定能使用该产品，账户级证据才是最终依据。

为什么必须公开列出未知事项？

因为用假设填补证据空白会制造虚假精确。未知事项说明下一步应该核验什么。

最安全的第一步是什么？

写清具体任务，核验官方来源，采用最小权限和最可逆的路径，并在适合时先做小额测试。