User Commitment Registration
Registering your User Commitment to enable mixer pool interactions and receive anonymous UTXOs
To interact with the Unified Mixer Pool-depositing funds, receiving UTXOs, or spending shielded assets-you must register your User Commitment on-chain. This commitment serves as your anonymous identity within the mixer ecosystem.
What is a User Commitment?
The User Commitment is a cryptographic hash that binds together three of your four keys:
- L1 Interaction Key - Your Solana address (Ed25519)
- Shielded Spending Key - BN254 scalar for ZK proofs
- Master Viewing Key - 252-bit key for auditability
The commitment is the root hash of a Poseidon Merkle tree constructed from these keys and their blinding factors. For full technical details, see User Commitment Tree.
Why Registration is Required
When someone creates a UTXO for you in the mixer pool, they set the unlocking address to your User Commitment. Without registration:
- Senders cannot look up your commitment
- You cannot receive UTXOs from others
- You are limited to self-deposits only
Registration creates an on-chain mapping from your L1 address to your User Commitment, enabling others to send you anonymous transfers.
What Gets Registered
| Field | Description |
|---|---|
| User Commitment | The root hash of your User Commitment Tree (single field element) |
| Associated L1 Address | The Solana address this commitment is registered under |
Note: The underlying keys (L1, Spending Key, MVK) and blinding factors are never revealed during registration. Only the final commitment hash is stored on-chain.
Registration Process
Step 1: Generate Your Keys
Ensure you have all three keys required for the commitment:
| Key | Generation |
|---|---|
| L1 Interaction Key | Your Solana wallet keypair |
| Shielded Spending Key | BN254 scalar (random or derived) |
| Master Viewing Key | 252-bit integer (random or derived) |
Plus the blinding factors for the Spending Key and MVK.
Step 2: Compute Your User Commitment
Construct the Poseidon Merkle tree and compute the root:
For the complete algorithm, see User Commitment Tree.
Step 3: Submit Registration Transaction
Call the RegisterUserCommitment instruction:
Step 4: Verification
After registration, your User Commitment is stored on-chain and can be queried by anyone knowing your L1 address.
Capabilities Unlocked
Once your User Commitment is registered, you gain the following capabilities:
| Capability | Description |
|---|---|
| Receive UTXOs | Others can create UTXOs with your commitment as the unlocking address |
| Deposit to Mixer | Create UTXOs for yourself or others |
| Spend UTXOs | Burn UTXOs that have your commitment as the unlocking address |
| Anonymous Transfers | Full mixer functionality with unlinkable transactions |
What You Still Need
User Commitment registration alone enables mixer interactions, but for full Umbra functionality you also need:
| Capability | Required Registration |
|---|---|
| ETA visibility | X25519 Registration |
| Receive confidential transfers | X25519 Registration |
| Decrypt ETA balances | X25519 Registration |
Binding to L1 Address
The commitment itself contains a hash of your L1 address (Hash 1 in the tree structure). This creates a cryptographic binding:
- The on-chain record links L1 → Commitment
- The commitment internally links back to L1
- This bidirectional binding prevents commitment substitution attacks
Security Considerations
Key Material Protection
| Component | Sensitivity | If Compromised |
|---|---|---|
| User Commitment | Public | No impact (it's meant to be public) |
| Spending Key | Critical | Attacker can spend your mixer UTXOs |
| MVK | Sensitive | Attacker can view your transaction history |
| Blinding Factors | Critical | Required to reconstruct commitment for ZK proofs |
Spending Key Security
The Shielded Spending Key is the most critical component. Unlike the L1 key (which only controls ETAs), the Spending Key controls all your mixer funds. Recommendations:
| Practice | Rationale |
|---|---|
| Hardware storage | Isolate from network-connected devices |
| Independent generation | Consider generating separately from other keys |
| Secure backup | Loss means permanent loss of mixer funds |
Immutability
Key rotation is not supported. Once a User Commitment is registered and UTXOs are associated with it, the underlying keys cannot be changed. To use new keys:
- Spend all existing UTXOs to a new commitment
- Generate fresh keys
- Compute and register a new User Commitment
Relationship to X25519 Registration
User Commitment registration is independent from X25519 registration:
Registration Order
There is no required order-you can register either one first, or both in the same transaction batch:
| Order | Use Case |
|---|---|
| X25519 first | User wants confidential transfers before mixer |
| Commitment first | User wants mixer anonymity before ETAs |
| Both together | User wants full functionality immediately |
The 1:1 Binding
Important: A single L1 address can only have one User Commitment. This is enforced at multiple levels:
| Level | Enforcement |
|---|---|
| On-Chain | Only one commitment can be registered per L1 address |
| Cryptographic | L1 address is hashed into the commitment structure |
| Protocol | Attempting to register a second commitment will fail |
To maintain multiple shielded identities, you need separate L1 addresses for each.
Summary
| Aspect | Details |
|---|---|
| Purpose | Enable mixer pool interactions and receiving UTXOs |
| What's Registered | User Commitment hash (root of Poseidon tree) |
| Components Bound | L1 Key + Spending Key + MVK + Blinding Factors |
| Enables | Mixer deposits, receiving UTXOs, spending UTXOs |
| Does Not Enable | ETA visibility (requires X25519) |
| Key Rotation | Not supported-must migrate to new commitment |
| Multiple Identities | Requires separate L1 addresses |
X25519 Public Key Registration
Registering your X25519 public key to enable encrypted token account visibility and receive confidential transfers
Confidential-Only Transfers
Execute direct encrypted transfers between Encrypted Token Accounts (ETAs) or to public ATAs without using the mixer pool for fast confidential payments.