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 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

​
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

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

​
Privacy Properties

​
What Is Hidden

​
What Is Not Hidden

​
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