> For the complete documentation index, see [llms.txt](https://docs.hooded.cash/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hooded.cash/protocol-and-architecture/trust-and-security.md). # Trust & Security Model HoodedCash is designed so that custody, transaction validity, and confidentiality don't depend on trusting HoodedCash as a company. Security is layered, and each layer addresses a distinct threat. *** ## Security layers | Layer | Threat addressed | Mechanism | | ------------------ | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Custody | HoodedCash is compromised or coerced into moving user funds | Non-custodial keys, generated and held on-device. HoodedCash never holds private keys. | | Confidentiality | HoodedCash or a third party reads transaction amounts | ZK proof generation and decryption happen client-side. HoodedCash's backend only ever sees ciphertext. | | Transfer validity | A malformed or overdrawing transfer is submitted | HoodedCash'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 | HoodedCash's backend becomes unavailable | Funds live in user-owned smart accounts on Robinhood Chain, not HoodedCash-controlled contracts. Any EVM wallet or tool can interact with them directly using an exported key. | *** ## What HoodedCash can and cannot do **HoodedCash 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 **HoodedCash 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. *** ## Client-side proof generation All zero-knowledge proof generation for confidential transfers happens on your device, using WASM, not on HoodedCash's servers. This is a structural choice, not a policy promise: your unencrypted balance and transfer amounts never leave your device in a form HoodedCash'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 HoodedCash 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 HoodedCash'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. *** ## Idempotent submission Every HoodedCash 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 prevents double-sends. *** ## 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 HoodedCash as a company | On-chain funds sit in user-owned smart accounts, not HoodedCash-custodied contracts. Users retain direct on-chain access regardless of HoodedCash'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.hooded.cash/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.