Security and Threat Model
Cyphron is designed so that custody, validity, and confidentiality never depend on trusting Cyphron 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 | Cyphron is breached or pressured into moving funds | Keys are non-custodial, generated and stored on the device. Cyphron never holds a private key. |
| Confidentiality | Cyphron 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. |
| 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 | Cyphron's backend is offline | Funds live in user-owned smart accounts on Robinhood Chain rather than in contracts Cyphron controls. With an exported key, any EVM wallet can access them directly. |
What Cyphron can and cannot do
Cyphron 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
Cyphron 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
AgentControllerand 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 Cyphron's servers. This is a matter of structure, not policy: your plaintext balance and amounts never exist anywhere Cyphron's infrastructure could capture them, whether it wanted to or not. The sequencer only orders ciphertext and never sees a balance or an amount.
Cyphron's own RPC
To stay reliable under heavy load, Cyphron 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 Cyphron 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 Cyphron 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. |