> 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/implementation-ledger/ns-428-verified-customer-rhc-funding-handoff.md).

# NS-428 · Verified customer RHC funding handoff

## Outcome

Replace the signed-in customer's generic Robinhood Chain bridge placeholder with an exact-wallet, source-attributed canonical Ethereum-to-Robinhood Chain funding review and external provider handoff. NIGHTSHIFT verifies route identity, chain direction, wallet continuity and reviewed contract evidence without quoting, requesting an allowance, constructing calldata, opening a wallet request, signing or submitting a transaction.

## Official evidence reviewed

* Robinhood Chain bridging: <https://docs.robinhood.com/chain/bridging/>
* Robinhood Chain protocol contracts: <https://docs.robinhood.com/chain/protocol-contracts/>
* Robinhood Chain connection and provider guidance: <https://docs.robinhood.com/chain/connecting/>
* Review date: 2026-07-16.

The canonical Arbitrum route is the documented Ethereum-to-Robinhood Chain default. The documentation describes deposits as taking about ten minutes, not as a guaranteed arrival time. Fees, live token support, wallet connection and final confirmation belong to the provider surface. Canonical withdrawals are a separate flow with an approximately seven-day challenge period and a later Ethereum L1 claim.

## Implementation

* `CustomerRhcBridgeReadinessResponseV1` is an additive strict contract. Existing customer portfolio and access contracts remain immutable.
* `GET /api/profile/bridge-readiness?address=...` requires the server-verified Privy access token and official Privy identity token. The selected address must match an exact provider-linked EVM wallet.
* The route revalidates the reviewed six-route, 16-contract registry and projects only the canonical funding direction plus exact Delayed Inbox, L1 Gateway Router and L2 Gateway Router identities.
* The same lowercase EVM address is bound to Ethereum chain 1 and Robinhood Chain 4663. Cross-wallet responses, changed contract identities, registry drift and response-authority drift fail closed.
* The customer Funds workspace exposes the verified path, provider-owned confirmation checklist, destination-receipt completion rule and external canonical bridge handoff.
* Every failure is private, no-store and address-free. The per-session, per-wallet rate limiter uses only an opaque digest.

## Safety invariants

* `quoteCapability` and `executionCapability` are always `none`.
* No amount, token support, fee, gas estimate, allowance, calldata, signature, key, transaction hash or completion claim is invented.
* Opening the external provider is not a NIGHTSHIFT transaction. The user must independently confirm source, destination, wallet, token, fees and final action inside that surface.
* A provider acknowledgement or wallet balance change alone is not finality; the review requires destination-chain receipt evidence.
* Partner bridge families remain documentation-only and are not presented as execution-attested routes.
* Login grants no transfer, withdrawal, trading, operator or signer authority.

## Verification

```powershell
pnpm --filter @terminal/contracts exec vitest run src/customer-rhc-bridge-readiness.test.ts
pnpm --filter @terminal/web exec vitest run app/api/profile/bridge-readiness/route.test.ts app/auth/customer-rhc-bridge-readiness-panel.test.ts
pnpm --filter @terminal/contracts artifacts:check
pnpm typecheck
pnpm test
pnpm build
pnpm smoke:web
pnpm handoff:check
```

## Remaining external gates

* The official domain still needs a real production Privy project, allowed origins and verified identity-token flow before customer login can run there.
* A managed live quote/transaction integration, legal review and explicit user-authorized wallet flow would be a separate capital-moving milestone.
* A production managed Robinhood Chain HTTP/WSS/archive topology is still required for authoritative portfolio and post-bridge reconciliation evidence.


---

# 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/implementation-ledger/ns-428-verified-customer-rhc-funding-handoff.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.