User Commitment Tree

Overview

In Umbra, a user's Shielded Address is not a public key-it is the Root Hash of a deterministic Merkle Tree known as the User Commitment. This structure cryptographically binds three of the four keys (L1 Interaction, Shielded Spending, and Master Viewing) together, ensuring that no funds can be held in the pool without a valid, recoverable audit trail.

The User Commitment serves as the user's identity within the shielded pool, appearing in UTXOs as the Unlocking Address.

Note: The X25519 Keypair is intentionally excluded from the User Commitment Tree. It operates independently for Encrypted Token Account visibility and MPC communication.

---

Tree Structure

The commitment is derived via a 3-level Poseidon hash tree with carefully structured leaves and intermediate nodes.

Visual Representation

---

Construction Algorithm

Level 1: Leaf Hashes

Three leaf hashes are computed from the raw key material:

Hash 1 - L1 Address Hash:

The 32-byte L1 public key is split into two 128-bit field elements:

$$\text{Hash}_1 = \text{Poseidon}([\text{UserAddress}_{\text{low}}, \text{UserAddress}_{\text{high}}])$$

Hash 2 - Auditing Hash:

The Master Viewing Key is hashed with its blinding factor:

$$\text{Hash}_2 = \text{Poseidon}([MVK, MVK_{\text{blinding}}])$$

Hash 3 - Spending Hash:

The Shielded Spending Key is hashed with its blinding factor:

$$\text{Hash}_3 = \text{Poseidon}([\text{SpendingKey}, \text{SpendingKey}_{\text{blinding}}])$$

Level 2: Intermediate Hash

The shielded secrets (auditing and spending) are combined:

$$\text{Hash}_4 = \text{Poseidon}([\text{Hash}_2, \text{Hash}_3])$$

Level 3: Root (User Commitment)

The final commitment combines the L1 address hash with the shielded secrets hash:

$$\text{UserCommitment} = \text{Poseidon}([\text{Hash}_1, \text{Hash}_4])$$

---

Blinding Factors

Both the MVK and Spending Key are hashed with blinding factors before inclusion in the tree.

Purpose

Generation Options

The Umbra SDK implements cryptographic derivation from the master seed for easier backup and recovery.

Storage Requirement

Critical: The blinding factors must be stored/recoverable. Without them, the User Commitment cannot be reconstructed, and UTXOs cannot be spent.

---

Usage in UTXOs

When a UTXO is created in the Unified Mixer Pool, it contains an Unlocking Address-which is the User Commitment. The User Commitment is not stored in plaintext; instead, it is hashed into the UTXO's global commitment structure. This means external observers see only the global commitment, while the User Commitment remains hidden within.

---

Spending a UTXO

To spend (burn) a UTXO, the owner must provide a Zero-Knowledge Proof demonstrating knowledge of:

1. The Master Viewing Key and its blinding factor
2. The Shielded Spending Key and its blinding factor
3. The L1 Address components
4. The correct reconstruction path to the User Commitment

What the Proof Demonstrates

---

Security Properties

Binding Property

The User Commitment cryptographically binds all three keys:

• No Key Substitution: Cannot substitute one key while keeping others
• Tamper Evidence: Any modification produces a different commitment
• Unique Identity: Each key combination produces a unique commitment

Hiding Property

The Poseidon hash ensures:

• Pre-image Resistance: Cannot derive keys from the commitment
• Second Pre-image Resistance: Cannot find alternative keys for same commitment
• Collision Resistance: Cannot find two key sets with same commitment

Audit Guarantee

The tree structure ensures:

• Recoverable Audit Trail: Every UTXO has an associated MVK for auditability
• Mandatory Compliance Path: Funds cannot exist without a valid viewing key
• Structural Enforcement: The protocol enforces this at the cryptographic level

---

Key Rotation

Key rotation is not currently supported in Umbra.

Why Not?

The User Commitment is deterministically derived from the three keys. Changing any key produces a completely different commitment, which means:

1. Existing UTXOs would point to the old commitment
2. New keys would create a new, unrelated identity
3. No protocol mechanism exists to "migrate" UTXOs between commitments

---

Multiple Identities

A single L1 Interaction Key cannot be associated with multiple User Commitments.

The L1 Address is hashed into Hash 1, which becomes part of the commitment structure. This creates a 1:1 binding between:

• One L1 public key
• One User Commitment

To maintain multiple shielded identities, users would need separate L1 keys for each.

---

Why the X25519 Keypair is Excluded

The X25519 Keypair is intentionally not included in the User Commitment Tree. This design decision provides several benefits:

The X25519 keypair operates in a separate domain:

---

Summary