> 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-go-live-validation.md). # Go-live validation This is the promotion runbook from proven NIGHTSHIFT PAPER behavior to a tightly controlled Hyperliquid testnet rehearsal and, only afterward, a separately authorized mainnet canary. It does not authorize a wallet registration, deposit, withdrawal, order, cancellation or dead-man-switch mutation. ## Authority boundary Every external mutation needs action-time authorization for the exact action. Configuration, a green readiness report, previously loaded funds, a general request to test, or an earlier approval is not authorization for a later venue mutation. | Action | Separate authorization required | | --------------------------------------------------------------- | ------------------------------- | | Register/revoke an API wallet | Yes | | Approve a builder fee | Yes | | Move funds or claim testnet funds | Yes | | Arm, heartbeat, disarm or deliberately trigger `scheduleCancel` | Yes | | Place, modify or cancel an order | Yes | | Change leverage | Yes | | Reconcile by exact retained order identity | No; read-only venue operation | | Run `pnpm hyperliquid:readiness` | No; read-only loopback audit | Never paste the owner key, API-wallet key, operator secret, internal token, eligibility token, identity token, cookie or database URL into a prompt, command argument, repository file, browser storage, log or evidence document. ## Phase 0: production dependencies Do not enable testnet execution until all items are true: 1. The exact intended release commit is reviewed and backed up. 2. A private PostgreSQL service has encrypted backups and point-in-time recovery. `pnpm db:migrate` and `pnpm db:verify` pass; a protected minimum-32-byte `CUSTOMER_ACCOUNT_DIGEST_KEY` is backed up; and `/api/health` reports `customerDatabaseState=ready` plus `customerAccountDigestState=configured`. 3. Privy production identity and its exact-app rehearsal are configured if customer persistence is in scope. 4. A dedicated Hyperliquid API wallet is registered by the owner on testnet. It is not the owner/master key, is used by one signer process and is stored only in a protected regular file outside the repository. * Never reuse an API-wallet address after deregistration. Use a newly generated address for a replacement process. * Account and order queries use the master/subaccount address, not the API-wallet signing address. 5. The owner separately approves the exact reviewed builder and maximum fee. The builder satisfies NIGHTSHIFT's Standard-account and balance checks. 6. A current signed eligibility decision binds the exact testnet account, venue and policy. 7. The signer store is backed up and reports schema 8, integrity `ok` and WAL. 8. `ALLOW_MAINNET=false`, Arcus execution is disabled and the mainnet configuration is absent. ### Current pre-funded campaign checkpoint — 2026-07-26 * An owner-controlled dedicated MetaMask wallet has been connected to Hyperliquid testnet. Its seed phrase and private key remain outside NIGHTSHIFT, Codex, the browser application and repository. * Faucet eligibility is not yet satisfied because Hyperliquid requires a prior mainnet deposit from the same owner address. * When the owner is ready, the funding plan is at least 6 USDC on Arbitrum plus enough ETH for gas, followed by a separately reviewed mainnet deposit and a separately authorized claim of the 1,000 mock-USDC testnet allocation. * Funding or a successful faucet claim does not authorize API-wallet registration, signer activation, an order, a cancellation, a leverage change, a dead-man mutation or any later mainnet action. * Until that checkpoint is complete, finish only no-send readiness, identity, database-recovery, provider, alerting and runbook evidence. Keep the signer service stopped and execution disabled. ## Phase 1: no-send readiness audit Start only the dedicated Hyperliquid signer and the separately configured web control plane. Keep the entry kill switch active during configuration. Run the offline doctor first, then inspect authenticated signer health. After reviewing every value, release the testnet kill switch and run: ```powershell $env:NIGHTSHIFT_OPERATOR_SECRET = "" pnpm hyperliquid:readiness -- --origin http://127.0.0.1:3000 --expected-network testnet --expected-symbols BTC --max-canary-notional-usd 12 --max-leverage 1 --require-zero-open-orders --require-ready Remove-Item Env:NIGHTSHIFT_OPERATOR_SECRET ``` The command creates a temporary loopback operator session, reads `/api/health` and `/api/execution/status`, compares the configured campaign scope without printing the symbols, revokes the session and emits only a redacted report. It never calls an order, cancel, leverage, funding or dead-man mutation route. Required evidence: * `state: "ready"` and `network: "testnet"`; * the expected network, exact symbol set, signer/BFF policy digest, maximum 1x leverage, maximum canary notional and zero-open-order expectations all match; * customer database ready; * signer reachable and scope-matched; * current eligibility and matching authority; * confirmation/internal secrets present without printing them; * builder fee configured and signer-matched; * portfolio reconciliation ready with complete current account/position/order/fill/funding coverage; * `capitalMutationAttempted: false`; * temporary operator session revoked. Any contradiction, partial DEX coverage, unknown order, stale capital snapshot, database failure or failed session revocation stops the rehearsal. ## Phase 2: authorized testnet matrix Use a deliberately funded testnet account and the minimum venue-valid size. Hyperliquid currently rejects perp orders below $10 notional. A testnet faucet claim is itself a mutation and currently requires a prior mainnet deposit from the same address. Before each numbered mutation, state the exact network, symbol, side, size, price/trigger, maximum notional and expected outcome, then obtain fresh action-time authorization. 1. **Resting order and cancellation** * Submit one non-marketable GTC limit with a unique CLOID. * Reconcile until exact `open` state appears. * Prepare and authorize one cancel by that CLOID. * Reconcile until exact venue `canceled`; absence from the open-order list alone is insufficient. 2. **IOC fill and position/PnL** * Submit one tiny marketable IOC inside the reviewed slippage, spread, fee, market-notional, portfolio and canary ceilings. * Reconcile the exact CLOID. Record fill quantity, price, fee token/amount and closed PnL without copying raw venue responses. * Verify the authoritative portfolio generation reflects the position and account change. 3. **Reduce-only exit** * Submit a side/size-exact reduce-only close. * Prove the position cannot flip and reconcile terminal fill/cancel evidence. 4. **Atomic stop-loss bracket** * Open one tiny parent with an exact losing-side protective stop appropriate to the position. * Confirm the parent and stop child use distinct retained CLOIDs and `normalTpsl`. * Wait for an actual venue trigger or close/cancel through separately reviewed actions. Never move a trigger merely to make it execute immediately. * Accept terminal protection only from grouped parent/child reconciliation. * Hyperliquid triggers TP/SL from mark price. Its market TP/SL form currently permits 10% slippage, so NIGHTSHIFT's reviewed limit-trigger child and explicit slippage ceiling must remain authoritative. 5. **Atomic take-profit bracket** * Repeat with both TP and SL children. * A completed exit is accepted only when every leg is terminal and the sibling has exact `siblingFilledCanceled` evidence. Any bounded/missing/conflicting leg is `attention-required`. 6. **Ambiguous-outcome recovery** * Rehearse a controlled lost response only with a test fixture or an explicitly approved testnet incident. * Verify the original intent/CLOID becomes reconcile-only and cannot be submitted again. 7. **Venue dead-man rehearsal** * Confirm the UTC daily trigger budget. Hyperliquid currently permits at most 10 `scheduleCancel` triggers per day, resetting at 00:00 UTC. * Place one tiny reviewed resting testnet order, arm the 30-second schedule and verify it is tracked. * With separate authorization, intentionally stop authenticated heartbeats once. * After the acknowledged deadline, reconcile zero all-DEX open orders plus exact retained `scheduledCancel` status. * Record the same-account 30-day rehearsal evidence and trigger consumption. 8. **Restart and storage recovery** * With no mutation pending, restart the signer child and prove the supervisor recovers one generation without losing lifecycle or dead-man evidence. * Stop the signer, create/verify a cold signer-store backup and restore only into an isolated rehearsal path. After every case, rerun the read-only readiness audit. Stop immediately for an unknown mutation, stale reconciliation, unsafe database/store state, unexpected open order, wrong account/network, fee/slippage mismatch or unresolved position. ## Required testnet evidence The promotion record contains only fixed outcome codes, redacted fingerprints, exact release commit, database migration set, signer-store schema/integrity/WAL state, test timestamps, bounded coverage labels and reviewer approvals. It must prove: * GTC open and exact cancel finality; * IOC fill and exact fee/PnL evidence; * reduce-only close without flip; * stop-loss and take-profit grouped lifecycle; * no-retry ambiguous-outcome behavior; * one successful dead-man deadline cancellation; * exact all-DEX zero-open-order reconciliation; * signer restart and backup recovery; * no secret, raw account, signature, cookie or provider payload retained. Repository tests and PAPER results do not substitute for this venue evidence. Use [the redacted evidence template](/nytshift-docs/hyperliquid/hyperliquid-validation-evidence-template.md) for the campaign record. Generate its exact structured draft with `pnpm hyperliquid:evidence -- template`, then accept promotion only when `pnpm hyperliquid:evidence -- verify` returns `state=verified`. The verifier is offline, grants no authority and makes no venue request. Exact CLOIDs, account addresses, signatures and raw venue payloads remain only in the protected operational stores; retain the final evidence digest separately in the approval/change record. ## Phase 3: mainnet canary Mainnet remains disabled until the full testnet matrix is reviewed. Loading funds does not release execution authority. The first proposed validation envelope is deliberately narrow: | Control | Initial ceiling | | ------------------------------------- | ---------------------------------------------------------- | | Separately funded allocation | $50 maximum | | Market | BTC perpetual only | | Per-order notional | $12 maximum | | Leverage | 1x | | Concurrent exposure | One order or one position | | Campaign realized-loss stop | $2 cumulative | | Dead-man deadline | 30 seconds | | Heartbeat freshness before a mutation | 15 seconds maximum | | Transfers/withdrawals | None except a separately authorized initial funding action | These are ceilings, not instructions or authorization. If the venue minimum, fees, precision, liquidity or current risk state cannot fit inside them, stop rather than enlarge the envelope. 1. The user chooses and separately authorizes the transfer amount, up to the $50 campaign ceiling. Verify receipt through the venue; NIGHTSHIFT does not infer funding finality from an acknowledgement. 2. Issue a fresh mainnet eligibility decision for the exact account. 3. Configure `MAINNET_CANARY_MAX_NOTIONAL_USD=12`, exact `EXECUTION_SYMBOL_ALLOWLIST=BTC`, `NIGHTSHIFT_HL_SYMBOL_ALLOWLIST=BTC`, `NIGHTSHIFT_HL_MAINNET_MAX_LEVERAGE=1` and reviewed fee/slippage/notional limits. Do not broaden the repository defaults merely to make an order pass. 4. Stop the testnet signer, verify a cold signer-store backup and follow [`hyperliquid-mainnet-signer.md`](/nytshift-docs/hyperliquid/hyperliquid-mainnet-signer.md). The managed supervisor must prove an offline mainnet doctor, fixed loopback bind, explicit $12-or-lower cap, strict mainnet health and the same account-bound rehearsal store. Enable mainnet independently in the web service only for the approved canary window. 5. Arm the venue dead-man switch and prove more than five seconds remain with a heartbeat no older than 15 seconds. 6. Run the strict read-only audit and retain its redacted report: ```powershell pnpm hyperliquid:readiness -- --origin http://127.0.0.1:3000 --expected-network mainnet --expected-symbols BTC --max-canary-notional-usd 12 --max-leverage 1 --require-zero-open-orders --require-dead-man-rehearsal --require-ready ``` 7. Present one exact canary order for fresh user authorization. The first mainnet action should be one minimum-valid, low-notional, liquid-market order—not the full loaded balance. 8. Reconcile the exact order, fill, fees, position and customer database projection. 9. Close the exact position reduce-only under a separate authorization, reconcile flat account state and prove zero open orders. 10. Stop the campaign immediately at $2 cumulative realized loss or any incident condition, even if the $50 allocation remains. 11. Re-enable the kill switch, safely disarm only after zero-open-order proof, stop the signer and review the evidence before any broader limit. Do not expand symbols, notional, leverage, automation or capital from one successful canary. Each expansion is a separate reviewed change. ## Incident stop conditions Keep or restore the kill switch and stop new entries when any of these occurs: * a signed call has an unknown outcome; * a database, signer store, reconciliation rail or operator alert is unavailable; * an order disappears without exact status; * TP/SL siblings conflict or any protective leg is missing; * dead-man state is uncertain/expired with unresolved open orders; * the account, API wallet, builder, network, eligibility or release fingerprint changes; * an unexpected fee, PnL, funding, leverage or position appears; * the machine falls below safe RAM/disk thresholds or storage warnings recur. Preserve evidence, reconcile by exact retained identity and never retry the capital-moving action. ## Official Hyperliquid references * API and testnet endpoints: * API wallets and nonce ownership: * Order, cancel and `scheduleCancel`: * Order types and reduce-only/TIF behavior: * TP/SL trigger semantics: * Error responses and the current minimum perp order value: * Testnet faucet prerequisites: * Builder-code approvals and fee ceilings: --- # 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-go-live-validation.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.