> 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/policy-control-and-incident-response/execution-eligibility.md). # Signed execution eligibility ## Boundary NIGHTSHIFT does not determine whether a person may legally trade. A designated human compliance operator must review the current user, account, jurisdiction, sanctions constraints and venue terms through an external process. That process may issue one short-lived `nse_v1` Ed25519 attestation only after all four checks are complete. The attestation contains no name, country, region, date of birth or other personal/location data. It contains only an opaque attestation ID, policy digest, validity window and exact venue/network/account scopes. Robinhood Chain's current terms require an adult user who is not prohibited by law or sanctions and prohibit masking location or identity with a VPN or proxy: . Hyperliquid publishes legal-compliance and restricted-jurisdiction criteria in its Foundation-operated node material and notes that criteria may change: . Those pages are evidence inputs, not a hard-coded trading-jurisdiction list or legal advice. The operator must also review the venue's current trading terms and Arcus's current compliance result before issuing. ## Create the authority key once Create the issuer key on a dedicated issuer machine, outside this repository and outside the production host: ```powershell $env:NIGHTSHIFT_ELIGIBILITY_PRIVATE_KEY_PATH = "$env:USERPROFILE\.nightshift-eligibility-authority\private.pem" $env:NIGHTSHIFT_ELIGIBILITY_PUBLIC_KEY_PATH = "$env:USERPROFILE\.nightshift-eligibility-authority\public.pem" pnpm eligibility:keygen ``` The command refuses relative paths, symlinks, wrong key types, identical paths and overwrite. Back up the private key through a separate protected secret workflow. Never copy the private key, its path variable or its backup to the web/signer host. ## Record the reviewed policy and issue Create a controlled policy record outside the repository. It should identify the exact current sources, review time, reviewer, decision procedure and incident/rotation owner. Keep any personal review evidence in that controlled system; do not place it in the attestation payload. After completing the four checks, issue a narrowly scoped attestation. Scope format is `venue:network:lowercase-account` for Hyperliquid and `venue:network:lowercase-account:account-index` for Arcus. Multiple scopes are comma-separated. ```powershell $policy = "$env:USERPROFILE\.nightshift-eligibility-authority\policies\2026-07-review.md" $output = "$env:USERPROFILE\.nightshift-eligibility-authority\issued\account-testnet.nse" pnpm eligibility:issue -- --scopes "hyperliquid:testnet:0x1111111111111111111111111111111111111111,arcus:testnet:0x1111111111111111111111111111111111111111:0" --policy-file $policy --policy-version "rhc-and-venue-terms-2026.07" --days 7 --output $output --ack "adult,jurisdiction,sanctions,venue-terms" ``` Validity is capped at 30 days and defaults to seven. Output is a protected, create-once token file; the command prints only its path, redacted authority fingerprint, policy digest and non-personal payload. Renew with a new attestation ID after a fresh review. Never extend or edit a signed payload. ## Verify and configure the runtime Verify on the issuer machine before delivery: ```powershell $env:NIGHTSHIFT_ELIGIBILITY_ATTESTATION = (Get-Content -Raw $output).Trim() pnpm eligibility:verify ``` Deliver only the one-line attestation and public key through the protected deployment channel. Configure both the web control plane and signer process with the same values: ``` NIGHTSHIFT_ELIGIBILITY_ATTESTATION=nse_v1... NIGHTSHIFT_ELIGIBILITY_PUBLIC_KEY_PATH=/etc/nytshift/eligibility-public.pem NIGHTSHIFT_ELIGIBILITY_PUBLIC_KEY= EXECUTION_ACCOUNT_SCOPE=0x... ARCUS_EXECUTION_ACCOUNT_SCOPE=0x... ``` `NIGHTSHIFT_ELIGIBILITY_PUBLIC_KEY` accepts inline PEM only for ephemeral local/test launch environments. Supervised production should use the absolute public-key path and must not configure both key sources. The account-scope variables are independent expected-signer scopes; they cannot create eligibility. After restart, unlock the operator session and inspect **Safety settings -> Signed eligibility authority**. It must show `ACTIVE`, the reviewed policy version, expiry and the same public-key fingerprint for both venue paths. The web control plane also compares its redacted projection with the signer's projection; a different token, key, policy digest, validity window or scope fails closed. ## Expiry and incident handling * Missing, partial, malformed, forged, not-yet-valid, expired, wrong-network, wrong-account or wrong-index evidence blocks every new order and leverage mutation before signer idempotency claim or venue I/O. * Expiry does not disable cancel-by-ID, Arcus cancel-all, reconciliation, Hyperliquid dead-man arm/heartbeat/disarm or post-deadline reconciliation. Protective authority remains exact-account, authenticated and independently gated. * If the issuer private key leaks, stop new entry, rotate the key pair, replace the production public key and issue new attestations after fresh review. * If the attestation leaks, remove it, keep entry locked and issue a new attestation ID. The token contains account scopes and should be treated as sensitive deployment authorization even though it cannot sign a venue request. * A current signed attestation does not replace live Arcus compliance, operator authentication, AEGIS review, account/market state, risk limits, builder approval, execution-store integrity, alerting, rehearsal, dead-man, canary or mainnet gates. --- # 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/policy-control-and-incident-response/execution-eligibility.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.