Key Hierarchy
Privacy Boost uses four types of keys. Each serves a distinct purpose and has different security implications if compromised.1. Account Owner
The registered owner can be an EOA controlled by an ECDSA key, a delegated EOA, or a smart account. Owner authorization manages the account and its spend permissions.- Used for: Managing signing keys through AuthRegistry owner authorization, creating approval-only accounts, approving spend commitments, revoking approval batches, and cancelling forced withdrawals.
- 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 key-mode transfers and withdrawals inside ZK circuits. Account-owner spend approvals provide a separate authorization mode without an EdDSA signature.
- Why EdDSA? EdDSA on BabyJubjub is efficient to verify inside the circuit.
- Multi-device: A key-enabled account can register multiple signing keys, rotate them, and revoke them. An approval-only account cannot register signing keys.
- If compromised: An attacker who also holds your nullifying key and note data 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 valid spend authorization and the note secrets).
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 also requires a registered-key signature or an account-owner spend approval). But they can link your transactions.
Account-Owner Spend Approvals
createAccount(salt) creates an approval-only account that cannot register signing keys. Its owner calls approveSpend or approveSpendBatch with blinded operation commitments. Other registered accounts can also use these approvals.
A batch contains 1 to 256 strictly sorted commitments and expires within 30 days. The circuit proves membership in the batch without exposing which approval leaf it used in a normal epoch. The owner and batch size are visible at registration, and the owner can revoke the whole batch.
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:
All three sources produce the same key types (viewing key, nullifying key, auth key) through the same HKDF derivation, and they only differ in where the input seed comes from.
For practical usage (code examples, persistence options, and recovery), see Key Management in the SDK documentation.
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.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