> For the complete documentation index, see [llms.txt](https://docs.useprivatus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useprivatus.com/protocol-and-architecture/trust-and-security.md). # Trust & Security Model Privatus is engineered so that custody, transaction validity, and confidentiality never depend on trusting Privatus 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 | Privatus is compromised or coerced into moving user funds | Non-custodial keys, generated and held on-device. Privatus never holds private keys. | | Confidentiality | Privatus or a third party reads transaction amounts | ZK proof generation and decryption happen client-side. Privatus's backend only ever sees ciphertext. | | Transfer validity | A malformed or overdrawing transfer is submitted | Solana's native ZK proof program checks the range and validity proofs for confidential balances, and Privatus's on-chain Groth16 verifier (alt\_bn128 syscalls) checks shielded pool proofs, before encrypted state is updated. Verification is part of consensus: an invalid proof cannot settle. | | Agent overspend | An agent transacts beyond its authorized limit | Spend policies live on-chain in the Privatus agent program's state; a policy-violating transaction fails the program's checks. 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, Squads-based key rotation, 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 Solana Ed25519 signing applies, and every transaction is bound to a recent blockhash and deduplicated by signature. Same guarantees as any Solana transaction. | | Censorship | A block producer delays or refuses a transaction | Solana has no central operator ordering transactions. Blocks come from a globally distributed validator set with rotating leaders; a transaction refused by one leader is picked up by the next, and no single party can exclude Privatus traffic. | | Availability | Privatus's backend becomes unavailable | Funds live in user-owned smart accounts on Solana, not Privatus-controlled programs. Any Solana wallet or tool (Phantom, Solflare, Backpack) can interact with them directly using an exported key. | *** ## What Privatus can and cannot do **Privatus 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 **Privatus 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. Solana rejects anything that doesn't match a valid signature, and the ZK proof program rejects anything without a valid proof. * Bypass an agent's spend policy. Policy limits are enforced on-chain by the agent program, 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 Privatus's servers. This is a structural choice, not a policy promise: your unencrypted balance and transfer amounts never leave your device in a form Privatus's infrastructure could intercept even if it wanted to. Validators, likewise, only ever order ciphertexts. They never see balances or transfer values. *** ## Dedicated RPC Privatus uses dedicated RPC infrastructure rather than public Solana RPC endpoints, for reliability under load. This affects performance, not the trust model. Any transaction submitted through Privatus's RPC can equally be submitted through any other RPC provider, since it's a standard signed Solana transaction. There is no privileged path and no gatekeeper. *** ## Idempotent submission Every Privatus submission is bound to a recent blockhash and identified by its transaction signature, which the network deduplicates: a transaction retried due to network conditions can only ever be included once, and if its blockhash expires unincluded, it is dead and must be rebuilt and re-signed. Idempotent submission logic on top of these Solana 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; Squads-based rotation on Pro and above; 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 Privatus as a company | On-chain funds sit in user-owned smart accounts, not Privatus-custodied programs. Users retain direct on-chain access regardless of Privatus's operational status. | | Network congestion or outage | Redundant RPC providers, priority-fee handling, and a status page. 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.useprivatus.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.