A crypto dead man's switch is an exchange-side timer that cancels eligible open orders if the client stops renewing it. It removes the unfilled quantity covered by that venue's rules; it does not reverse fills or close existing positions. Before enabling one, verify the timer units, renewal response, cancellation scope and restart behavior, including whether resting protective orders can be removed.
Three controls answer different questions
The useful question is what should happen when the application can no longer supervise its orders. A dead man's switch gives the venue an instruction in advance, while communication still works. If accepted renewals stop, the venue's countdown can expire without a fresh cancellation request from the disconnected client.
That mechanism differs from two controls an operator may already use:
| Control | What starts the action? | What must be checked? |
|---|---|---|
| Exchange dead man's switch | A renewable venue timer expires. | Eligible order set, accepted renewals and actual cancellation results. |
| Local kill switch | An application rule or operator changes local control state. | Whether new submissions stop and which separate cancellation actions execute. |
| Good-till-date order | A specified order reaches its expiry boundary. | Accepted expiry, final order state and any intervening fills. |
The existing trading-bot kill-switch guide covers local emergency controls. The good-till-date order guide covers individual expiry instructions. Here the central problem is maintaining a venue timer without accidentally keeping abandoned orders alive or canceling another workflow's orders.
Renew the timer only on evidence of health
Kraken Spot's CancelAllOrdersAfter endpoint uses a timeout in seconds. A new nonzero request resets the countdown to its supplied timeout; zero disables it. Kraken recommends calls every 15–30 seconds with a 60-second timeout. After expiry, its timer remains disabled until another nonzero timeout is supplied. These are Kraken's documented settings, rather than universal exchange defaults. Kraken Spot: Cancel All Orders After X.
Treat a successful renewal as permission for covered orders to remain active for another interval. Keep the last confirmed renewal, the returned trigger time where available, and the account and product associated with it. Sending a request is not evidence that the venue accepted the extension.
A missing response creates uncertainty: the venue may have accepted the renewal while its response was lost, or the request may never have arrived. Preserve both possibilities until supported evidence resolves them. The previous confirmed deadline is an observation, not proof that a later unacknowledged request had no effect.
The process sending renewals should also check the health that matters to the strategy. A separate timer worker can remain alive while the order manager is frozen or its market data is stale. Unconditional renewal would preserve exactly the unattended orders the mechanism was meant to retire. Define explicit health conditions, such as a responsive owner process and sufficiently recent verified account state, before extending the timer.
Choose the interval and timeout together. Leave room for request transit, processing and local scheduling delays between a planned renewal and expiry. A longer timeout tolerates more interruption while leaving unattended orders working longer; a shorter one can cancel them during an otherwise recoverable delay. Document that tradeoff against the order's purpose, and include renewal traffic in the request budget.
Identify the cancellation set before arming it
OKX demonstrates why the scope needs its own record. Its Cancel All After documentation covers pending order-book trading orders, excluding Spread trading. Without a tag, the described cancellation scope is the sub-account; with a tag, only matching tagged orders are affected. Its timeout uses seconds, permits zero to disable or 10–120 to enable, and its documentation recommends a heartbeat every second. OKX: Cancel All After parameters and scope.
An order's label inside your application does not establish that it belongs to the exchange's cancellation set. Record the actual venue identifiers:
| Scope question | Evidence to retain | Failure to expose |
|---|---|---|
| Which account and product? | Environment, account identity and endpoint | A timer configured for a different execution account. |
| Which orders? | Supported types, symbols and any tags | An untagged order escaping a tag-scoped timer. |
| Which protective instructions? | Actual resting or conditional order categories | Cancellation removing an exit, or an assumed exit remaining outside scope. |
| Who may renew? | Owner process and shared-scope policy | Another process extending a timer after its intended owner fails. |
For a quote-based workflow, establish whether a displayed price is indicative or firm using the RFQ quote distinction. Then verify that product's lifecycle separately. An order-book cancellation endpoint's existence does not establish how an RFQ expires or whether an accepted trade can be canceled.
A missed renewal does not mean immediate cancellation
Consider this hypothetical venue model: the timeout is 60 seconds, the client plans to renew every 20 seconds, and the venue cancels covered remainders after expiry. The account starts with no ETH and submits a 0.50 ETH spot buy at an illustrative limit of 2,000 USDT per ETH. Every fill below occurs at that limit; fees and other activity are excluded.
The three-second cancellation completion interval is invented for this exercise. It is not a measured Kraken or OKX latency. Assume later evidence establishes that the failed renewal never reached the venue.
| UTC time | Constructed event | State that follows |
|---|---|---|
| 09:00:00 | Venue accepts a 60-second timer. | Trigger is 09:01:00. |
| 09:00:20 | Venue accepts another 60-second renewal. | Trigger moves to 09:01:20. |
| 09:00:37 | 0.10 ETH fills; communication then fails. | 0.40 ETH remains on the order. |
| 09:00:40 | Scheduled renewal does not reach the venue. | Trigger stays at 09:01:20. |
| 09:00:55 | Another 0.15 ETH fills unseen by the client. | Actual inventory is 0.25 ETH; 0.25 ETH remains. |
| 09:01:20 | Timer expires and cancellation begins. | Completion has not yet been established. |
| 09:01:21 | A further 0.05 ETH fills before cancellation completes. | Inventory becomes 0.30 ETH; 0.20 ETH remains. |
| 09:01:23 | Final evidence confirms the remainder canceled. | No quantity remains working on this order; 0.30 ETH is still held. |
The deadline is the last accepted renewal time plus the timeout: 09:00:20 + 60 seconds = 09:01:20. Missing the 09:00:40 renewal leaves 40 seconds until the modeled trigger. It does not cause an immediate cancel at 09:00:40.
The acquired quantity is 0.10 + 0.15 + 0.05 = 0.30 ETH, worth 600 USDT at the assumed execution price. The canceled remainder is 0.50 − 0.30 = 0.20 ETH, with 400 USDT of limit notional. These reconcile to the original 1,000 USDT order notional. Cancellation prevents that remaining instruction from buying more; it does not sell the 0.30 ETH already acquired.
The delay distinction has an explicit venue example: OKX says its engine cancels affected orders one by one after triggering, and the operation can take a few seconds. The trigger boundary therefore should not be treated as evidence that every covered order is already terminal. OKX: cancellation processing after the timer triggers.
Shared timers and maintenance create different failures
A healthy peer can conceal a failed owner
If several strategies share one countdown, a healthy strategy's renewals may keep the failed strategy's orders alive. Conversely, a process using a shorter timeout or disabling the shared timer can change another strategy's protection policy. Merely assigning different local bot names does not create independent venue timers.
Use separate supported scopes where appropriate, or appoint one coordinated owner whose health policy accounts for every covered strategy. Test that two processes cannot silently overwrite each other's intended state. Where venue-supported tags isolate timers, verify that order placement actually carries the intended tag.
Scheduled downtime changes the operating procedure
Kraken recommends disabling its timer ahead of scheduled trading-engine maintenance; it warns that enabled timers can cancel orders when the engine returns from planned or unplanned downtime. That documented behavior needs a maintenance plan, rather than an assumption that the timer always acts during the outage itself. Kraken: timer behavior around maintenance.
Disabling a timer changes the unattended-order policy. Decide which orders should remain, resolve any intended cancellations and record who supervises existing exposure during the maintenance window. A zero timeout disables the countdown; it is not an immediate cancel-all command.
Verify the result before restarting
Keep new submissions gated while recovering the last known timer state, original order identifiers, final fills and remaining orders. The WebSocket recovery guide explains the separate work needed to restore market continuity and account observations. A live connection alone cannot resolve an unseen fill.
Review protective orders individually. If a covered resting exit was canceled, the corresponding position can remain while its exit instruction is gone. If an order category was outside scope, it may still be active. For perpetual positions, also review continuing holding obligations: funding-rate caps and floors concern the rate boundary, not cancellation of the position that incurs funding.
A useful acceptance exercise records five results in a supported test environment or tabletop model:
- Healthy renewals repeatedly move the acknowledged trigger forward.
- Suppressing renewals permits the expected scope to expire while unrelated orders follow their own rules.
- A lost response is retained as uncertain, including the case where the venue accepted it.
- Fills during the observation gap remain in the recovered inventory ledger.
- Restart explicitly restores the required timer state before new orders rely on it.
For Kraken's documented one-shot expiry behavior, the fifth check includes a fresh nonzero timeout after a trigger. Do not assume that reconnecting automatically arms it again.
Before enabling a dead man's switch, produce one reviewable record: the covered order set, the renewal health conditions, the last acknowledged deadline and the evidence required to declare cancellation complete. Use it during the next outage to recover the account state within known boundaries.