Key Hierarchy
Privacy Boost uses four types of keys. Each serves a distinct purpose and has different security implications if compromised.1. EOA Key (Account Owner)
Your existing ECDSA private key (secp256k1) from your Ethereum wallet (MetaMask, hardware wallet, etc.).- Used for: Managing auth keys in the AuthRegistry (register, rotate, revoke) via EIP-712 signatures. This is the root of account ownership onchain.
- Never enters the TEE in raw form.
- If compromised: Attacker can register new auth keys or revoke existing ones. This is your standard Ethereum key, so protect it the way you normally would.
2. Auth Key
An EdDSA key pair on the BabyJubjub curve, registered in the AuthRegistry contract.- Used for: Authorizing transfers and withdrawals inside ZK circuits. Every transfer requires an EdDSA signature from a registered auth key.
- Why EdDSA? EdDSA on BabyJubjub is efficient to verify inside arithmetic circuits. ECDSA verification inside a ZK circuit would cost 10-100x more constraints.
- Multi-device: A single account can have multiple auth keys (one per device). Keys can be rotated or permanently revoked.
- If compromised: Attacker can authorize transfers from your account. Mitigated by revoking the compromised key via your EOA key and cancelling any unauthorized forced withdrawal requests.
3. Viewing Key
An elliptic curve key pair (secp256k1) used for ECDH-based encryption and decryption of transaction metadata.- Used for: Encrypting note metadata for recipients (as a sender) and decrypting incoming note metadata (as a recipient). This is how you discover your balance and transaction history.
- Part of your privacy address: The viewing public key is included in your privacy address so senders can encrypt data for you.
- If compromised: Attacker can see your balance, transaction history, and identify your notes. They cannot spend your funds (that requires the auth key).
4. Nullifying Key
A secret scalar value (not a key pair, just a number), unique per account. This is the core cryptographic binding that ties your identity to your notes.- Used for: Deriving your Master Public Key (MPK) and computing nullifiers when spending notes. See Protocol Deep Dive for the full formulas.
- If compromised: Attacker can identify your notes and track your UTXO set. They still cannot spend your funds (spending requires an auth key signature). But they can link your transactions.
Key Derivation
All protocol-level keys are deterministically derived from a single seed using HKDF-SHA256:Seed Sources
The SDK supports three ways to produce the seed:| Source | How the seed is produced |
|---|---|
| Wallet-derived | The wallet signs a deterministic message; the signature is the input from which the seed is derived. Same wallet always produces the same keys. No extra backup needed. |
| Mnemonic | A BIP-39 12-word phrase is used as the seed. Allows key portability across different wallets, but the phrase must be backed up. |
| Raw seed | Raw entropy (16+ bytes of hex), fed through the same HKDF master-seed derivation as the other sources. |
Privacy Address
Your privacy address is a compact encoding of your MPK and viewing public key:Dual-Path ECDH Encryption
This is the core encryption scheme that enables two things simultaneously:- The TEE server can decrypt transaction metadata for fast indexing and balance queries
- The recipient can independently decrypt the same metadata for manual recovery (forced withdrawal)
Why “Dual-Path”?
The sender performs two independent ECDH operations (one with the TEE’s public key, one with the recipient’s viewing public key) using the same blinded key as input. This produces two separate decryption paths from a single encryption operation.| Party | Key Used | Role |
|---|---|---|
| Sender | Viewing private key (sender’s) | Performs both ECDH computations and encrypts the payload |
| TEE | TxPrivKey (TxPubKey served via the attested /info endpoint) | Decrypts via ECDH with the sender’s blinded viewing key |
| Recipient | Viewing private key (recipient’s) | Decrypts via ECDH with the sender’s blinded viewing key |
How It Works
r and blinds their viewing public key. The X-coordinate of the resulting point, (viewingPubKeySender * r).x, goes onchain (the recipient reconstructs the Y-coordinate from the curve equation). This blinding ensures transactions from the same sender can’t be linked.
2. Derive encryption keys. The sender performs ECDH with the TEE’s public key and the recipient’s viewing public key (both scaled by r), then derives two symmetric keys via HKDF.
3. Encrypt. The sender generates a random ephemeral key (EphTxEncKey) and encrypts the payload with AES-256-GCM.
4. Wrap. The ephemeral key is XOR’d with each derived key, producing two wrap keys: one for the TEE, one for the recipient.
5. Publish. The blinded key, both wrap keys, and the ciphertext go onchain.
How Decryption Works
Both the TEE and recipient can independently recover the ephemeral key:- TEE: Uses its TxPrivKey + the onchain blinded key to perform ECDH, derives the same symmetric key, and XORs the TEE wrap key to recover the ephemeral key.
- Recipient: Uses their viewing private key + the onchain blinded key to perform ECDH, derives the same symmetric key, and XORs the receiver wrap key.
What’s Encrypted
Each output’s ciphertext contains the sender and recipient Master Public Keys (MPKs), token ID, amount, and a random value for commitment uniqueness. Deposits contain the same fields minus the sender MPK.Integrity Verification
For transfers and withdrawals, the TEE decrypts each output ciphertext and checks that its token ID and amount match the server-visible output fields, and that the decrypted recipient MPK plus note randomness derive the output NPK used to compute the onchain commitment. This prevents a sender from submitting a commitment for one note while giving the TEE different plaintext. Recipients can independently recover notes from onchain data when the receiver-targeted ciphertext is well formed for their viewing key. For deposits, the onchain deposit record is authoritative for token ID and total amount; normal deposit note amounts are decrypted and checked to sum to that total, while gateway-origin deposits override the ciphertext amount with the onchain measured amount.How Recipients Discover Their Notes
Normal Operation (TEE Available)
The TEE decrypts all output ciphertexts as part of its normal indexing. It extracts the recipient’s account ID and indexes each note. Recipients query their balance from the TEE indexer, with no scanning required and instant results. The TEE doesn’t store users’ private keys. It only decrypts the per-transaction ciphertexts using its own TxPrivKey to learn which account each note belongs to.Manual Recovery (TEE Unavailable)
If the TEE is down, recipients can discover their notes independently by scanning onchain events and attempting to decrypt each output’s receiver-targeted ciphertext with their viewing key. If decryption succeeds (valid GCM auth tag), the note belongs to them. They then check the nullifier registry to find which notes are still unspent. This is the path used for forced withdrawal, and it works with only onchain data and the user’s own keys.Next Steps
- Protocol Deep Dive: How notes, commitments, and transactions work
- Trust & Security: TEE guarantees, self-custody, threat model
- Glossary: Technical terminology reference