What Are Viewing Keys?
The master viewing key (MVK) is a 252-bit BN254 field element derived deterministically from your master seed. It sits at the root of a hierarchical key system that lets you grant scoped read access to your Stealth Pool activity without ever exposing the root key or any data outside the defined scope. Viewing keys are designed for compliance and audit use cases:- Provide an auditor or regulator access to transactions within a specific time window
- Grant a compliance officer access to all activity for a specific token
- Share full visibility at the master level with a tax advisor or legal counterparty
- Prove to an exchange that specific Stealth Pool Notes originated from you.
Viewing keys are read-only credentials. Possessing a viewing key does not allow burning Stealth Pool Notes or withdrawing balances. They can only be used to decrypt ciphertext data that was encrypted under the associated key — specifically the
pc_encrypted_* (Poseidon stream cipher) fields on a note. They cannot decrypt the AES-GCM or Rescue ciphertexts.The Viewing Key Hierarchy
All keys in the hierarchy are BN254 field elements. Each level is derived from its parent using the Poseidon hash function. A key at any level grants access to all data within its scope - and nothing above or adjacent to it in the tree.- Monthly key for
2025-02: sees all USDC mixer activity in February 2025 - Yearly key for
2025: sees all USDC mixer activity across all of 2025 - Mint key for USDC: sees all USDC mixer activity, all time
- Master viewing key: sees everything across all tokens and all time
Deriving Viewing Keys
Each level of the hierarchy has a corresponding deriver factory function. Pass{ client } to get a deriver, then call it with the appropriate parameters.
Master Viewing Key
Mint Viewing Key
Yearly Viewing Key
Monthly Viewing Key
Daily Viewing Key
Exporting and Sharing a Viewing Key
Viewing keys arebigint values (BN254 field elements). Export them as decimal or hex strings for out-of-band sharing with an auditor:
Sharing Example
How Key Derivation Works
Viewing keys are derived using the Poseidon hash function over BN254. Starting from the master viewing key:- You cannot derive a parent key from a child key - the tree is one-directional
- Child keys can always be re-derived from the parent at any time
- Two separate mint keys cannot be linked without the master viewing key
Security Properties
- One-directional - a grantee who holds a monthly key cannot derive the yearly key, the master viewing key, or any key for another mint or time period
- Unlinkable - viewing keys for different months or mints are computationally unrelated without the master key
- Deterministic - the same wallet on the same network always produces the same viewing key hierarchy; keys can be re-derived at any time
- Non-transactional - sharing a viewing key does not create any on-chain state; it is a purely off-chain credential
What Auditors Can Do With a Viewing Key
An auditor who holds a viewing key can:- Scan the Stealth Pool (Indexed Merkle Tree) for notes that were encrypted under the corresponding key.
- Decrypt the note
pc_encrypted_*payloads (Poseidon stream cipher) to learn the amount and recipient. - Verify that specific transactions occurred within the defined scope.
- Access any data outside the scope of the key they hold.
- Burn Stealth Pool Notes — viewing keys are read-only, not spending keys.
- Link the activity to any adjacent scope without the parent key.
- Decrypt the X25519 + AES-GCM ciphertext (
aes_encrypted_data) or the Rescue ciphertext (rc_encrypted_*) — those use independent keys.
No opinionated
getViewingKey…NoteScannerFunction factory is shipped — auditors compose one from the shipped primitives. Pattern (~50 lines): for each note, call getSecondViewingKeyDeriver for the granted scope, then call getPoseidonDecryptor with the Second Viewing Key as the cipher key and the keystream Poseidon([transactionViewingKey, counter, 2n]) to recover the plaintext.