The user’s existing ECDSA private key (secp256k1) from their Ethereum wallet. Root of account ownership. Used to manage auth keys in the AuthRegistry via EIP-712 signatures. Never enters the TEE.
An EdDSA key pair on the BabyJubjub curve, registered in the AuthRegistry contract. Authorizes transfers and withdrawals inside ZK circuits. A single account can have multiple auth keys (one per device). Can be rotated or permanently revoked by the account owner.
An elliptic curve key pair (secp256k1) used for ECDH-based encryption and decryption of transaction metadata. Lets you see your balance and transaction history. Included in your privacy address so senders can encrypt data for you. Compromise reveals your transaction history but does not put funds at risk.
A secret scalar (not a key pair) that binds your public identity to your notes. Used for deriving your MPK and computing nullifiers when spending notes. If compromised, an attacker can identify your notes and track your UTXO set, but cannot spend your funds (spending requires an auth key signature).
Your identity within Privacy Boost, derived from your account ID and nullifying key via Poseidon2 hashing. Public information, safe to share. Part of your privacy address.
A compact encoding of your MPK and viewing public key (96 bytes total). Share this to receive private transfers. Contains everything a sender needs to construct an encrypted output for you.
A protocol-level identifier for a user account, derived via Poseidon2 hashing during key setup. Used in key derivation and as a field in encrypted transaction metadata. Not an Ethereum address.
A UTXO (unspent transaction output) representing a specific amount of a specific token. A note contains: NPK (Note Public Key), token ID, and value. Notes are never stored in plaintext onchain — only their commitments are.
A per-note unique key derived from the owner’s MPK and a random value. The randomness ensures every commitment is unique, even for identical recipients and amounts.
A Poseidon2 hash of a note’s contents (NPK, token ID, value). Published onchain as a Merkle tree leaf. Reveals nothing about the note. Cannot be brute-forced due to 128-bit randomness in NPK.
A one-time-use tag that marks a specific note as spent, derived from the owner’s nullifying key and the note’s position in the Merkle tree. Published onchain when a note is consumed. Cannot be linked to its source commitment by an outside observer. The contract enforces uniqueness to prevent double-spending.
An append-only tree using Poseidon2 hashing that stores all note commitments. Uses the LeanIMT (Lean Incremental Merkle Tree) design for efficient onchain appends. The contract holds the root; the TEE maintains the full tree. Proofs of inclusion are used in ZK circuits to verify that a note exists without revealing which one.
The process of creating a new Merkle tree when the active tree reaches capacity. Old trees remain queryable — notes in finalized trees can still be spent.
Moving tokens from a public wallet into the shielded pool. A 2-step process: the user locks tokens, then the TEE processes the deposit into the Merkle tree. Individual note amounts are hidden; only the total deposit amount is public.
Moving tokens between shielded notes. Input notes are consumed (nullifiers published), new output notes are created for the recipient. Sender identity, recipient identity, token type, and amounts are all hidden from onchain observers.
Moving tokens from the shielded pool to a public address. Processed using the same mechanism as transfers. The withdrawal address and amount are public.
A trustless exit path that bypasses the TEE entirely. The user generates a ZK proof locally and submits it directly to the contract. Has a configurable delay period for security. Works with only the user’s private keys and onchain data.
A batch of transactions verified by a single Groth16 proof. Batching amortizes the ~200K gas verification cost across all transactions, enabling high throughput. Epochs are submitted when the batch reaches the configured size.
The encryption scheme that gives two independent parties (TEE and recipient) the ability to decrypt the same transaction metadata. The sender performs ECDH with both the TEE’s public key and the recipient’s viewing public key, blinded with the same random scalar. See Keys & Encryption for the full scheme.
The TEE’s transaction key pair. TxPubKey is published onchain so users can encrypt data for the TEE. TxPrivKey is held exclusively inside the TEE enclave and used to decrypt transaction ciphertexts for indexing and balance tracking.
The sender’s viewing public key multiplied by a random scalar. Published in transaction calldata. The blinding prevents different transactions from the same sender from being linked.
A ZK-friendly hash function. Used for commitments, nullifiers, MPK derivation, and Merkle tree nodes. Efficient inside arithmetic circuits, making it ideal for ZK proof systems.
A zero-knowledge proof system with constant-size proofs and constant verification cost (~200K gas). Uses the BN254 curve with native EVM precompile support. Requires a per-circuit trusted setup.
The elliptic curve used for Groth16 proofs. Has native EVM precompile support for point addition, scalar multiplication, and pairing checks, making onchain verification efficient.
A twisted Edwards curve embedded in the BN254 scalar field. Used for EdDSA signatures inside ZK circuits because arithmetic on this curve is efficient in BN254-based circuits.
A key agreement protocol. Two parties with their own key pairs can compute a shared secret without either revealing their private key. Used in the dual-path ECDH scheme.
HMAC-based Key Derivation Function (using SHA-256). Derives encryption keys from ECDH shared secrets and derives viewing key and nullifying key from the wallet signature.
Manages the binding between account IDs and EdDSA auth keys. Supports registration, rotation, and revocation. Maintains its own Poseidon2 Merkle tree and uses snapshots to provide stable references for epoch proofs.
A standalone contract that manages the auditor registry and logs audit queries onchain. Has no connection to the shielded pool — cannot affect fund storage or movement. See Compliance.
A hardware-isolated enclave where the Privacy Boost server runs. Prevents anyone — including the server operator — from accessing data inside the enclave. Deployed on Azure Confidential Computing with AMD SEV-SNP. Verified via remote attestation through Azure MAA.
A cryptographic proof from TEE hardware that the enclave is genuine and running expected code. Implemented via Azure MAA (Microsoft Azure Attestation). The SDK verifies this before sending any data to the TEE server.
The mechanism by which the TEE obtains its root key. The attestation service releases the key only to a verified enclave. The root key is used to derive all TEE operational keys via HKDF.
