Key Architecture Overview

The Umbra Protocol uses a four-key cryptographic model that decouples transaction authority into distinct layers: L1 Interaction, Confidential Account Visibility, Shielded Spending, and Auditing. This architecture allows users to maintain privacy and spend authority while providing granular, opt-in auditability for compliance or personal tracking.

Unlike standard blockchains where a single public key represents both identity and history, Umbra uses a User Commitment Tree-a unified identity derived from three of the four keypairs (the X25519 Keypair operates independently).

The Four Keys

User Commitment Binding

Three of the four keys are cryptographically bound into a unified shielded identity. The X25519 Keypair operates independently.

---

The Four-Key Model

Every entity interacting with Umbra must generate and manage four distinct keys, each serving a specific cryptographic purpose:

---

Two Domains: Mixer Pool vs. Encrypted Token Accounts

Umbra operates across two distinct privacy domains, each using different keys:

Mixer Pool (Shielded UTXOs)

For anonymous, unlinkable transfers through the unified mixer pool:

Encrypted Token Accounts (ETAs)

For confidential balance storage and direct transfers:

---

Key Independence & Security Model

The four keys in Umbra's architecture can be either fully independent or deterministically derived from a common source. This choice is entirely up to the end users of the protocol and integrating developers, and represents a fundamental tradeoff between two security paradigms:

Two Security Paradigms

Information-Theoretic Security (Random Generation)

When keys are generated independently and randomly, they achieve information-theoretic security. This means that even an adversary with unlimited computational power cannot derive one key from another, because there is simply no mathematical relationship between them.

Characteristics:

• Each key is sampled from a cryptographically secure random number generator (CSPRNG)
• No key can be computed from any other key, regardless of computational resources
• Compromise of one key provides zero information about the others
• Provides the strongest possible independence guarantee

Tradeoffs:

• Each key must be stored and backed up separately
• Loss of any key's backup means permanent loss of that key's functionality
• More complex key management (4+ separate secrets to secure)
• No single point of recovery

Cryptographic Security (Deterministic Derivation)

When keys are deterministically derived from a single master seed, they achieve cryptographic security. This means that deriving one key from another is computationally infeasible-it would require breaking the underlying cryptographic assumptions (e.g., the security of KMAC-256 or the discrete logarithm problem).

Characteristics:

• All keys are derived from a single master seed using domain-separated key derivation functions
• Keys are computationally independent: deriving one from another requires breaking cryptographic assumptions
• Single backup (the master seed) enables recovery of all keys
• Practical security equivalent to information-theoretic security against realistic adversaries

Tradeoffs:

• Compromise of the master seed compromises all derived keys
• Single point of failure for backups (but also single point of recovery)
• Relies on the security of the key derivation function (e.g., KMAC-256)
• Simpler key management (1 seed to secure)

Comparison of Approaches

Protocol Requirements

Regardless of which approach is chosen, each key must satisfy its specific validity conditions:

The protocol does not care how these conditions are met-only that they are met. Users can generate keys randomly, derive them deterministically, use hardware security modules, implement threshold schemes, or any combination thereof.

Hybrid Approaches

Advanced users may choose hybrid strategies that combine both paradigms:

Example 1: Isolated Spending Key

• Derive L1, X25519, and MVK from a master seed (convenience)
• Generate Spending Key randomly and store separately (maximum spending security)
• Rationale: The spending key is the most critical; isolating it limits blast radius

Example 2: Hardware-Backed Critical Keys

• Store L1 and Spending Key in hardware security module (HSM)
• Derive X25519 and MVK from software seed (acceptable for view-only)
• Rationale: Hardware isolation for keys that control funds

Example 3: Threshold Rescue Key for DAOs

• Derive L1, Spending Key, and MVK deterministically per user
• Use Distributed Key Generation (DKG) for shared X25519 Key
• Rationale: DAO treasury visibility requires quorum, but individual spending is personal

Blinding Factors

The blinding factors used in the User Commitment Tree follow the same independence model:

• Random blinding factors provide information-theoretic hiding of the underlying keys
• Derived blinding factors provide cryptographic hiding and are recoverable from the master seed

Both approaches produce a secure User Commitment. The Umbra SDK uses derived blinding factors for ease of backup and recovery, but users requiring maximum theoretical security can generate them randomly.

---

Compromise & Loss Scenarios

The consequences of key compromise or loss differ dramatically based on whether keys were generated independently (information-theoretic security) or derived from a master seed (cryptographic security). This section provides detailed analysis of each scenario.

---

Scenario Analysis: Deterministic Derivation

When all keys are derived from a single master seed, security events follow a correlated pattern.

Master Seed Compromise

What happens: An attacker gains access to the master seed (e.g., via phishing, malware, physical theft, or backup breach).

Immediate consequences:

Attack timeline:

1. Attacker derives all four keys from the compromised seed
2. Attacker drains ETAs via L1 key (immediate, visible on L1 chain)
3. Attacker spends mixer UTXOs via Spending Key (requires generating ZK proofs)
4. Attacker decrypts all historical and future transaction data via MVK
5. Complete loss of funds and privacy

Mitigation after detection:

• No recovery possible for already-stolen funds
• Immediately move any remaining funds to a new identity with fresh seed
• Assume all historical transaction privacy is permanently compromised

Individual Derived Key Exposure

What happens: An attacker gains access to a single derived key (not the master seed itself).

L1 Interaction Key compromised (derived):

Shielded Spending Key compromised (derived):

Master Viewing Key compromised (derived):

X25519 Keypair compromised (derived):

Master Seed Loss (Deterministic)

What happens: User loses access to the master seed (hardware failure, forgotten password, lost backup).

If no individual key backups exist:

Critical insight: In deterministic derivation, losing the master seed is equivalent to losing ALL keys simultaneously. This is both the greatest risk and the simplest recovery model-everything depends on one secret.

Mitigation strategies:

• Geographic distribution of seed backups
• Hardware security modules with backup procedures
• Multi-signature custody for institutional users
• Regular verification that backups are recoverable

---

Scenario Analysis: Independent Random Generation

When each key is generated independently, security events are isolated but recovery is more complex.

Individual Key Compromise (Independent)

L1 Interaction Key compromised (independent):

Shielded Spending Key compromised (independent):

Master Viewing Key compromised (independent):

X25519 Keypair compromised (independent):

Key advantage of independent generation: Each compromise is perfectly isolated. An attacker who obtains your MVK learns absolutely nothing about your Spending Key or L1 key-not even probabilistically.

Individual Key Loss (Independent)

L1 Interaction Key lost (independent):

Shielded Spending Key lost (independent):

Master Viewing Key lost (independent):

X25519 Keypair lost (independent):

Key risk of independent generation: Each key loss is also isolated. Losing your Spending Key backup means mixer funds are gone forever, even if all other keys are perfectly secure.

Multiple Key Loss (Independent)

With independent generation, losing multiple keys compounds consequences:

---

Comparative Summary

---

Unified Identity: The User Commitment

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 together.

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

For detailed information on the tree structure and construction, see User Commitment Tree.

---

Key Rotation

Key rotation is not currently supported for keys in the User Commitment. Once a User Commitment is created and UTXOs are associated with it, the underlying keys cannot be changed. Users who require new keys must:

1. Spend all existing mixer UTXOs to a new User Commitment
2. Generate a fresh set of keys
3. Create a new User Commitment from the new keys

The X25519 Keypair, being independent of the commitment, could theoretically be rotated with ETA re-encryption, though this is not currently a supported protocol operation.