> 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/arcus/arcus-customer-withdrawals.md). # Customer withdrawals This runbook covers the user-owned Arcus withdraw-to-self lifecycle. It does not authorize activation. Keep the scope disabled until the operator has separately approved customer identity, production Robinhood Chain data, legal/eligibility controls, test evidence and a capped production rehearsal. ## Normal disabled state The repository, local supervisor and public release builder use: ``` NIGHTSHIFT_ARCUS_WITHDRAWAL_MODE=disabled NIGHTSHIFT_ARCUS_WITHDRAWAL_ALLOW_MAINNET=false NIGHTSHIFT_ARCUS_WITHDRAWAL_CONFIRMATION_SECRET= ``` `/api/health` must report `arcusCustomerWithdrawalState=disabled`, `arcusCustomerWithdrawalMode=disabled`, `arcusCustomerWithdrawalAllowMainnet=false` and `arcusCustomerWithdrawalStoreState=ready`. Preparation remains available as a no-send review when customer identity and live preflight evidence are available; no confirmation token or signature control is issued. ## Activation prerequisites Do not enable the scope until all of the following are independently proven on the exact public release: 1. Privy browser/server configuration and a fresh verified production rehearsal for Google, wallet, embedded/link/logout/session-expiry and chain-4663 flows. 2. Two authenticated production Robinhood Chain HTTP/WSS providers and archive evidence with healthy divergence monitoring. 3. Current `pnpm audit:arcus-withdrawal` evidence, exact BridgeVault proxy/implementation code, live Arcus account/compliance/collateral reads and reviewed jurisdiction/eligibility controls. 4. A private absolute lifecycle store on backed-up operator storage and a successful create/verify/restore rehearsal while the supervisor is stopped. 5. A 32–4096 byte random confirmation secret installed only in the private service environment. Never place it in source, `.env.example`, local `config.json`, a prompt or browser storage. 6. Desktop and 390px production rehearsals covering wrong wallet, wrong chain, rejected signature, expired ticket, preflight drift, submit-document drift, account-transfer-document drift, known HTTP rejection, ambiguous response, pending acknowledgement, exact applied terminal event and explicit rejected terminal event. 7. Explicit owner/security/legal approval for the narrow withdraw-to-self capability. Only after those checks may the private service environment set both mode and mainnet approval. Restart the exact immutable release and read back health before allowing a customer to prepare a ticket. Login alone must remain insufficient. ## Customer flow 1. Select the provider-verified wallet and Arcus account in Funds. 2. Prepare the amount. Confirm the recipient is the same exact wallet and inspect account, collateral, compliance, document, chain and vault evidence. 3. If the separately gated submission state is ready, connect that same wallet, switch it to Robinhood Chain `4663` and type the exact phrase. 4. Inspect the wallet's EIP-712 domain/message. Reject the request if the address, account index, amount, nonce, chain or verifying contract differs. 5. Sign once. HTTP 202 means pending only. Retain the NIGHTSHIFT attempt ID and Arcus withdrawal ID. 6. Reconcile until the exact ID reaches a documented terminal transfer state. Every reconciliation first validates the current official account-transfer schema; drift produces attention-required and no venue read. Never use a balance change, list absence, elapsed time or a second ticket as finality. ## Ambiguous or stuck outcome * `attention-required` or a transport/response failure after signing means the venue may have received the request. Do not retry and do not create a replacement ticket. * Preserve the lifecycle store and IDs. Use **RECONCILE EXACT ID** after provider recovery. * If the exact ID is absent, leave it pending for the first 15 minutes and then attention-required; absence is not rejection. * Duplicate, mismatched or malformed terminal evidence is an incident. Disable the scope, preserve the checkpoint and escalate to Arcus with the user-held/retained identifiers. Do not edit the store. * A documented terminal rejection is final for that attempt. Diagnose collateral, amount, compliance or account state before a completely new review. ## Disable and recovery 1. Set mode to `disabled` and mainnet approval to `false`, restart and verify the disabled health state. Removing the confirmation secret provides an additional lock. 2. Do not delete pending/attention records. Disabled mode must still preserve their backup and later operator reconciliation evidence. 3. Create and verify a NIGHTSHIFT checkpoint before maintenance. Restore only with the supervisor stopped; verify the restored backup and restart. 4. If the store is corrupt, health is unsafe. Stop the runtime, preserve the corrupt file, restore the latest verified checkpoint and re-read every retained non-terminal ID before considering reactivation. 5. Rotate the confirmation secret after suspected compromise. Existing tickets become invalid; already submitted attempts remain reconcilable from the durable store. --- # 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/arcus/arcus-customer-withdrawals.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.