Private payments and positions on Robinhood Chain.

Public ledgers expose more than settlement. Amounts, balances, counterparties, timing, recurring payment patterns, and portfolio changes can all become durable public records. That is especially sensitive when the assets represent dollars, payroll, treasury activity, or tokenized equity positions.

Orivan is intended to add a private path at the settlement layer without taking custody. A user deposits an asset into the protocol, represents value as a shielded note, and later claims it to a fresh address. The protocol is designed so the user controls the secrets required to move a note; Orivan does not hold user funds or keys.

This document describes a target architecture, not a production system. The repository contains early cryptographic building blocks, while the complete proving, nullifier, relayer, and deployment path remains under active development.

Deposit. The client samples a secret and derives a Poseidon commitment from Poseidon(amount, secret). The commitment can be stored without publishing the note secret. The secret stays with the user and is required to prove control of the note.

Shield. A zero-knowledge proof is intended to demonstrate that an input note is valid and unspent without revealing the note itself. The transition publishes a nullifier to prevent double-spends and a new commitment for the resulting shielded state.

Claim. The recipient is intended to receive value at a one-time ERC-5564 address. A gasless relayer submits the final transaction so the recipient does not need a funded public address merely to claim. The exact circuit and relayer interfaces are not final.

Building on the asset settlement chain avoids a separate off-chain balance sheet and the trust assumptions that come with it. The target is for users to retain ownership while moving between public assets and shielded notes through verifiable contracts.

Robinhood Chain uses chain id 4663. Orivan is being specified around that environment and its tokenized-asset use cases, but chain selection alone does not make the protocol ready. No Orivan contracts are deployed yet. Contract addresses should be treated as valid only after they appear in the repository's deployment documentation following the required ceremony and audit process.

In the intended product, the sender chooses an asset and amount, creates a commitment locally, and transfers the resulting note through the shielded state machine. The recipient receives the information needed to detect and claim the note without reusing their everyday wallet address.

The target-hidden fields are the amount, sender, and recipient inside the shielded transfer. Entry and exit transactions still create observable metadata, so timing, deposit size, withdrawal size, and a small anonymity set may allow correlation. Privacy depends on the completed circuits, the size and behavior of the pool, and disciplined claim routing.

The current SDK transfer path is deliberately gated and throws until proving is ready. That fail-closed behavior prevents an unfinished privacy path from being presented as a working transfer.

The architecture should keep the source note private while exposing only the information an execution venue strictly requires. A proof would authorize the transition from a valid unspent input note, while settlement would produce a new commitment representing the resulting asset or position.

A venue may still learn execution-side data, and market activity can be correlated by time and size. Orivan's design goal is data minimization, not the impossible promise that external venues observe nothing. Router selection, quote integrity, slippage protection, partial fills, failed executions, and refund behavior remain open product and protocol work.

The intended batch flow creates a separate note for every recipient. Each recipient detects and claims their note through a fresh address, limiting direct address reuse and avoiding a single public recipient list inside Orivan's shielded logic.

Batch construction, scheduling, recurring runs, approvals, recovery, accounting exports, and claim monitoring remain on the roadmap. Until those controls and the proving system are complete, Orivan must not be treated as payroll infrastructure.

A useful private wallet still needs to show pending deposits, unspent notes, completed claims, and failed routes. Orivan's target is to derive this view from client-held note material and chain data. Users should be able to export their own records for accounting without sending the complete history to Orivan.

Local state creates practical responsibilities: backups, device migration, duplicate detection, and secure recovery must be designed carefully. Hosted support, notifications, or analytics must not become a second payment graph. Any optional service should minimize, separate, and clearly disclose the metadata it receives.

The relayer must be paid for gas and service without requiring the recipient to fund the one-time claim address. In the planned circuit, the fee is accounted for alongside input and output values so a proof can enforce the correct transition without publishing a production payment schedule.

There is no production fee schedule before deployment. Fees, limits, supported gas assets, quote expiry, and refund behavior will be specified only after benchmarks, relayer implementation, testnet operation, and security review. Any number shown outside official deployment documentation should be treated as non-canonical.

Security guarantees depend on complete and correct circuits, safe contracts, a correctly performed setup, reliable client secret handling, and independent audits. None of those should be inferred from an early commitment implementation.

A relayer may see network-level metadata and may censor or delay a request, but the target protocol does not give it the note secret or a direct recipient identity. Permissionless relayers are planned so users are not dependent on a single operator. Private submission, transport protections, and fallback routing still require testing.

Do not use real funds. The specification and current code are unaudited and not for production use. Test only with disposable development wallets and valueless test assets.

The canonical website is orivan.xyz. The application entry point is app.orivan.xyz, and public updates are posted at x.com/orivanzk.

Orivan does not publish a deployment address today. Any future deployment information will appear on the canonical website only after the trusted setup ceremony and independent audit. Social posts and direct messages are never sufficient address verification.

Privacy is an end-to-end property. RPC providers, hosting infrastructure, wallet software, browsers, and other vendors operate under their own policies and may receive IP addresses, request timing, wallet connection data, or chain metadata. Users should review those policies and choose their infrastructure accordingly.

The existing experimental application may expose wallet and chain metadata to connected wallets, RPC endpoints, hosting providers, and other integration services. It must not be described as zero-telemetry until the complete client, dependency set, network behavior, logging, and hosting path have been audited.

The protocol target is that keys, note secrets, local history, and recovery material never need to reach Orivan servers. Optional diagnostics or support tooling must be disclosed, minimized, and separated from note data before any production release.

Orivan does not take custody, provide investment, legal, or tax advice, or guarantee availability, privacy, execution, asset value, or fitness for a particular purpose. Cryptographic software, smart contracts, relayers, wallets, infrastructure providers, and tokenized assets each carry independent risks.

Do not use real funds. Users are responsible for their jurisdiction, wallet security, backups, transaction decisions, counterparties, tax obligations, and privacy hygiene. Stealth addresses and zero-knowledge proofs cannot undo identity disclosure, compromised endpoints, unsafe device practices, or uniquely identifying transaction behavior.

Final production terms, supported jurisdictions, asset disclosures, and protocol risk documentation will be published before any production launch. Until then, this document is a technical description of intended behavior rather than a promise of service.