- The operator cannot access your data. TEE hardware isolation prevents it.
- The operator cannot move your funds. Every transfer requires your own signature.
- You can always exit. Forced withdrawal bypasses the server entirely.
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
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. TLS termination happens inside the enclave. |
What the TEE Sees
The TEE does see transaction plaintext (amounts, counterparties) inside the enclave — it needs this to generate ZK proofs and index balances. But this data never leaves the enclave in unencrypted form. The TEE does not hold users’ private keys. It has its own key (TxPrivKey) for decrypting transaction ciphertexts, but users’ viewing keys, nullifying keys, and auth keys are never sent to the TEE.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 — 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
- 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.
- Generate a ZK proof locally: This runs on consumer hardware. No TEE needed.
- Submit to the contract: The contract verifies the proof and starts a configurable delay period.
- Execute after the delay: The contract transfers your tokens.
Why There’s a Delay
- Security: If an attacker compromises your auth key and requests a forced withdrawal, the delay gives you time to cancel the request using your EOA key.
- Race resolution: If the TEE processes the same notes during the delay via a normal transaction, the forced withdrawal safely fails (nullifiers already spent).
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 | TLS + 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 |
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 — Transaction lifecycle and circuit details
- Keys & Encryption — Full encryption scheme
- Compliance & Auditing — How regulated access works
- Glossary — Technical terminology reference