Master Viewing Key

Overview

The Master Viewing Key (MVK) serves two critical functions in Umbra:

1. Linker Creation - Required to generate the linkers necessary for valid ZK proofs when spending UTXOs
2. Transaction Decryption - Enables decryption of transaction history for auditability

The MVK provides view-only access-an auditor with the MVK can see transaction history but cannot spend any funds. However, without the MVK, even the owner cannot spend their UTXOs because linker creation requires the MVK.

---

Technical Specification

Why 252 Bits?

The 252-bit constraint is an implementation detail required by the ZK circuit design.

Inside the circuit, we perform a limbwise representation equality check to verify the MVK. This check requires the value to be represented in a specific number of limbs (smaller chunks), and the 252-bit constraint ensures:

1. The value fits cleanly into the limb structure
2. No overflow occurs during limbwise comparisons
3. The equality check can be performed efficiently within the circuit

This is a practical constraint arising from how large integers are handled inside ZK circuits on the BN254 field.

---

Purpose

Linker Creation for Spending

The MVK is essential for creating linkers - encrypted metadata attached to transactions. Without valid linkers, ZK proof generation fails and spending is impossible.

This means the MVK is not just for viewing - it's required for spending. Even if you have the Shielded Spending Key, you cannot spend UTXOs without the MVK.

---

Transaction Viewing Key Derivation

The MVK enables granular auditability through a hierarchical derivation of Transaction Viewing Keys (TVKs). This allows you to share viewing access for specific time periods without exposing your entire transaction history.

Derivation Structure

TVKs are derived through a chain of hashes, where each level takes the previous key and hashes it with a time component:

Hash Function

The TVK derivation uses the Poseidon hash function over the BN254 scalar field with the S-box exponent $x^5$ as the non-linear component:

$$\text{Hash}(a, b) = \text{Poseidon}_{BN254, x^5}(a, b)$$

Poseidon is chosen for its:

Derivation Formula

The derivation follows a recursive pattern where each time-scoped key is derived from its parent using Poseidon:

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})$$

Level 5 - Minute TVK:

$$TVK_{\text{minute}} = \text{Poseidon}(TVK_{\text{hour}}, \text{Minute})$$

Level 6 - Second TVK:

$$TVK_{\text{second}} = \text{Poseidon}(TVK_{\text{minute}}, \text{Second})$$

Example: Deriving a Monthly TVK for March 2025

To derive the TVK for March 2025:

1. Start with MVK: Your root Master Viewing Key
2. Derive Yearly TVK: $TVK_{2025} = \text{Poseidon}(MVK, 2025)$
3. Derive Monthly TVK: $TVK_{2025\text{-}03} = \text{Poseidon}(TVK_{2025}, 3)$

The resulting $TVK_{2025\text{-}03}$ can decrypt all transactions from March 2025, but cannot decrypt:

• Transactions from any other month in 2025
• Transactions from any other year
• The MVK itself (hash functions are one-way)

Hierarchical Properties

Why This Matters

Scenario 1: Tax Auditor

You need to provide transaction records for 2024 to a tax auditor:

1. Derive $TVK_{2024} = \text{Hash}(MVK, 2024)$
2. Share $TVK_{2024}$ with the auditor
3. Auditor can see all 2024 transactions
4. Auditor cannot see 2023, 2025, or any other year
5. Auditor cannot derive your MVK

Scenario 2: Monthly Reporting

A compliance officer needs access to January 2025 only:

1. Derive $TVK_{2025} = \text{Hash}(MVK, 2025)$
2. Derive $TVK_{2025\text{-}01} = \text{Hash}(TVK_{2025}, 1)$
3. Share $TVK_{2025\text{-}01}$ with the officer
4. Officer can see all January 2025 transactions
5. Officer can also derive more granular keys (daily, hourly) for January 2025
6. Officer cannot see February 2025 or any other month

Scenario 3: Real-Time Monitoring

A trading desk needs second-by-second visibility for a specific hour:

1. Derive the full chain down to the hourly TVK
2. Share the hourly TVK
3. Recipient can derive minute and second TVKs within that hour
4. Cannot see any other hour

Derivation Diagram

Security Properties of TVK Derivation

---

Auditor Delegation

Users can share viewing access at various granularity levels:

Important: Once a key is shared, it cannot be revoked. The recipient permanently has access to that time scope. Share the minimum scope necessary.

Non-Repudiation

The inability to revoke shared keys provides non-repudiation:

• If you share a TVK with an auditor, you cannot later deny having shared it
• The auditor can prove they received legitimate viewing access
• This creates accountability for both parties

---

Key Generation

The Master Viewing Key can be generated randomly or derived deterministically from a master seed. Both approaches are valid as long as the key is exactly 252 bits and cryptographically secure.

All Umbra keys (MVK, Shielded Spending Key, L1 Keypair, and X25519 Keypair) can either be derived from a single master seed or managed as fully independent keys.

---

MPC Integration

The MVK is bound into the User Commitment Tree-the same tree-based structure described previously that cryptographically binds the L1 Key, Shielded Spending Key, and MVK together into a single commitment.

When registering the User Commitment on-chain, the user also registers a Rescue Cipher encrypted version of the MVK. This encrypted MVK is stored alongside the commitment and provides the Arcium MPC network with access to the viewing key for regulatory compliance purposes.

This design ensures:

---

Summary