Skip to main content
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 authorization.
  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

​
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 your authorization, through a registered signing key or an account-owner spend approval. The ZK circuit verifies it, and the smart contract rejects any proof without valid authorization. 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 (a registered signing key, or an onchain spend approval the account owner submits at exit time)
  • 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, from their registered owner account.
  • 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. Unclaimed gifts use the separate permissionless public gift-exit path.

​
Security Boundaries

Security boundaries: User Domain, TEE Domain, and Public Domain with trust relationships and forced withdrawal bypass Security boundaries: User Domain, TEE Domain, and Public Domain with trust relationships and forced withdrawal bypass

​
Privacy Properties

​
What Is Hidden in Internal Transfers

​
What Is Not Hidden

​
Anonymity Set

The anonymity set is all UTXOs across all historical Merkle trees, a theoretical maximum of roughly 550 billion UTXOs at the deployed tree depth of 24.

​
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. Portal and gift notes are rebuilt from the records saved when those funds were created (see Portal Deposits and Claimable Transfers).

​
User Recovery

Users can independently reconstruct their own notes using only onchain data and their viewing key. Portal and gift recovery additionally needs the records saved at funding time. This is the foundation of forced withdrawal and works without any server infrastructure. Feature-specific steps are in the Portal Deposits and Claimable Transfers guides.

​
Next Steps