> For the complete documentation index, see [llms.txt](https://docs.hoodprivate.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hoodprivate.com/protocol-and-architecture/trust-and-security.md). # Trust & Security Model HoodPrivate is engineered so that custody, transaction validity, and confidentiality never depend on trusting HoodPrivate as a company. Security is layered, each layer answers a distinct threat, and the guarantees hold even when the company itself is the adversary in the threat model. *** ## Security layers | Layer | Threat addressed | Mechanism | | ------------------ | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Custody | HoodPrivate is compromised or coerced into moving user funds | Non-custodial keys, generated and held on-device. HoodPrivate never holds private keys. | | Confidentiality | HoodPrivate or a third party reads transaction amounts | ZK proof generation and decryption happen client-side. HoodPrivate's backend only ever sees ciphertext. | | Transfer validity | A malformed or overdrawing transfer is submitted | HoodPrivate's on-chain verifier contract checks the zero-knowledge range and validity proofs before encrypted balances are updated, and because Robinhood Chain settles to Ethereum through the Arbitrum stack's fraud proofs, that verification is ultimately secured by Ethereum. | | Agent overspend | An agent transacts beyond its authorized limit | Spend policies live on-chain in the agent account's ERC-4337 validation contract; a policy-violating transaction fails validation. Client-side policy checks reject it even earlier, before it is ever signed. | | Key loss | User loses their device and passkey | Multi-device passkey sync, exportable keys, and social recovery (post-beta). See [Key Management & Custody](/privacy-and-confidential-transfers/key-management.md). | | Replay and forgery | Reuse or forgery of a signed transaction | Standard EVM transaction signing and account-nonce semantics apply, same guarantees as any Robinhood Chain transaction. | | Censorship | The sequencer delays or refuses a transaction | Robinhood operates the chain's single sequencer in its initial phase, but the Arbitrum stack's delayed inbox on Ethereum guarantees forced inclusion of any transaction the sequencer ignores. | | Availability | HoodPrivate's backend becomes unavailable | Funds live in user-owned smart accounts on Robinhood Chain, not HoodPrivate-controlled contracts. Any EVM wallet or tool can interact with them directly using an exported key. | *** ## What HoodPrivate can and cannot do **HoodPrivate can:** * Route requests, render the app, and index on-chain events for a real-time feed * Generate and send webhook notifications * Evaluate and enforce spend policies at the point an agent's client attempts to sign a transaction * Facilitate KYC and selective disclosure workflows you initiate **HoodPrivate cannot:** * Move your funds without your signature. It never holds your private key. * Read your transaction amounts. It never holds your decryption key. * Alter a transaction after it's signed. Robinhood Chain rejects anything that doesn't match a valid signature, and the verifier contract rejects anything without a valid proof. * Bypass an agent's spend policy. Policy limits are enforced on-chain by the account's validation contract, and checked client-side before signing, not as a discretionary backend review. The "cannot" list is the more important one. These are structural guarantees, enforced by cryptography and consensus rather than corporate policy. *** ## Client-side proof generation All zero-knowledge proof generation for confidential transfers happens on your device, using WASM, never on HoodPrivate's servers. This is a structural choice, not a policy promise: your unencrypted balance and transfer amounts never leave your device in a form HoodPrivate's infrastructure could intercept even if it wanted to. The sequencer, likewise, only ever orders ciphertexts. It never sees balances or transfer values. *** ## Dedicated RPC HoodPrivate uses dedicated RPC infrastructure rather than public Robinhood Chain RPC endpoints, for reliability under load. This affects performance, not the trust model. Any transaction submitted through HoodPrivate's RPC can equally be submitted through any other RPC provider, since it's a standard signed Robinhood Chain transaction, and in the extreme case, forced in through the delayed inbox on Ethereum. There is no privileged path and no gatekeeper. *** ## Idempotent submission Every HoodPrivate submission is pinned to a specific account nonce, so a transaction that needs to be retried due to network conditions can only ever be included once. Idempotent submission logic on top of standard EVM nonce semantics makes double-sends structurally impossible. *** ## Risks and mitigations | Risk | Mitigation | | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Device loss with no synced passkey | Export your key proactively and store it securely; social recovery planned post-beta | | Low-power device can't generate a ZK proof quickly | Server-assisted proof generation fallback, using only client-derived inputs, never plaintext amounts | | Agent's parent account is compromised | Spend policy limits bound the damage even if the parent account's session is hijacked; revoke the agent's key immediately from the dashboard | | Regulatory action targeting HoodPrivate as a company | On-chain funds sit in user-owned smart accounts, not HoodPrivate-custodied contracts. Users retain direct on-chain access regardless of HoodPrivate's operational status. | | Sequencer or network outage | Redundant RPC providers and a status page; forced inclusion via Ethereum's delayed inbox remains available. No funds are at risk during an outage, only availability of the app. | --- # 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://docs.hoodprivate.com/protocol-and-architecture/trust-and-security.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.