> For the complete documentation index, see [llms.txt](https://nytshift.gitbook.io/nytshift-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nytshift.gitbook.io/nytshift-docs/hyperliquid/hyperliquid-dead-man-switch.md).

# Venue dead-man switch

Use this runbook whenever Hyperliquid execution readiness reports `DEAD MAN TESTNET REHEARSAL REQUIRED`, `DEAD MAN SWITCH REQUIRED`, an elapsed venue deadline, an unknown heartbeat, or open orders remaining after reconciliation. This safety mechanism does not replace the entry kill switch, per-order cancellation, bracket reconciliation, API-wallet revocation, or authoritative portfolio reconciliation.

## Fixed semantics

* NIGHTSHIFT schedules a venue-native cancel-all deadline 30 seconds in the future.
* Authenticated operator-presence heartbeats run every ten seconds and must remain monotonically sequenced.
* Every arm/heartbeat/disarm re-reads the primary plus every discovered named perp DEX before a signed schedule action.
* An ACK is schedule evidence only. It is never cancellation evidence.
* Hyperliquid permits at most ten deadline **triggers** per UTC day. Do not intentionally let repeated rehearsals or incidents consume that allowance without recording the reason and remaining operational capacity.
* Never retry an `uncertain`, timeout, 5xx-after-attempt, malformed-ACK, or lost-response action. Preserve the store and reconcile after the retained deadline.

## State meanings

| State                                        | Meaning                                                        | Operator action                                                                  |
| -------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| `unconfigured` / `disarmed`                  | No active retained venue schedule                              | Keep execution locked or explicitly review arm                                   |
| `arming` / `heartbeat-pending` / `disarming` | A venue-changing action has begun                              | Do not send another action                                                       |
| `armed`                                      | Latest deadline ACK is retained                                | Keep the authenticated terminal mounted and watch heartbeat/ACK time             |
| `uncertain`                                  | A signed schedule action may or may not have reached the venue | Stop heartbeats, wait for the retained deadline, then reconcile                  |
| `expired`                                    | Retained deadline has elapsed                                  | Reconcile exact all-DEX and CLOID evidence                                       |
| `reconciled-clear`                           | Exact read found zero open orders                              | Review evidence; testnet proof still depends on exact `scheduledCancel` status   |
| `attention-required`                         | Open orders remain                                             | Use separately reviewed per-order cancellation as needed, then re-arm protection |

## Before arming

1. Confirm the supervised signer health is exact for the intended network/account and execution-store schema v8 is current, integrity `ok`, and WAL-backed.
2. Confirm the operator session is authenticated and the terminal shows a complete authoritative portfolio generation.
3. Confirm public Hyperliquid metadata is healthy with no schema drift and every discovered perp DEX is available.
4. Confirm the entry kill switch, eligibility, builder, alerting and account-scope gates are in their intended state.
5. Read the current dead-man state. Reconcile `expired` or `uncertain` before preparing another arm. Do not overwrite unknown evidence.
6. Select **Review arm**, read the exact network warning, then explicitly confirm before the 30-second review expires.
7. Verify `armed`, a future venue deadline, a recent venue ACK and an advancing heartbeat sequence. If any is missing, execution stays locked.

## Authenticated heartbeat incident

1. Stop order entry immediately. Do not close an open incident by refreshing the page or retrying the same request.
2. Record the last acknowledged deadline, sequence, open/tracked counts and reason from the terminal. Never copy the internal lease or any credential.
3. If the BFF reports a proven `not-attempted` preflight failure, no schedule refresh was sent; the previous retained deadline remains authoritative.
4. If the outcome is `uncertain`, allow the retained deadline to pass. Do not call arm, heartbeat or disarm while the outcome is unknown.
5. Select **Reconcile venue evidence** only after the deadline. Zero open orders produces `reconciled-clear`; any remaining order produces `attention-required`.
6. For remaining orders, use the normal reviewed cancellation path. Cancellation remains available even when entry readiness is locked. Re-arm only after reviewing the resulting state.
7. Preserve the signer database, audit and control-plane trace records for incident review.

## Safe disarm

1. Disarm is not an emergency-stop substitute. First verify the account should intentionally have no working Hyperliquid orders.
2. Select **Review disarm** and explicitly confirm.
3. The signer independently re-reads every perp DEX. Any open order produces a proven no-attempt rejection and leaves the previous schedule intact.
4. Only a default-action ACK to `scheduleCancel(None)` produces `disarmed`. If its outcome is unknown, never assume protection was removed; wait for the retained deadline and reconcile.

## Creating real testnet rehearsal evidence

This is a capital-affecting external action and requires separate explicit user authorization, an eligible intentionally funded testnet account and a user-owned API wallet. Repository tests do not create this proof.

1. Confirm the daily trigger budget and choose a tiny reviewed testnet resting order with an exact CLOID.
2. Arm the dead-man switch and verify the order is included in the retained tracked count.
3. Intentionally stop authenticated heartbeats and allow the acknowledged deadline to elapse once.
4. Reconcile after the deadline. Proof requires zero all-DEX open orders plus exact venue `scheduledCancel` status for at least one retained CLOID.
5. Confirm the terminal reports the testnet rehearsal completion time and 30-day validity window.
6. Record the trigger consumption and reconcile the full testnet account. Do not repeat merely to refresh UI state.

## Mainnet boundary

Mainnet submission remains impossible unless the same configured account has fresh testnet rehearsal proof, the venue switch is armed, more than five seconds remain, and the last heartbeat is no older than 15 seconds. All existing eligibility, account, kill-switch, portfolio, builder, alerting, canary, explicit confirmation and reconciliation gates remain mandatory. A real mainnet canary still requires separate final user authorization.

Official semantics: <https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint#schedule-cancel-dead-mans-switch>.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://nytshift.gitbook.io/nytshift-docs/hyperliquid/hyperliquid-dead-man-switch.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
