Umbra PrivacyUnlocking Address Strategies
Choosing between registered commitments and ephemeral keys when creating UTXOs for different recipients
When creating a UTXO in the Unified Mixer Pool, you must set an unlocking address-the User Commitment that determines who can spend the UTXO. Your strategy depends on whether the recipient is registered with Umbra.
The Two Strategies
| Strategy | When to Use | Who Burns |
|---|---|---|
| Registered Commitment | Recipient has registered their User Commitment | Recipient |
| Ephemeral Keys | Recipient is not registered with Umbra | Sender |
Strategy 1: Registered Commitment (Maximum Anonymity)
When the recipient has registered their User Commitment, you can use it directly as the unlocking address.
How It Works
UTXO Fields
| Field | Value |
|---|---|
| Unlocking Address | Recipient's registered User Commitment |
| Destination Address | Recipient's L1 address |
Who Does What
| Actor | Actions |
|---|---|
| Sender | Creates UTXO, funds deposit |
| Recipient | Waits for mixing delay, generates ZK proof, burns UTXO |
Privacy Analysis
| Aspect | Privacy Level |
|---|---|
| Sender Anonymity | Maximum-recipient doesn't know who sent |
| Recipient Anonymity | Maximum-part of full anonymity set |
| Amount Privacy | Depends on deposit source (ATA vs ETA) |
| Link Breaking | Complete-no correlation possible |
Why This Is Preferred
| Advantage | Explanation |
|---|---|
| Full Anonymity Set | Recipient's withdrawal is indistinguishable from all other burns |
| Sender Privacy | Sender doesn't need to reveal themselves |
| Timing Freedom | Recipient chooses when to withdraw |
| Self-Custody | Recipient controls their own keys |
Strategy 2: Ephemeral Keys (Non-Registered Recipients)
When the recipient hasn't registered with Umbra, you can still send them funds using ephemeral keys-a temporary set of keys you generate specifically for this UTXO.
How It Works
Ephemeral Keys Generated
You generate a complete set of keys for the ephemeral commitment:
| Key | Purpose |
|---|---|
| Ephemeral L1 Key | Part of commitment hash (can be recipient's L1) |
| Ephemeral Spending Key | Required for ZK proof generation |
| Ephemeral MVK | Required for commitment construction |
| Blinding Factors | Required for commitment computation |
UTXO Fields
| Field | Value |
|---|---|
| Unlocking Address | Ephemeral User Commitment (you control) |
| Destination Address | Recipient's L1 address |
Who Does What
| Actor | Actions |
|---|---|
| Sender | Generates ephemeral keys, creates UTXO, waits for delay, burns UTXO |
| Recipient | Nothing-funds arrive at their ATA or ETA |
The Burn Process
Since you hold the ephemeral keys, you can generate the ZK proof and burn the UTXO:
Comparison of Strategies
| Aspect | Registered Commitment | Ephemeral Keys |
|---|---|---|
| Recipient Setup | Must be registered | No setup required |
| Who Burns | Recipient | Sender |
| Recipient's Action | Must generate proof and burn | None (passive receipt) |
| Sender Privacy | Maximum | Sender knows the link |
| Recipient Anonymity | Full anonymity set | Reduced (sender knows) |
| Timing Control | Recipient chooses | Sender controls |
| Key Custody | Recipient controls keys | Sender controls ephemeral keys |
| Complexity | Lower for sender | Higher for sender |
When to Use Ephemeral Keys
Use Case 1: Onboarding New Users
Send funds to someone who hasn't joined Umbra yet:
The recipient doesn't need to understand Umbra-they just receive tokens in their regular Solana wallet.
Use Case 2: One-Time Payments
For single payments where the recipient won't use Umbra regularly:
| Scenario | Strategy |
|---|---|
| Paying a merchant | Ephemeral keys → burn to their ATA |
| Refund to customer | Ephemeral keys → burn to their wallet |
| Gift to friend | Ephemeral keys → burn to their address |
Use Case 3: Automated Payments
Systems that need to distribute funds programmatically:
Privacy Considerations
Ephemeral Key Limitations
When using ephemeral keys, be aware of reduced privacy:
| Limitation | Explanation |
|---|---|
| Sender Knows Link | You created the UTXO and burned it-you know the connection |
| Timing Correlation | If you burn immediately after delay, timing narrows candidates |
| Amount Knowledge | You know exactly what the recipient received |
Mitigations
| Mitigation | How It Helps |
|---|---|
| Encourage Registration | Ask recipients to register for future payments |
| Variable Timing | Wait random time beyond minimum delay |
| Batch Burns | Burn multiple UTXOs in one transaction to obfuscate |
Trust Model
| Strategy | Trust Required |
|---|---|
| Registered Commitment | No trust-recipient controls everything |
| Ephemeral Keys | Recipient trusts sender to burn and not keep records |
Destination Address Options
Regardless of which strategy you use, the destination address determines where funds go when burned:
Burn to ATA (Public)
| Aspect | Details |
|---|---|
| Amount | Visible on-chain after burn |
| Recipient Address | Visible |
| Best For | Non-Umbra users, off-ramping |
Burn to ETA (Confidential)
| Aspect | Details |
|---|---|
| Amount | Stays hidden (encrypted) |
| Recipient Address | Visible |
| Requirement | Recipient must have X25519 registered |
| Best For | Continued confidentiality |
Complete Flow Examples
Example 1: Sending to Registered User
Alice wants to send 100 USDC to Bob, who is registered:
Privacy Result: Maximum anonymity for both parties.
Example 2: Sending to Non-Registered User
Alice wants to send 100 USDC to Carol, who isn't registered:
Privacy Result: Carol receives anonymous funds, but Alice knows the connection.
Example 3: Onboarding with Future Registration
Alice sends to David, expecting him to register later:
Implementation Considerations
Ephemeral Key Storage
When using ephemeral keys, you must store them until the burn is complete:
| What to Store | Why |
|---|---|
| Ephemeral Spending Key | Required for ZK proof |
| Ephemeral MVK | Required for commitment reconstruction |
| Blinding Factors | Required for ZK proof |
| UTXO Data | Required for proof generation |
After burning, you can discard the ephemeral keys.
Automation
For systems making many payments:
For automated systems, the flow involves generating ephemeral keys, computing the ephemeral commitment, creating the UTXO with that commitment as the unlocking address, storing the ephemeral keys securely, and scheduling the burn after the mixing delay.
Summary
| Aspect | Registered Commitment | Ephemeral Keys |
|---|---|---|
| Best For | Maximum privacy, registered users | Non-registered recipients, onboarding |
| Who Burns | Recipient | Sender |
| Anonymity | Full | Reduced (sender knows link) |
| Recipient Action | Must burn themselves | None required |
| Complexity | Simple | More complex (key management) |
| Recommendation | Preferred when possible | Fallback for non-registered |
Decision Flowchart
Burning UTXOs to Encrypted Balance
Learn how to withdraw funds from Umbra's Unified Mixer Pool to an Encrypted Token Account (ETA) while maintaining full transaction privacy and anonymity.
MPC Threat Model
Understand Umbra's dishonest majority security model powered by Arcium's Cerberus MPC protocol for secure encrypted balance operations and verification.