Everything you own
The objects that make up an Umbra account, where each one lives, who can see it and how it comes back, and what Umbra's infrastructure holds about you.
Umbra's clients, not the protocol
This section describes how Umbra's own applications and SDK set up an account: one wallet signature, the keys derived from it, the platform wallet and the local note store. The protocol enforces none of that. The shielded pool checks proofs, signatures and commitments; it does not check how your keys were made, whether they came from a signature, or which wallet signs for you. Another client can follow its own standard and still use the same pool. Where a page states something the pool or a circuit does enforce, it says so.
An Umbra account, as Umbra's clients build it, is one wallet signature and everything derived from it, plus the notes and records the protocol keeps for you in public, encrypted form. Nothing about it is stored by Umbra in a form that lets anyone spend, and a few pieces are held by Umbra's services in a form that lets them read.
The objects
Eight objects make up an account. The first five are things you hold or can regenerate from your main wallet. The last three are public or archived records the protocol keeps on your behalf, and only your keys make sense of them.
Main wallet
Your own Solana wallet, held in your wallet software or on your device. Umbra does not derive it, hold it or back it up. It signs the account message once on each device, binds itself to your platform wallet in the user registry, and pays the Solana fee for your registration and, in the SDK's default form, for your deposits. Its address is public like any Solana address. It comes back only through your wallet's own backup, and that backup is also the only backup your Umbra account has.
Account signature
One Ed25519 signature by your main wallet over a fixed Umbra message. The app asks for it when it needs your keys and holds it in memory; nothing in the protocol stores it. Every other secret on this page is derived from its 64 bytes, so only you should ever see it. Ed25519 signatures are deterministic, so signing the same message again returns the same bytes, which is how it comes back. See the account signature.
Platform wallet
A Solana keypair derived from the account signature, through a seed your device derives once per session, and re-derived from that seed each time it is needed. It signs the bind in the user registry, your registration and your deposits, so its address is public. The bind publicly links it to your main wallet, and the registration links it to your identity commitment. See the platform wallet.
Identity keys
The spending key, nullifier key, outgoing viewing key and proof-authorisation key, plus eight blinders that hide each slot of your identity commitment. All are re-derived on your device from the account signature, and none is stored anywhere else. At registration your device also splits the outgoing viewing key into shares, one for each guardian node. See your keys.
Encryption keypair
An ML-KEM-768 keypair that senders encrypt your notes to. The secret key is re-derived on your device and decrypts every note sent to you. The public key is archived by the data endorser when you register and served by the indexer to anyone who pays you, which is its purpose; the chain itself carries only its hash.
Identity commitment
Your identity commitment (sometimes called the user commitment) is one hash that commits to your keys, your platform wallet and the hash of your encryption public key. It is the one public value that stands for you inside the protocol. Registration appends it to the shielded pool's identity tree, where it stays permanently, and the registration transaction links it to your platform wallet. It never appears in a transaction afterwards. See your identity commitment.
Notes
The units of your private balance. Each note exists in three places: its commitment in the pool's note tree, which is public; its encrypted contents in the archive the data endorser writes and the indexer serves; and a decrypted copy in your device's local store. Only you and the note's sender, who created it, can read the contents. If your device loses its copy, rescanning the archive finds the note again.
Sender records
Every value transaction you send carries an encrypted summary of what it did: your identity commitment, the token and amount of each note spent, and the owner, token and amount of each note created. It is encrypted under that transaction's per-transaction viewing key and archived beside the notes. You can re-derive the key from your outgoing viewing key.
The local note store
Your device also keeps a local note store, encrypted under a journal key derived from the same signature. It is a cache of what the chain and the archive already hold, so losing it costs a rescan, not funds.
How each comes back
Everything except the main wallet comes back from the account signature or from public records. Sign the message again and the device re-derives the platform wallet, every identity key, the encryption keypair and the journal key, and recomputes the identity commitment. The commitment itself never needs restoring, because the identity tree holds it permanently. Notes and sender records come back by rescanning the archive with the re-derived keys. See recovery.
What controls your funds
Tokens you deposit sit in pool token accounts owned by the shielded pool program, not in any wallet Umbra controls. A note can be spent only by a zero-knowledge proof that its owner knows the opening of the identity commitment the note belongs to, and that opening never leaves your device. The powers governance holds over the program are described in governance and upgrades.
What Umbra's infrastructure holds about you
- One share of your outgoing viewing key per guardian node. Your device splits the key at registration, one share per guardian node. Each node also returns an escrowed copy of its share, sealed under a key derived from that node's own secret, which is kept in write-once storage.
- One share of every per-transaction viewing key. The same split is made in every value transaction.
- Your registration, archived by the data endorser. The archive keeps your ML-KEM-768 public key, the registration payload and the transaction's account list, which includes your main wallet and platform wallet. All of these are public on chain or meant to be served to payers.
- Encrypted notes and sender records. The data endorser archives every encrypted note and every sender record, and the indexer serves them to anyone. Only key holders can open them.
- Screening records. The screener records each screened value transaction, including Private Sends, with its verdict and the modules' replies. It screens the bound submitter of every transaction and any public deposit or withdrawal parties. It does not learn or screen the private recipient.
- What the context service sees when you spend. To build a spend, your device asks the indexer's context service for Merkle paths. That one request carries your identity commitment, the positions of the notes you are spending, their nullifiers and the recipient's wallet address.
- Request metadata. Umbra's services sit behind a gateway, and requests carry an access key and come from your network address. What each service logs is up to its operator.
None of these lets anyone spend. Spending needs the spending key, the nullifier key and the slot blinders, which are never shared.
Sent notes and the outgoing viewing key
Your device derives the randomness it encrypts each new note with from your outgoing viewing key and the transaction's public values. Whoever holds your outgoing viewing key can therefore reproduce the encryption of every note you created and read its full contents, not only the sender record.
Related
Last updated
Security levels and quantum status
How strong each primitive is today, which ones a quantum computer would break, and what an attacker could and could not do if one existed.
The account signature
The single wallet signature every Umbra key is derived from, why signing again recovers the whole account, and the ways it can go wrong.