> For the complete documentation index, see [llms.txt](https://docs.sectoral.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sectoral.xyz/under-the-hood/threat-model.md). # Security and Threat Model Sectoral is designed so that custody, validity, and confidentiality never depend on trusting Sectoral as a company. Each layer stands on its own and addresses a specific threat, and every guarantee is meant to hold even when the company itself is the adversary. *** ## Threats and defenses by layer | Layer | Threat | Defense | | ----------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Custody | Sectoral is breached or pressured into moving funds | Keys are non-custodial, generated and stored on the device. Sectoral never holds a private key. | | Confidentiality | Sectoral or a third party tries to read amounts | Proofs and decryption happen on the client. The backend only ever handles ciphertext. | | Transfer validity | Someone submits a malformed transfer or one that overdraws | Before any balance changes, the on-chain verifier checks the range and validity proofs. Robinhood Chain settles to Ethereum via the Arbitrum stack's fraud proofs, so that check is ultimately secured by Ethereum. | | Agent overspend | An agent tries to spend beyond what it is allowed | Policies are stored and enforced on-chain in `AgentController`, which rejects any spend that breaks them. Client-side checks catch it even earlier, before signing. | | Key loss | Both the device and the passkey are lost | Passkey sync across devices, exportable keys, and social recovery once beta ends. See [Keys and Account Recovery](/privacy-and-cryptography/keys-and-recovery.md). | | Replay or forgery | A signed transaction is replayed or forged | Ordinary EVM signatures and account nonces, exactly as for any other Robinhood Chain transaction. | | Censorship | The sequencer halts or declines a transaction | For now Robinhood operates a single sequencer, but the Arbitrum stack's delayed inbox on Ethereum guarantees inclusion of anything the sequencer skips. | | Availability | Sectoral's backend is offline | Funds live in user-owned smart accounts on Robinhood Chain rather than in contracts Sectoral controls. With an exported key, any EVM wallet can access them directly. | *** ## What Sectoral can and cannot do **Sectoral can:** * Route requests, serve the app, and index chain events into a live feed * Create and deliver webhooks * Check spend policy when an agent's client attempts to sign * Operate the KYC and disclosure flows that you start **Sectoral cannot:** * Move your funds without your signature, since it has none of your private keys. * See your amounts, since it has none of your decryption keys. * Tamper with a signed transaction. The chain refuses anything with a bad signature, and the verifier refuses anything without a valid proof. * Override an agent's policy. Limits are enforced on-chain by `AgentController` and checked on the client before signing, not judged by a backend on a case-by-case basis. The "cannot" list is the important one. Each item on it follows from cryptography and consensus, not from a promise in a policy document. *** ## Proving happens on your device For confidential transfers, zero-knowledge proofs are generated locally in WASM and never on Sectoral's servers. This is a matter of structure, not policy: your plaintext balance and amounts never exist anywhere Sectoral's infrastructure could capture them, whether it wanted to or not. The sequencer only orders ciphertext and never sees a balance or an amount. *** ## Sectoral's own RPC To stay reliable under heavy load, Sectoral operates its own RPC infrastructure instead of depending on public Robinhood Chain endpoints. This choice is about performance and has nothing to do with trust. Every transaction Sectoral submits is a standard signed Robinhood Chain transaction that any other provider could submit just as well, and as a last resort it can be forced in through Ethereum's delayed inbox. There is no privileged route and no gatekeeper. *** ## Safe retries Every submission is tied to a particular account nonce, so even if a transaction is retried on a flaky connection, it can be included only once. Because submission is idempotent and built on standard EVM nonces, sending twice by accident simply cannot happen. *** ## Remaining risks and mitigations | Risk | Mitigation | | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | A device is lost and no passkey was synced | Export your key ahead of time and keep it somewhere safe; social recovery arrives after beta | | A device is too slow to generate proofs quickly | Server-assisted proving from inputs derived on the client, never from plaintext amounts | | The parent account is compromised | Policy limits cap the damage even if a session is hijacked; revoke the agent's key from the dashboard right away | | Regulators take action against the company | Funds are held in user-owned smart accounts, not in accounts Sectoral custodies. On-chain access continues regardless of what happens to the company. | | The sequencer or the network goes down | Multiple RPC providers and a status page, with forced inclusion via Ethereum's delayed inbox still available. Service may degrade; funds remain safe. | --- # 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.sectoral.xyz/under-the-hood/threat-model.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.