> 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/normative-design/arcus.md).

# Arcus Robinhood Chain perpetual rail

Status: production public reads, account lifecycle reconciliation, connected no-send preflight and a disabled-by-default protected place/cancel boundary are implemented. Funding mutation and execution activation remain operator-owned release gates.

## Verified production surface

NIGHTSHIFT uses the official Arcus mainnet REST origin `https://api.arcus.xyz` and WebSocket origin `wss://api.arcus.xyz/v1/ws`. The adapter currently provides:

* online-market discovery with venue status, category, session, margin, mark, oracle, funding, open interest and 24-hour volume;
* paginated real candles from one minute through one day, plus live candle updates;
* live market snapshots, L2 order books, privacy-safe recent public trades and funding history;
* address validation, jurisdiction/compliance state, equity, free collateral, margin, positions and liquidation context;
* open orders, fills, order history, funding payments, deposits and withdrawals;
* explicit Robinhood Chain source/destination attribution from the venue transfer ledger.

All endpoints fail closed. Market routes accept only live-discovered `ONLINE` market IDs. The recent-trade route validates side, price, size, ID and timestamp, drops counterparty addresses, and reports provider/reason on failure. REST supplies reconnect recovery while market, candle and trade subscriptions share one byte-bounded, stale-detecting Arcus browser socket with ref-counted replay and bounded reconnect. The server pins the configured public API origin to Arcus HTTPS, uses bounded request timeouts, streams JSON through a size cap, limits concurrency, supervises a cooldown circuit, rate-limits opaque account keys, disables cache reuse for account data, discards error bodies, and never accepts a client-supplied upstream URL.

## Public account lifecycle reconciliation

Inspecting a registered Arcus address seeds a strict lifecycle from public open-order, order-history and fill REST reads, then adds address-scoped `orders` and `userFills` subscriptions to the pooled Arcus browser socket with `snapshot: true`. An order snapshot atomically replaces working and recent-closed state. Subsequent order updates must be consecutive by venue sequence number: duplicates are ignored, while a forward gap freezes order reduction, exposes `ORDER_SEQUENCE_GAP` and forces a new subscription snapshot. A periodic REST account refresh cannot clear that incident. Fill snapshots and updates are trade-ID deduplicated and monotonic, without inventing a consecutive rule for sparse fills.

The reducer and terminal distinguish ACK, open, partial, filled, canceled and rejected state because an HTTP 202 place/cancel acknowledgement is not a final outcome. Account frames must echo the exact inspected address; normalized order/fill rows omit the address and all signing material. This is public reconciliation only and has `executionCapability: none`.

## Connected no-send preflight

`POST /api/arcus/preflight` accepts only same-origin JSON and an exact public account, discovered market, side, plain market/limit type, venue TIF, decimal quantity/price and reduce-only flag. It re-reads current market constraints, two-sided L2, account, positions, portfolio risk and compliance server-side; browser state is never its policy authority.

The `arcus-rhc-v1` evaluator uses integer decimal arithmetic to select the active tick tier and require remainder-free price ticks and size quantums. It also validates status/freshness, market protective bounds, spread/slippage, ALO crossing, minimum notional, venue session/off-hours bounds, compliance, reduce-only position semantics, symbol/gross exposure, buffered session margin, live daily PnL and current-day equity drawdown. Results are private/no-store, rate-limited under an opaque account hash, and structurally fixed to `executionCapability: none`.

This is not an Arcus simulation and it is not an executable intent. The response has no API key, signature, canonical signed message, confirmation token, client ID or submit/cancel capability. Current production metadata does not publish the `maxOrderSize` referenced by the order docs, so execution uses a separate exact per-market operator attestation and fails closed when it is absent. Arcus does not expose cancel-on-disconnect; NIGHTSHIFT does not claim it.

## Protected place/cancel boundary

Authenticated operator routes expose redacted signer status, exact execution review, one-use place confirmation, live-open-order cancel review, one-use cancel confirmation and client-ID reconciliation. Every review re-reads Arcus market, book, compliance, account, positions, portfolio risk and rate-limit state from the signer-selected network. The submit route repeats those reads inside a ten-second window and rejects any changed normalization, notional, account scope, market-size attestation or rate cooldown before it consumes the confirmation.

The isolated Python service reads an operator-owned Ed25519 PEM only from a filesystem path and never returns key material. It derives the 64-hex API key, signs the official compact sorted `ordersign` place/cancel payload with nanosecond timestamps, and sends the matching master address in both the query and body. It recomputes tick and quantum integers, enforces account/index scope, GTT expiry, exact notional, mainnet canary notional and a fresh review. An application-identified SQLite schema persists place/cancel intent hashes, results, reconciliation safety, audit, and alert state. Exclusive versioned migrations preserve legacy rows and commit only after exact history/table/column plus SQLite integrity checks; future, foreign, malformed, non-WAL, or non-current stores fail closed. The BFF writes every normalized approved or rejected review verdict to that store before it can deliver an approval token. An authenticated exact-scope route reads only Arcus-prefixed events and strips signer detail before the terminal displays them. A transport failure or 5xx becomes `unknown`, is never retried, and must reconcile by `clientId`; HTTP 200/202 remains only `acknowledged` until the public `orders` and `userFills` lifecycle resolves it. See [`runbooks/arcus-execution-store-recovery.md`](/nytshift-docs/arcus/arcus-execution-store-recovery.md) and [`runbooks/arcus-execution-audit.md`](/nytshift-docs/arcus/arcus-execution-audit.md).

Every place confirmation includes literal preauthorization for one cancel-by-client-ID attempt if signer reconciliation later fails. The signer records the exact intent/account/index/market/symbol/client-ID scope in `submitting` state before calling Arcus. A missing or false policy cannot validate. Unknown or malformed lifecycle state atomically claims the only automatic cancellation before signing it, so an in-process repeat, crash or restart cannot submit it again. The signer keeps an aggregate incident latch while the cancel is pending, acknowledged, rejected or unknown, and while a later read remains `OPEN` or `PARTIALLY_FILLED`. Only exact `FILLED`, `CANCELED` or `REJECTED` state resolves the incident. The web readiness gate consumes this signer-owned aggregate state; an active incident blocks ordinary entry without blocking the kill-switch-only emergency cancel. See [`runbooks/arcus-reconciliation-incident.md`](/nytshift-docs/arcus/arcus-reconciliation-incident.md).

The local supervisor forcibly sets `ARCUS_EXECUTION_MODE=disabled` and `ARCUS_ALLOW_MAINNET=false`. Enabling even testnet requires a separate signer process, valid internal/confirmation secrets, an inactive kill switch, exact `ARCUS_EXECUTION_ACCOUNT_SCOPE`, a current Ed25519-signed venue/network/account/index eligibility decision and a non-empty market-size allowlist. The web control plane and signer verify that authority independently; environment booleans cannot create eligibility. Mainnet additionally requires the signer mainnet flag, a testnet order acknowledgement followed by account-bound terminal reconciliation, an acknowledged account-wide emergency stop followed by zero-open-order reconciliation, daily-risk-control attestation and explicit canary approval. Rehearsal proof comes only from the same durable signer audit and expires after 30 days.

The separate `signer:*` operational supervisor prepares only Arcus testnet. Its doctor validates the key and scope with zero network requests; the child binds fixed IPv4 loopback, refuses mainnet and Hyperliquid execution, disables access logs, checks authenticated health against the exact account/index and persists only a fingerprint plus process state. Hyperliquid uses the independent `hl-signer:*` supervisor and cannot share an active execution-store lease with Arcus. The real-process integration tests prove child recovery and clean shutdown with ephemeral keys. They are infrastructure for a later authorized rehearsal, not evidence that a user key is registered, eligible, funded or permitted to trade.

### Signer-owned execution alerts

The signer transactionally records secret-free alerts for unknown/rejected order operations and reconciliation incident open/resolved transitions. A bounded SQLite outbox persists stable opaque delivery IDs, attempts, leases and aggregate delivery health across restart. When both `ARCUS_ALERT_WEBHOOK_URL` and `ARCUS_ALERT_WEBHOOK_SECRET` are configured, a signer thread posts canonical JSON to the reviewed HTTPS receiver with an HMAC-SHA256 signature over the timestamp and exact body. Redirects, environment proxies and response-body retention are disabled.

Delivery is at least once: the receiver must verify timestamp/signature before parsing, durably deduplicate the delivery ID and return 2xx only after acceptance. Retry is bounded and deterministic. Exhausted pending capacity latches overflow and fails health closed; a unique recovery marker is queued before the latch clears. Health exposes only enabled/safe booleans, pending/delivered counts, overflow and a fixed error code. Ordinary execution requires healthy delivery, while emergency cancel-all remains independent. See [`runbooks/arcus-execution-alert-delivery.md`](/nytshift-docs/arcus/arcus-execution-alert-delivery.md).

### Account-wide emergency cancel

Arcus documents `POST /v1/cancelAllOrders` as an asynchronous account/index-scoped operation. NIGHTSHIFT exposes it through a separate emergency readiness state so an active entry kill switch blocks new orders without also blocking risk reduction. It requires the exact signer scope, operator session, internal/confirmation secrets, observed cancel rate and `ARCUS_EXECUTION_KILL_SWITCH=true`; it does not require market-size or new-entry eligibility attestations.

Preparation reads the complete bounded open-order scope, records its count and identity digest and issues a ten-second domain-separated one-use review. The signer sends exactly one body containing only `address`, `accountIndex` and `validUntil`, signed with Arcus legacy scheme 2 (`timestamp + cancelAllOrders + sorted compact JSON`). Review metadata stays local. A separate durable claim makes interruption or ambiguous delivery reconcile-only.

`CANCEL_ALL_ACKNOWLEDGED` is not completion. NIGHTSHIFT immediately queries the open-order scope and continues to show an incomplete stop until the authoritative count is zero. The operator keeps the kill switch active and uses reconciliation instead of resubmitting. API-wallet revocation remains an owner/master-wallet action described in the kill-switch runbook; NIGHTSHIFT does not collect that wallet authority.

## Funding truth

Arcus uses USDG as perpetual collateral. A deposit moves capital from the user's wallet into the Arcus execution domain; it is not simultaneously spendable in the source wallet. Public account transfer updates prove credit and withdrawal reconciliation, but they are not authority to initiate either operation.

Arcus now publishes an exact direct testnet flow on Robinhood Chain testnet: chain `46630`, the official testnet RPC, open-mint six-decimal test USDG, a `PaxosDepositProxy`, and `mint -> approve -> initiateDeposit(owner, accountIndex, token, amount)`. `POST /api/arcus/funding/testnet` converts that document into a server-authoritative no-send plan. Each request re-fetches or uses a five-minute cache of the exact official Markdown, rejects any reviewed-parameter drift, verifies live chain ID, deployed token/proxy code, USDG metadata, wallet ETH/USDG/allowance, exact calldata and no-state simulations. Minting covers only a balance deficit and approval is exact rather than unlimited. The terminal exposes this as a testnet-only funding planner with no wallet-signing or send capability.

`pnpm audit:arcus-funding` independently performs the bounded official-document drift check for a connected release. The addresses are intentionally not treated as timeless: Arcus warns that testnet contracts can change, so a mismatch fails closed until a new review and code change are completed.

After a user independently submits the calls in their own wallet, credit must be observed through `GET /v1/account` and `GET /v1/accountTransferUpdates` until an `APPLIED DEPOSIT` is authoritative. NIGHTSHIFT never equates a wallet transaction, HTTP response or source-wallet balance with credited Arcus collateral.

Production is different. The current onboarding documentation says the Arcus app uses Fun to quote, swap and bridge supported wallet/exchange/cash deposits into USDG, showing route, third-party fees and estimated time before user confirmation. It does not attest that every source asset or Robinhood Chain route is always available; the live provider quote remains authoritative. NIGHTSHIFT therefore keeps production deposit integration external and unconfigured rather than inventing deposit calldata.

Arcus now publishes production withdrawal-to-self separately: `POST /v1/withdraw`, chain `4663`, BridgeVault `0x14b107cf534239c59571b066cb6497a321da897c`, and the exact `Arcus Withdraw` EIP-712 domain/type. `POST /api/arcus/funding/withdrawal/prepare` is a dual-Privy-token, exact-linked-wallet, same-origin no-send review. It drift-checks the exact official submit Markdown, proves chain and deployed proxy/implementation code, re-reads the exact Arcus account and compliance evidence, verifies exact USDG quantums and free collateral, then returns a short-lived typed-data review bound to the same wallet. Preparation never asks for a signature or calls `/v1/withdraw`. A separately disabled-by-default submit route can request `eth_signTypedData_v4` from that exact user wallet only after every production gate is explicit, atomically consumes its one-use ticket before one fixed-origin request, and stores HTTP 202 as pending only. Reconciliation independently drift-checks Arcus's account-transfer document and closes only on the exact retained `withdrawalId`, wallet, account, amount and documented terminal state. No private key, signature, raw identity or arbitrary recipient is retained, and ambiguous outcomes are never retried.

## Live-capital gates

The boundary exists, but it cannot be activated for live capital until all of the following pass:

1. The user generates an Ed25519 API key and registers it with the owner EVM wallet using the documented message-signing flow.
2. Address and jurisdiction compliance pass for the exact owner account.
3. The user funds an intentionally bounded USDG account through current, officially attested production contracts.
4. The isolated signer starts with exact quantums, idempotency, timestamp/expiry checks and secret-free logs verified against the current API key.
5. A short-lived confirmation binds market, side, type, price, size, live risk evidence, account and policy version.
6. Every protected HTTP acknowledgement correlates by exact order/client identity into the public lifecycle; unknown reconciliation can use only the pre-authorized one-cancel scope, and ambiguous outcomes remain latched and non-retryable until exact terminal venue state resolves them.
7. Signer-owned execution alert delivery is configured, authenticated, restart-rehearsed, non-overflowed and healthy.
8. Execution-store schema, integrity and WAL health are current and a cold-backup/recovery rehearsal has preserved all unknown-outcome evidence.
9. Testnet/no-send checks, a user-approved capped canary, stop rehearsal and post-trade reconciliation pass.

## Official references

* <https://docs.arcus.xyz/api-reference/introduction>
* <https://docs.arcus.xyz/api-reference/authentication>
* <https://docs.arcus.xyz/concepts/exchange-architecture>
* <https://docs.arcus.xyz/guides/fund-testnet-account>
* <https://docs.arcus.xyz/concepts/onboarding>
* <https://docs.arcus.xyz/api-reference/exchange/submit-withdrawal>
* <https://docs.arcus.xyz/api-reference/exchange/place-order>
* <https://docs.arcus.xyz/api-reference/exchange/cancel-order>
* <https://docs.arcus.xyz/api-reference/exchange/cancel-all-open-orders>
* <https://docs.arcus.xyz/api-reference/public/get-order-status>
* <https://docs.arcus.xyz/api-reference/public/get-open-orders>
* <https://docs.arcus.xyz/api-reference/public/get-order-history>
* <https://docs.arcus.xyz/api-reference/public/get-current-rate-limit-usage>
* <https://docs.arcus.xyz/api-reference/onboarding/revoke-api-key>
* <https://docs.arcus.xyz/api-reference/public/get-markets>
* <https://docs.arcus.xyz/api-reference/websocket>
* <https://docs.arcus.xyz/concepts/perpetuals/order-types>


---

# 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/normative-design/arcus.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.
