Your identity commitment
The single public value that stands for you in the shielded pool, the eight slots it commits to, where it is stored and what it reveals.
Umbra's clients, not the protocol
The identity commitment's eight slots are fixed by the registration circuit, so every client must fill them the same way. Where the values in those slots come from, such as keys derived from a wallet signature, is up to the client; this page describes what Umbra's clients do.
Your identity commitment (sometimes called the user commitment) is one BN254 field element that commits to your keys, your platform wallet and your encryption key. It is public from the moment you register, it owns every note you hold, and it never appears in a transaction afterwards.
The eight slots
Each slot is hashed with its own blinder into a slot leaf, and the eight leaves are hashed into the commitment. Both hashes are Poseidon in the circuit-only form, with a distinct domain per slot (42 to 49) and for the root (50), so no leaf can stand in for another.
The table compares the eight slots on what each holds, what the registration proof checks about it, and whether a transaction proof opens it. A slot that is not opened is carried into the proof as its finished leaf, so the proof can rebuild the commitment without learning what is inside.
| Slot | Holds | Checked at registration | Opened in a spend |
|---|---|---|---|
| 0 | Spending key | Key non-zero | Yes, privately |
| 1 | Nullifier key | Key non-zero | Yes, privately |
| 2 | Outgoing viewing key | Key non-zero; shared two of three with the guardian nodes | Yes, privately |
| 3 | Proof-authorisation key | Key non-zero | No; its leaf is carried as is |
| 4 | Platform wallet address, as two 128-bit halves | Blinder non-zero; the address is a public input and must have signed | Yes, privately, for the self-transfer fee rate |
| 5 | Retired (fixed at zero) | Blinder non-zero | No |
| 6 | Hash of your ML-KEM-768 public key, as two halves | Blinder non-zero; the hash is a public input | No |
| 7 | Reserved (fixed at zero) | Blinder non-zero | No |
Slot 5 is named for a guardian-cluster binding it no longer carries, and holds zero. Slots 5 and 7 still take a non-zero blinder, so their leaves are as unpredictable as the others.
The fold below shows how the eight slot leaves become one commitment.
Where it lives
Registration appends your commitment, as it is, to the shielded pool's identity tree. The identity tree belongs to the pool program, not to the user registry, and there is one per pool index; the SDK registers in pool index 0 unless told otherwise. It has the same shape as the note tree, levels of eight children with a top level of four, for 232 leaves, and it remembers its 512 most recent roots.
A second structure, the registration staging buffer and the indexed tree behind it, records which commitments have been registered so the same one cannot be added twice. See register.
What it is used for
- It owns your notes. An identity-owned note's owner field is your identity commitment. The owner field is not in the encrypted note; you supply it when you open the note, because it is yourself.
- Every value transaction proves the sender is registered. The transaction proof rebuilds the sender's commitment from the keys it opens and shows it is a leaf of the identity tree, against a root the program checks is one of the tree's recent 512.
- You can only pay registered identities. Every identity-owned output's owner must also be a leaf of the identity tree. A note cannot be created for a commitment that was never registered.
- Senders find you through it. The indexer resolves your main wallet to your commitment and your encryption public key. See receiving payments.
What it reveals
The commitment itself reveals nothing about your keys. The links around it are public:
- The register transaction carries the commitment, the hash of your encryption public key and your platform wallet as a signer. With the user registry's bind, that ties your commitment to your main wallet for anyone who reads the chain.
- Your leaf position in the identity tree, and the slot you registered at, are public.
Inside value transactions, the sender's commitment and every output's owner are private inputs to the proof. A chain observer sees neither. A deposit is the exception in practice: its depositor, your platform wallet, is public, and the platform wallet is linked to your commitment.
Related
Last updated
Your keys
Every key derived from your account signature, what each one does in the protocol, who else holds it, and what a leak of each would cost.
Receiving payments
How a sender turns your main wallet address into an identity commitment and an encryption key, what can be checked along the way, and how notes owned by a Solana address differ.