Kraken Dead Man's Switch API 准备清单
已验证事实边界
1. Kraken futures documentation says the dead man's switch endpoint triggers a countdown timer using a timeout specified in seconds. 2. Kraken futures documentation says expiring the timer cancels all user orders, and a timeout of zero deactivates the mechanism. 3. Kraken futures documentation recommends refreshing every 15 to 20 seconds with a 60-second timeout. 4. Kraken futures documentation lists possible errors including authenticationError, apiLimitExceeded, nonceDuplicate and nonceBelowThreshold. 5. Kraken spot Cancel All Orders documentation identifies the cancel-all action and required order permissions for spot REST. 6. The readiness record must separate futures endpoint behavior, spot cancel-all behavior, key permission, timer refresh, server time, rate limits and post-cancel order reconciliation.
收起完整分析
决策矩阵
文章表格：可横向滑动，或聚焦表格区域后使用方向键。
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Endpoint scope | futures dead-man behavior and spot cancel-all behavior are not the same control | identify market, product lane and endpoint before testing | whether a strategy spans both surfaces |
| Authentication | APIKey and Authent headers must be valid before the timer matters | test auth failure handling and never log secrets | whether credential rotation changes behavior mid-run |
| Refresh cadence | the timer protects only if refresh calls happen predictably | run a local scheduler test with clock and network jitter | whether the runtime pauses during system sleep |
| Zero deactivation | timeout zero is a special off switch | test deactivation in a harmless environment | whether a later worker accidentally re-enables the timer |
| Error handling | rate limit and nonce errors can break the refresh loop | alert on error classes and pause order placement | whether retries create duplicate risk |
| Reconciliation | cancel trigger does not by itself prove final position safety | query open orders, fills and positions after expiry | whether partial fills occurred before cancellation |
来源地图
- Kraken API Center：Dead man's switch（kraken-deadman）
- Kraken API Center：Cancel All Orders（kraken-cancel-all）
- Kraken API Center：Get API Key Info（kraken-key-info）
控制说明
1. Endpoint scope
这一项要求读者把公开来源翻译成操作规则。这里的含义是：futures dead-man behavior and spot cancel-all behavior are not the same control。可执行动作是：identify market, product lane and endpoint before testing。仍然未知的是：whether a strategy spans both surfaces。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、安全保证、恢复保证、平台排名或价格暗示。
2. Authentication
这里的含义是：APIKey and Authent headers must be valid before the timer matters。可执行动作是：test auth failure handling and never log secrets。仍然未知的是：whether credential rotation changes behavior mid-run。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
3. Refresh cadence
这里的含义是：the timer protects only if refresh calls happen predictably。可执行动作是：run a local scheduler test with clock and network jitter。仍然未知的是：whether the runtime pauses during system sleep。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
4. Zero deactivation
这里的含义是：timeout zero is a special off switch。可执行动作是：test deactivation in a harmless environment。仍然未知的是：whether a later worker accidentally re-enables the timer。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
5. Error handling
这里的含义是：rate limit and nonce errors can break the refresh loop。可执行动作是：alert on error classes and pause order placement。仍然未知的是：whether retries create duplicate risk。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
6. Reconciliation
这里的含义是：cancel trigger does not by itself prove final position safety。可执行动作是：query open orders, fills and positions after expiry。仍然未知的是：whether partial fills occurred before cancellation。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
仍需明确的未知项
- whether a strategy spans both surfaces
- whether credential rotation changes behavior mid-run
- whether the runtime pauses during system sleep
- whether a later worker accidentally re-enables the timer
- whether retries create duplicate risk
- whether partial fills occurred before cancellation
实用结论
Kraken 的 dead man's switch 应被视为断线控制机制，而不是泛化安全标签。Kraken futures 文档说明，cancelallordersafter endpoint 允许用户提交秒级 timeout，开始倒计时，并在超时后取消所有用户订单；用户必须持续刷新 timeout，或通过指定 0 来停用。文档建议每 15 到 20 秒调用一次，并提供 60 秒 timeout。实用准备清单是：在真实策略依赖它之前，先测试 authentication、refresh cadence、zero deactivation、server time、rate-limit errors、order scope 与 recovery evidence。 本文停在证据边界内，帮助读者决定下一步核验什么，而不是把公开文档改写成私人账户、钱包、API key、池子路径、稳定币余额、代币化资产或政策框架在任何未来条件下都能成功的承诺。
相关专题与工具:交易所 API 与行情数据核查
来源与证据
03- Dead man's switch · docs.kraken.com
- Cancel All Orders · docs-legacy.kraken.com
- Get API Key Info · docs.kraken.com