Selective Transparency & Auditability

Umbra separates viewing rights from spending rights. This separation allows users to selectively share visibility into their transaction history and balances without giving up control over their funds. You can prove compliance, enable auditing, or share specific details-all without exposing your spending keys.

Umbra has two distinct viewing key systems for its two privacy layers:

---

Mixer Pool: Transaction Viewing Keys

For the Unified Mixer Pool, viewing access is controlled through Transaction Viewing Keys (TVKs) derived from the Master Viewing Key (MVK).

How It Works

The MVK is a 252-bit secret that serves as the root of all mixer viewing capabilities. From the MVK, you can derive time-scoped TVKs through a chain of Poseidon hashes, where each level takes the previous key and hashes it with a time component.

Derivation Process

TVKs are derived recursively using Poseidon hashes over the BN254 field with the $x^5$ S-box:

Level 1 - Yearly TVK:

$$TVK_{\text{year}} = \text{Poseidon}(MVK, \text{Year})$$

Level 2 - Monthly TVK:

$$TVK_{\text{month}} = \text{Poseidon}(TVK_{\text{year}}, \text{Month})$$

Level 3 - Daily TVK:

$$TVK_{\text{day}} = \text{Poseidon}(TVK_{\text{month}}, \text{Day})$$

Level 4 - Hourly TVK:

$$TVK_{\text{hour}} = \text{Poseidon}(TVK_{\text{day}}, \text{Hour})$$

Each hash takes the previous TVK and combines it with the next time component, creating a hierarchical chain.

Granularity

Key Properties

• Hierarchical - A parent TVK can derive all its children (e.g., yearly can derive monthly)
• One-Way - Child TVKs cannot derive parent TVKs or the MVK
• Non-Revocable - Once shared, a TVK grants permanent access to that time scope
• Off-Chain - TVKs are derived and shared directly between parties

Examples

Example 1: Tax Compliance

You need to provide transaction records for 2024 to your accountant:

1. Derive the yearly TVK: $TVK_{2024} = \text{Poseidon}(MVK, 2024)$
2. Share $TVK_{2024}$ with your accountant
3. Accountant can see all 2024 transactions
4. Accountant cannot see 2023, 2025, or any other year
5. Accountant cannot derive your MVK or spend any funds

Example 2: Payment Proof

You need to prove you paid a specific invoice on March 15, 2025:

1. Derive: $TVK_{2025} = \text{Poseidon}(MVK, 2025)$
2. Derive: $TVK_{2025\text{-}03} = \text{Poseidon}(TVK_{2025}, 3)$
3. Derive: $TVK_{2025\text{-}03\text{-}15} = \text{Poseidon}(TVK_{2025\text{-}03}, 15)$
4. Share $TVK_{2025\text{-}03\text{-}15}$ with the verifier
5. Verifier can confirm the payment occurred on that day
6. Verifier cannot see transactions from other days

Example 3: Ongoing Audit

A compliance officer needs monthly access for Q1 2025:

1. Derive and share $TVK_{2025\text{-}01}$ for January
2. Derive and share $TVK_{2025\text{-}02}$ for February
3. Derive and share $TVK_{2025\text{-}03}$ for March
4. Officer gets rolling visibility for each month
5. Officer can also derive daily/hourly TVKs within each shared month

For complete technical details, see Master Viewing Key.

---

Confidential Balances: Viewing Grants

For Encrypted Token Accounts (ETAs) and other confidential data, viewing access works differently. Instead of derived keys, it uses on-chain grants that enable the MPC to re-encrypt data for a specific grantee.

How It Works

All confidential data in Umbra is encrypted using a shared secret derived from the user's X25519 keypair and the MPC's public key. Each encryption uses a unique nonce.

Confidential Balance Viewing Keys allow a grantee to see any encryption related to the granter's X25519 public key for a specific nonce. This could be:

• An account balance
• A transfer amount
• Any other data encrypted with that nonce for the MPC

Grant Process

1. Granter creates an on-chain grant specifying:

   • The grantee's X25519 public key (already registered on-chain)
   • The specific nonce for which access is granted

2. MPC performs re-encryption - The MPC re-encrypts the data for the grantee's X25519 public key

3. Grantee can decrypt the data for that specific nonce only

Granularity

Confidential Balance Viewing Keys are extremely granular:

• Each grant is valid for one specific nonce only
• Subsequent encryptions with different nonces are not readable without new grants
• Any new encrypted data (balance updates, transfers, etc.) requires a new grant for visibility

Revocability

Confidential Balance Viewing Keys are semi-revocable:

• The on-chain grant can be deleted by the granter
• If the grantee has already used the grant - The MPC has already performed the re-encryption, so the grantee already has the decrypted data. Deleting the grant has no effect.
• If the grantee has not yet used the grant - Deleting the grant prevents the MPC from performing the re-encryption. The grantee loses access.

This is in contrast to Mixer Pool TVKs, which are non-revocable-once shared, the grantee permanently has the key and can decrypt at any time.

Use Cases

• Point-in-time audit - Grant access to a specific balance snapshot
• Transfer disclosure - Share visibility of a specific transfer amount
• Per-operation disclosure - Reveal any individual encrypted operation
• Compliance checkpoints - Provide access at specific intervals

---

Comparison: Two Viewing Systems

---

Privacy Without Obscurity

Both viewing systems maintain the core principle: viewing keys cannot spend funds.

This separation enables:

• Default Privacy - All data is encrypted by default
• Opt-In Transparency - Share viewing access when needed
• Granular Control - Choose exactly what to reveal and to whom
• Cryptographic Guarantees - Access is mathematically enforced

---

Related Documentation

• Master Viewing Key - TVK derivation for mixer pool
• X25519 Keypair - Key used in confidential balance grants
• Unified Mixer Pool - The anonymity layer
• Encrypted Token Accounts - The confidentiality layer