Binance、Kraken 与 OKX Cancel-All-After 订单安全控制
已验证事实边界
1. Binance Spot WebSocket API documentation includes openOrders.cancelAll for cancelling all open orders on one symbol. 2. Kraken official WebSocket documentation describes cancelAllOrdersAfter as an authenticated cancel-on-disconnect control. 3. OKX API documentation includes a cancel-all-after endpoint under its order-book trading API. 4. Binance signed endpoints require timestamp and recvWindow controls, so request timing is part of cancellation safety evidence. 5. A cancel request or timer acknowledgement does not alone prove that every private order reached a terminal cancelled state. 6. The safe decision record keeps venue acknowledgement, final order-state query, reconnect gap and manual pause authority separate.
收起完整分析
决策矩阵
文章表格:可横向滑动,或聚焦表格区域后使用方向键。
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Action type | one venue exposes an immediate cancel-all action while another documents a timer-based safety switch | label each control as immediate cancel, timer refresh, timer deactivate or status backfill | whether a private account has product-specific access to the endpoint |
| Scope | symbol-specific cancellation and account-wide timeout controls have different blast radii | record symbol, market type, account, portfolio and product family before sending a request | hidden subaccount or portfolio routing outside the local bot model |
| Signed timing | signed endpoints depend on timestamp, recvWindow or equivalent authentication freshness | sync clocks and log non-secret request ids before production use | network jitter during market stress |
| Acknowledgement | a successful request response can still precede final venue state | query order state after acknowledgement before releasing new risk | fills that race against the cancellation window |
| Reconnect gap | a websocket drop can hide the transition between open, partially filled and cancelled | backfill from REST or account history after reconnect | whether every interim transition remains recoverable |
| Evidence hygiene | the decision record should prove control behavior without exposing credentials | store endpoint, time, product, symbol and state label without secrets | internal retention policy for incident logs |
| Stop rule | automation should not continue when venue and local state disagree | pause new orders until final order state is reconciled | who can manually override during an incident |
来源地图
- Binance Developer Documentation:Trade - Spot WebSocket API(binance-ws-trade-cancel-all)
- Kraken API Center:Cancel on Disconnect(kraken-cancel-on-disconnect)
- OKX Technical Support:Trade REST API cancel-all-after(okx-cancel-all-after)
- Binance Developer Documentation:General REST API Information(binance-spot-rest-timing)
控制说明
1. Action type
这一项要求读者先把公开来源翻译成操作规则。这里的含义是:one venue exposes an immediate cancel-all action while another documents a timer-based safety switch。可执行动作是:label each control as immediate cancel, timer refresh, timer deactivate or status backfill。仍然未知的是:whether a private account has product-specific access to the endpoint。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、恢复保证、结算保证、可用性保证、价格暗示或平台排名。
2. Scope
这里的含义是:symbol-specific cancellation and account-wide timeout controls have different blast radii。可执行动作是:record symbol, market type, account, portfolio and product family before sending a request。仍然未知的是:hidden subaccount or portfolio routing outside the local bot model。
操作测试也必须很窄。这就是本节保留边界的原因。
3. Signed timing
这里的含义是:signed endpoints depend on timestamp, recvWindow or equivalent authentication freshness。可执行动作是:sync clocks and log non-secret request ids before production use。仍然未知的是:network jitter during market stress。
操作测试也必须很窄。这就是本节保留边界的原因。
4. Acknowledgement
这里的含义是:a successful request response can still precede final venue state。可执行动作是:query order state after acknowledgement before releasing new risk。仍然未知的是:fills that race against the cancellation window。
操作测试也必须很窄。这就是本节保留边界的原因。
5. Reconnect gap
这里的含义是:a websocket drop can hide the transition between open, partially filled and cancelled。可执行动作是:backfill from REST or account history after reconnect。仍然未知的是:whether every interim transition remains recoverable。
操作测试也必须很窄。这就是本节保留边界的原因。
6. Evidence hygiene
这里的含义是:the decision record should prove control behavior without exposing credentials。可执行动作是:store endpoint, time, product, symbol and state label without secrets。仍然未知的是:internal retention policy for incident logs。
操作测试也必须很窄。这就是本节保留边界的原因。
7. Stop rule
这里的含义是:automation should not continue when venue and local state disagree。可执行动作是:pause new orders until final order state is reconciled。仍然未知的是:who can manually override during an incident。
操作测试也必须很窄。这就是本节保留边界的原因。
仍需明确的未知项
- whether a private account has product-specific access to the endpoint
- hidden subaccount or portfolio routing outside the local bot model
- network jitter during market stress
- fills that race against the cancellation window
- whether every interim transition remains recoverable
- internal retention policy for incident logs
- who can manually override during an incident
实用结论
Binance、Kraken 与 OKX 的订单取消安全控制并不相同,因此自动化 runbook 应区分即时 cancel-all 动作和基于计时器的 cancel-on-disconnect 控制。Binance 文档说明 Spot WebSocket API 中撤销单一交易对所有挂单的方法,Kraken 文档说明 authenticated cancelAllOrdersAfter WebSocket 控制,OKX 文档说明 cancel-all-after 交易端点。实用结论是:先定义 symbol scope、timeout scope、signed-request timing、acknowledgement evidence、final order-state backfill 与暂停规则,再把本地机器人视为已清仓。 本文停在证据边界内,帮助读者决定下一步核验什么,而不是把公开文档改写成私人账户、钱包、回调、政策框架、结算路径或流动性头寸在任何未来条件下都能成功的承诺。
相关专题与工具:对比 Binance 与 Kraken对比 Binance 与 OKX
来源与证据
04- Trade - Spot WebSocket API · developers.binance.com
- Cancel on Disconnect · docs-legacy.kraken.com
- Trade REST API cancel-all-after · okx.com
- General REST API Information · developers.binance.com