> 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-btc-one-x-testnet-campaign.md). # BTC one-X testnet campaign Status: prepared, not authorized and not started. The matching PAPER campaign passed 28 files and 236 tests on 2026-08-04. That result proves NIGHTSHIFT's offline state transitions; it does not prove venue execution. This runbook fixes the first venue campaign at Hyperliquid testnet, BTC only, 1x, one order or position, no customer capital and no more than $12 per order or gross exposure. It creates no account, wallet, funding, signature or order. ## Owner-controlled prerequisites All prerequisites are exact-account and exact-network checks. Raw addresses, keys, signatures, CLOIDs, cookies, tokens and URLs stay in protected operational stores and never enter this runbook or exported evidence. 1. The owner selects one dedicated Hyperliquid testnet master/subaccount. Reads use that account address, not the API-wallet address. 2. The owner creates and registers one fresh API wallet for this signer process. It is not the owner key, is not shared with another process/subaccount and is never reused after deregistration. 3. The API-wallet private key is installed only as a protected regular file outside the repository. The path-only offline doctor must derive the expected fingerprint with zero network requests. The signer stays stopped afterward. 4. The owner satisfies testnet funding eligibility. Hyperliquid's faucet currently requires a prior mainnet deposit from the same owner address; the deposit and faucet claim are separate owner-signed mutations. Neither action authorizes trading. 5. The exact builder identity and maximum fee are approved independently if the current NIGHTSHIFT signer fee path is retained. The standard configured rate is 20 tenths of a basis point (2 bps), but this runbook does not approve, change or submit that fee. 6. A current eligibility decision binds the account fingerprint, testnet, BTC, the policy digest and an expiry no more than 30 days away. 7. The signer store reports schema 8, WAL and integrity `ok`; a cold pre-campaign backup is verified. Customer PostgreSQL and account-digest state are ready. 8. Testnet signer scope independently reports BTC only, 1x maximum, $12 order and gross ceilings and one concurrent exposure. Mainnet and Arcus execution remain disabled; the entry kill switch remains active during setup. 9. The operator verifies the daily `scheduleCancel` trigger budget before the campaign. The campaign consumes at most one intentional expiry. Any missing prerequisite stops before signer activation. Funding, registration, builder approval, dead-man actions and each order/cancel require fresh, specific owner authorization; a campaign-level approval is insufficient. ## Locked envelope | Control | Required value | | ----------------------- | --------------------------------------------------------------------- | | Network | Hyperliquid testnet | | Symbol | BTC only | | Leverage | Exactly 1x | | Per-order/gross ceiling | $12 / $12 | | Venue minimum | At least the current $10 perp minimum without raising the $12 ceiling | | Concurrent exposure | One order or one position | | Slippage | At most 30 bps and within current venue bounds | | Dead-man | 30-second deadline; heartbeat no older than 15 seconds | | Testnet allocation | At most $100 mock value; never customer capital | | Stop condition | Any unknown outcome, unexpected state or failed readiness check | Before the first mutation, generate the private exact-schema checklist with `pnpm hyperliquid:evidence -- template --network testnet`. Run the read-only readiness command with expected network `testnet`, symbols `BTC`, notional `12`, leverage `1`, zero open orders and `--require-ready`. Retain only its SHA-256 and redacted fixed-code result. ## Nine-case sequence Run cases serially. Start each case from a flat account with all-DEX open orders exactly zero unless the case explicitly creates the order it later resolves. After every case, revoke the operator session, rerun read-only readiness and record one `post-case` report digest. Never retry an ambiguous signed action. | # | Verifier case ID | Separately authorized mutations | Required passing evidence | Containment / rollback | | - | ---------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 1 | `resting-gtc-cancel` | One non-marketable GTC place; one cancel by retained CLOID | Exact `open`, then exact `canceled`; open-order absence alone is insufficient | Cancel once, reconcile by CLOID, require flat/zero orders | | 2 | `ioc-fill-pnl` | One marketable IOC within $10-$12 | Exact fill quantity/price, fee token/amount, PnL and customer-account projection | If partial, close only remaining exact quantity; never resubmit original intent | | 3 | `reduce-only-close` | One exact-size reduce-only exit | Filled/canceled lifecycle; position cannot flip; account flat | Any residual size is a new separately reviewed reduce-only action | | 4 | `stop-loss-lifecycle` | One grouped parent plus losing-side protective stop | Distinct retained CLOIDs, `normalTpsl`, trigger/fill state and complete grouped reconciliation | Missing/failed protection is `attention-required`; stop new entries and reconcile/cancel safely | | 5 | `take-profit-sibling-finality` | One grouped parent plus TP and SL | Every leg terminal; filled exit plus exact sibling `siblingFilledCanceled` | No success from parent ACK, trigger-only state or bounded/missing sibling evidence | | 6 | `ambiguous-outcome-reconcile-only` | Fixture-only by default; a real testnet incident needs separate approval | Original intent is durably reconcile-only and cannot be sent again after simulated lost response | Kill switch stays active until exact state is recovered; never manufacture a retry | | 7 | `dead-man-scheduled-cancel` | One resting order; arm; one intentional heartbeat expiry | Tracked schedule, deadline passage, exact `scheduledCancel`, all-DEX zero orders and trigger count | Do not disarm before zero-order proof; stop if daily budget is uncertain | | 8 | `signer-restart-recovery` | None while stopped/flat | Supervisor recovers one generation; store lock, lifecycle and dead-man rehearsal evidence remain intact | Keep kill switch active; rollback to the verified signer artifact if health/scope changes | | 9 | `cold-backup-restore` | None | Stopped signer backup digest, isolated restore, schema 8/WAL/integrity `ok`, identical redacted store fingerprint | Never restore over the live store; preserve both original and verified backup | Cases 4 and 5 must not move a trigger merely to force execution. A market TP/SL may gap or remain unfilled; the campaign records that truth and treats any unresolved protection as failure. ## Evidence contract The private working store retains exact order identities and raw venue evidence. The exported campaign record contains only: * release commit and artifact digest; * short account/API-wallet/builder/store fingerprints; * eligibility, migration, backup, symbol-scope and readiness SHA-256 values; * the locked envelope; * one authorization row no more than five minutes before every required mutation, with action/parameter/authorization digests and fixed result codes; * all nine passed case rows and ten read-only readiness snapshots (pre-mutation, one after each case) plus final readiness; * zero incidents, or a failed campaign that is never promoted; and * final proof of a flat account, zero all-DEX orders, reconciled customer state, active kill switch, stopped signer and verified final backup. `pnpm hyperliquid:evidence -- create` must reject incomplete or sensitive input; `pnpm hyperliquid:evidence -- verify` must return `state=verified` and `decisionCode=TESTNET_VALIDATION_PASSED`. Retain its final digest independently. ## Stop and recovery policy On unknown mutation outcome, wrong network/account/symbol, stale/partial reconciliation, fee/slippage/leverage drift, store/database fault, unexpected position/order, unresolved TP/SL or unsafe workstation capacity: 1. stop new mutations and keep/restore the entry kill switch; 2. preserve the signer store and evidence without editing raw identities; 3. use read-only account/order/fill queries to reconcile the retained intent; 4. cancel only through an already authorized exact protective path; 5. require flat account and all-DEX zero orders before stopping the signer; 6. verify a cold backup and record a failed campaign rather than widening scope. ## Owner decision gate The next external step is one explicit prerequisite package: authorize a dedicated owner-controlled testnet account, registration of a fresh API wallet, user-controlled satisfaction of the faucet prerequisite, the exact retained builder/maximum fee if required, and later individual action-time approvals for the nine-case mutations. Approval of this package still does not authorize a mainnet action, customer capital, higher leverage or live execution. Related controls: * [General promotion runbook](/nytshift-docs/hyperliquid/hyperliquid-go-live-validation.md) * [Evidence template](/nytshift-docs/hyperliquid/hyperliquid-validation-evidence-template.md) * [Testnet signer isolation](/nytshift-docs/hyperliquid/hyperliquid-testnet-signer.md) * [Dead-man switch](/nytshift-docs/hyperliquid/hyperliquid-dead-man-switch.md) --- # 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-btc-one-x-testnet-campaign.md?ask=&goal= ``` `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.