> 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-validation-evidence-template.md).

# Validation evidence template

Use one copy per testnet or mainnet campaign. This record is evidence, not an execution instruction. Never include an account address, API-wallet address or key, signature, CLOID, cookie, token, database URL, raw request/response body or provider credential.

Exact identities and raw venue evidence remain in the protected signer/customer stores. Export only fixed outcome codes, irreversible hashes or short redacted fingerprints.

## Campaign identity

| Field                                 | Value                 |
| ------------------------------------- | --------------------- |
| Campaign ID                           |                       |
| Network                               | `testnet` / `mainnet` |
| Release commit                        |                       |
| Release artifact digest               |                       |
| Operator/reviewer                     |                       |
| Start/end UTC                         |                       |
| Account fingerprint                   |                       |
| API-wallet fingerprint                |                       |
| Builder fingerprint and approved fee  |                       |
| Eligibility policy version/digest     |                       |
| Customer DB migration set             |                       |
| Signer store schema/integrity/journal |                       |
| Pre-campaign backup verification      |                       |

## Locked envelope

| Control                               | Approved value |
| ------------------------------------- | -------------- |
| Funded allocation ceiling             |                |
| Exact symbol count                    |                |
| Symbol-scope digest                   |                |
| Per-order notional ceiling            |                |
| Gross-exposure ceiling                |                |
| Leverage ceiling                      |                |
| Maximum concurrent orders/positions   |                |
| Slippage ceiling                      |                |
| Fee ceiling                           |                |
| Campaign realized-loss stop           |                |
| Dead-man deadline/heartbeat freshness |                |
| Campaign expiry UTC                   |                |

Record a scope digest rather than the raw symbol list in exported evidence. The operator must compare the exact symbols locally with the readiness command.

## Read-only readiness

| Check                         | Before first mutation | After every case | Final |
| ----------------------------- | --------------------- | ---------------- | ----- |
| Report timestamp and SHA-256  |                       |                  |       |
| State/network                 |                       |                  |       |
| DB and account-digest ready   |                       |                  |       |
| Execution gates all true      |                       |                  |       |
| Expected network matched      |                       |                  |       |
| Exact symbol scope matched    |                       |                  |       |
| Canary cap matched            |                       |                  |       |
| Leverage cap matched          |                       |                  |       |
| Zero-open-order expectation   |                       |                  |       |
| Dead-man rehearsal proven     |                       |                  |       |
| Operator session revoked      |                       |                  |       |
| Read-only/no capital mutation |                       |                  |       |

## Mutation authorization log

Create one row immediately before each external mutation. A campaign-level approval does not satisfy this table.

| UTC | Action | Network | Redacted intent fingerprint | Reviewed parameters digest | Expected result code | User authorization reference | Actual result code | Reconciled UTC |
| --- | ------ | ------- | --------------------------- | -------------------------- | -------------------- | ---------------------------- | ------------------ | -------------- |
|     |        |         |                             |                            |                      |                              |                    |                |

Actions include API-wallet registration/revocation, builder approval, funding/faucet claim, leverage change, order placement/modification/cancellation and every dead-man arm/heartbeat/disarm/intentional expiry.

## Testnet matrix

| Case                                     | Result | Evidence digest/timestamp | Reviewer |
| ---------------------------------------- | ------ | ------------------------- | -------- |
| Resting GTC open + exact cancel finality |        |                           |          |
| IOC fill, fee and PnL projection         |        |                           |          |
| Reduce-only close without flip           |        |                           |          |
| Stop-loss grouped lifecycle              |        |                           |          |
| Take-profit/stop-loss sibling finality   |        |                           |          |
| Ambiguous outcome becomes reconcile-only |        |                           |          |
| Dead-man exact `scheduledCancel` proof   |        |                           |          |
| Signer restart recovery                  |        |                           |          |
| Cold store backup/isolated restore       |        |                           |          |

## Mainnet canary

| Check                                                | Result/evidence |
| ---------------------------------------------------- | --------------- |
| Testnet matrix reviewed and accepted                 |                 |
| Funding receipt verified read-only                   |                 |
| Strict mainnet readiness report green                |                 |
| Entry separately authorized and reconciled           |                 |
| Fill quantity/price/fee/PnL projected to customer DB |                 |
| Exit separately authorized and reduce-only           |                 |
| Cumulative realized loss below campaign stop         |                 |
| Account flat and all-DEX open orders exactly zero    |                 |
| Kill switch restored                                 |                 |
| Dead-man safely disarmed after zero-order proof      |                 |
| Signer stopped and final backup verified             |                 |

## Incident and stop record

| UTC | Fixed incident code | New mutations stopped | Kill switch state | Reconciliation result | Evidence digest | Reviewer |
| --- | ------------------- | --------------------- | ----------------- | --------------------- | --------------- | -------- |
|     |                     |                       |                   |                       |                 |          |

Any unknown outcome, stale/partial reconciliation, database or signer-store fault, scope change, unexpected fee/PnL/funding/leverage/position, unresolved protective leg, or unsafe workstation condition fails the campaign.

## Structured final evidence

Keep the working checklist and final evidence as private regular files outside the repository. Generate the exact-schema draft first; it is intentionally invalid until every placeholder is replaced with observed, redacted evidence:

```powershell
pnpm hyperliquid:evidence -- template --network testnet --output C:\secure\nightshift\campaign-checklist.json
pnpm hyperliquid:evidence -- create --input C:\secure\nightshift\campaign-checklist.json --output C:\secure\nightshift\campaign-evidence.json
pnpm hyperliquid:evidence -- verify --evidence C:\secure\nightshift\campaign-evidence.json
```

Use `--network mainnet` for the separately authorized canary record. The verifier is offline and performs no network or venue request. It requires:

* all nine testnet cases or the complete mainnet canary closure;
* fresh authorization no more than five minutes before every required external mutation;
* pre-mutation, post-case and final read-only readiness proof;
* one redacted symbol scope, 1x leverage and no more than $12 per-order/gross exposure;
* reconciled customer-database projections, flat account, exactly zero open orders, restored kill switch, stopped signer and verified final backup.

The evidence digest binds the exact canonical record and detects an accidental or unapproved change only when the digest is retained independently in the approval/change record. It is not a digital signature and must not be treated as protection against an attacker who can replace both the file and digest. Never commit a completed campaign evidence file.

## Final decision

* [ ] Campaign passed every required case.
* [ ] No unresolved position, order, mutation or incident remains.
* [ ] All exported evidence is redacted.
* [ ] Testnet-only promotion approved, or mainnet canary closed without widening limits.
* [ ] Any next increase in capital, symbols, leverage or automation will receive a separate review.

Decision code:

Reviewer:

UTC:


---

# 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-validation-evidence-template.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.