Binance 与 Kraken 订单故障保护和撤单控制清单

决策矩阵

来源地图

• Binance Developer Docs：Spot REST API Trade endpoints（binance-rest-trade-docs）
• Binance Developer Docs：Spot WebSocket API trading requests（binance-ws-trade-docs）
• Binance Support：Notice on Binance Spot API Update (2026-06-25)（binance-spot-api-update-20260625）
• Kraken API Center：Dead man switch（kraken-dead-man-switch）

控制说明

1. Failure mode

这一项要求读者先把公开来源翻译成操作规则。这里的含义是：connection loss, rate limit pressure, partial replace or timer expiry。可执行动作是：name the failure before choosing a venue control。仍然未知的是：private incident timing。因此本文不会把未知部分包装成安全承诺、收益承诺、官方背书、审批保证、可用性保证或注册诱导。

2. Cancel scope

这里的含义是：single order, order list, symbol orders or all futures orders。可执行动作是：avoid assuming one endpoint covers every order。仍然未知的是：account-specific open orders。

3. Replace behavior

这里的含义是：whether a new order is attempted after cancel failure。可执行动作是：choose STOP_ON_FAILURE style behavior where appropriate。仍然未知的是：strategy tolerance。

4. Rate-limit behavior

这里的含义是：what happens when unfilled order limits are exceeded。可执行动作是：predefine cancel-only fallback rules。仍然未知的是：real-time limit usage。

5. Timer cadence

这里的含义是：how often failover protection must be refreshed。可执行动作是：test refresh interval without live exposure。仍然未知的是：network jitter。

6. Reconnect rule

这里的含义是：what the venue tells users to do after WebSocket disconnect。可执行动作是：build resubscribe and state-recovery steps。仍然未知的是：missed private events。

7. Authentication

这里的含义是：which key/signature headers or scopes are required。可执行动作是：use least-privilege keys and no secret logging。仍然未知的是：permission drift。

8. Order-state reconciliation

这里的含义是：how local state is compared with venue state。可执行动作是：query venue state after reconnect or timeout。仍然未知的是：fills during outage。

9. Operator evidence

这里的含义是：non-secret logs, timestamps and source URLs。可执行动作是：record evidence without API secrets or balances。仍然未知的是：clock drift。

10. Stop rule

这里的含义是：when automation should stop instead of retrying。可执行动作是：stop on unknown order state, key scope or venue status。仍然未知的是：future API changes。

仍需明确的未知项

• private incident timing
• account-specific open orders
• strategy tolerance
• real-time limit usage
• network jitter
• missed private events
• permission drift
• fills during outage
• clock drift
• future API changes

实用结论

本文最有价值的地方是克制。Binance 与 Kraken 的订单故障保护控制解决的不是同一个问题，因此对比应从失败模式开始，而不是从品牌开始。Binance 文档描述了 REST 与 WebSocket 的 cancelReplace 订单流，并说明过滤器和订单计数会在撤单与新订单处理前评估；orderRateLimitExceededMode 会影响超过未成交订单限制时是否仍尝试撤单。Binance 还公告过 Spot API 基础设施升级，期间 WebSocket 连接可能断开，用户需要重新连接。Kraken Futures 文档则描述 dead man switch 端点：若 timeout 到期且用户没有持续延长或关闭计时器，系统会取消用户所有订单。实用结论是：在自动化任一平台前，先分别映射替换逻辑、cancel-only 行为、连接恢复、计时器刷新频率、API 鉴权和私人订单状态对账。 用户应获得一个更清楚的核验路径，而不是一个看似肯定、实则无法由公开证据承担的承诺。