> ## Documentation Index
> Fetch the complete documentation index at: https://docs.privacyboost.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Trust & Security
> TEE guarantees, self-custody, forced withdrawal, and threat model
Privacy Boost gives you three guarantees:
1. **The operator cannot access your data.** TEE hardware isolation prevents it.
2. **The operator cannot move your funds.** Every transfer requires your own signature.
3. **You can always exit.** Forced withdrawal bypasses the server entirely.
Below, each guarantee is broken down: the mechanism that enforces it, the trust assumptions it rests on, and how your funds stay safe even in worst-case scenarios.
***
## Guarantee 1: The Operator Cannot Access Your Data
The TEE (Trusted Execution Environment) is a hardware-isolated enclave, a protected region of the CPU where all memory is encrypted by the hardware itself. The operating system, hypervisor, and server administrator cannot read or modify what's inside.
### How It Works
**Hardware isolation:** The CPU encrypts all enclave memory with keys that only the CPU has access to. There is no API, debug interface, or admin backdoor to read enclave contents. Even a physical memory dump yields only encrypted data.
**Remote attestation:** Before sending any data, your SDK verifies a cryptographic attestation from the hardware that:
* The CPU is genuine TEE hardware (AMD SEV-SNP on Azure Confidential Computing)
* The software running inside the enclave matches an expected code hash
* The enclave has not been tampered with
Attestation is verified via Azure MAA (Microsoft Azure Attestation), a JWT-based attestation service that provides cryptographic proof of the enclave's integrity.
**Key management:** The TEE's private keys are derived from a root key released via Secure Key Release (SKR), where the hardware attestation service only releases the key to a verified enclave. The operator never sees these keys in plaintext.
### What This Means in Practice
| Scenario | Can the operator... | Answer |
| ----------------------------------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SSH into the server and dump memory | Read user data? | **No.** Enclave memory is hardware-encrypted. |
| Take a database backup | Decrypt transaction details? | **No.** The decryption key only exists inside the enclave. |
| Deploy malicious code | Steal user funds? | **No.** Spending requires user EdDSA signatures. Attestation also fails if the code hash changes. |
| Shut down the server | Prevent users from accessing funds? | **Temporarily.** Users can always forced-withdraw directly from the contract. |
| Inspect network traffic | See transaction contents? | **No.** Every request and response is end-to-end encrypted to the attested enclave (X25519 + ChaCha20-Poly1305), so only the TEE can decrypt it, never the network or the operator. |
### What Stays Inside the Enclave
Transaction plaintext stays in the enclave. The TEE needs transaction details (amounts, counterparties) to generate ZK proofs and index balances, so it reads them inside the hardware-isolated enclave, but this data **never leaves** in unencrypted form.
The TEE **does not** hold users' viewing keys or EdDSA auth signing keys: these stay on the client and are never sent to the TEE. The TEE has only its own key (TxPrivKey), used to decrypt transaction ciphertexts.
***
## Guarantee 2: The Operator Cannot Move Your Funds
Every transfer and withdrawal requires the user's EdDSA signature. This signature is verified inside the ZK circuit, and the smart contract won't accept a proof without it. The operator doesn't have the user's EdDSA key and can't forge the signature.
This is not a policy; it's a cryptographic impossibility. Even a fully compromised TEE cannot authorize transfers on behalf of users.
***
## Guarantee 3: You Can Always Exit
**Forced withdrawal** is the self-custody escape hatch. If the server goes down (temporarily or permanently), you can withdraw your funds using only:
* Your own private keys (viewing key, nullifying key, auth key)
* Public onchain data (available from any Ethereum node)
### How It Works
1. **Reconstruct your notes:** Scan onchain events and decrypt the receiver-targeted ciphertexts using your viewing key. Check the nullifier registry to find which notes are still unspent.
2. **Generate a ZK proof locally:** This runs on consumer hardware. No TEE needed.
3. **Submit to the contract:** The contract verifies the proof and starts a configurable delay period.
4. **Execute after the delay:** The contract transfers your tokens.
### Why There's a Delay
* **A built-in review window.** A forced withdrawal is never instant. It is requested onchain and must wait out a public delay before it can execute, which keeps the operation transparent and lets the account owner cancel a request they did not intend, using their owner EOA.
* **Clean handling of concurrent activity.** If those notes are spent through normal activity while a forced withdrawal is pending, the forced withdrawal simply finds nothing left to claim (the nullifiers are already spent), so there is no double-spend and no stuck funds.
### The Bottom Line
Even in the worst case (the TEE is permanently destroyed, the operator is malicious, the server is offline forever), you can recover every token you deposited. Funds are secured by the Ethereum smart contract, not by the TEE.
***
## Security Boundaries
| Boundary | What Crosses | Protected By | If Broken |
| ------------------- | --------------------------------------------- | --------------------------------------------- | ------------------------------------------------ |
| **User ↔ TEE** | Signed requests, balance queries, attestation | Enclave-bound encryption + remote attestation | Privacy loss for that session. Funds safe. |
| **TEE ↔ Contract** | Proofs, nullifiers, commitments, ciphertexts | Onchain proof verification | N/A. Contract independently verifies everything. |
| **User ↔ Contract** | Client-generated proofs (forced withdrawal) | Onchain proof verification + delay | N/A. Fully trustless path. |
***
## Privacy Properties
### What Is Hidden
| Property | How |
| -------------------- | ---------------------------------------------------------------------------- |
| Sender identity | Nullifier is unlinkable to commitment; proven in ZK |
| Recipient identity | Commitment hides the owner; requires viewing key to decrypt |
| Token type | Inside the commitment hash; not exposed onchain |
| Transfer amount | Inside the commitment hash; not exposed onchain |
| Which note was spent | Nullifier derived from secret key + leaf index; unlinkable to any commitment |
### What Is Not Hidden
| Property | Why |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Deposit/withdrawal addresses | Public ERC-20 transfers |
| Deposit/withdrawal amounts | Public fields in the transaction |
| Number of transfers per batch | Public metadata |
| Transaction timing | Block timestamps |
| Earn / DeFi actions | The vault, token, and amount are public onchain, like a public withdrawal, but not linked to a wallet identity |
### Anonymity Set
The anonymity set is all UTXOs across all historical Merkle trees, a theoretical maximum of over 34 billion UTXOs.
***
## State Recovery
### TEE Recovery
If the TEE loses its state, it reconstructs everything from onchain events: replays deposit and transfer events, decrypts metadata using its TxPrivKey, and rebuilds the full Merkle tree and balance state.
### User Recovery
Users can independently reconstruct their own notes using only onchain data and their viewing key. This is the foundation of forced withdrawal and works without any server infrastructure.
***
## Next Steps
* [Protocol Deep Dive](/technical-explainer/protocol): Transaction lifecycle and circuit details
* [Keys & Encryption](/technical-explainer/keys-and-encryption): Full encryption scheme
* [Auditability](/product/auditability): How regulated access works
* [Glossary](/technical-explainer/glossary): Technical terminology reference