> For AI agents: the documentation index is at https://docs.umbraprivacy.com/llms.txt, and every page is available as Markdown at its URL with .md appended.

# Your keys (/docs/account/keys)

> **Umbra's clients, not the protocol**
>
> What each key does is fixed by the circuits: the proofs check how the spending, nullifier and viewing keys relate to your identity commitment and notes. How the keys are produced is not. The hierarchy on this page, from one signature through HKDF, BIP-39 and SLIP-0010, is the standard Umbra's clients follow, and another client could produce the same kinds of keys another way.

Every long-lived key you use in Umbra is derived from your account signature, and none is stored anywhere that signature cannot rebuild it from. Some stay on your device, one is split among the guardian nodes, and one is public by design.

- Account signature
  - Wallet seed: BIP-39 seed of the platform wallet's 24-word phrase
    - Platform wallet: Solana keypair, signs binding, registration and deposits
    - Journal key: local note store only
    - Identity master secret: bound to the platform wallet
      - Spending key: slot 0
      - Nullifier key: slot 1, makes each note's nullifier
      - Outgoing viewing key: slot 2, shared two of three with the guardian nodes
        - Per-transaction viewing key: one per transaction, also shared two of three
        - Transaction blinding key: note blindings and encryption randomness
      - Proof-authorisation key: slot 3, reserved
      - Eight slot blinders: one per identity slot
      - ML-KEM-768 keypair: public key published, its hash in slot 6

*The key hierarchy. The wallet seed is a BIP-39 seed and the platform wallet a SLIP-0010 derivation of it; every other value is an HKDF expansion of its parent under its own label, or a Poseidon hash for the per-transaction keys.*

Each key below has its own section: what it is for, where it is used, and who else can hold it. A comparison of what a leak of each would cost closes the page. Every value comes from the signature, so in practice the risk is a leak of the signature itself, which gives away all of them at once. See [the account signature](https://docs.umbraprivacy.com/docs/account/account-signature).

## Spending authority

No key signs a spend. To spend a note, the transaction proof shows that the prover knows the opening of an identity commitment in the pool's identity tree: the spending key, nullifier key and outgoing viewing key with their blinders, and the five other slot leaves. The note's owner field must be that commitment. Authority is knowledge of the whole opening.

The spending key has no other job. It is committed at registration, forced non-zero, and reappears only inside spend proofs.

## Nullifier key

When a note is spent, the proof publishes its nullifier, a Poseidon hash of the note's position in the tree and its nullifier blinding factor, with your nullifier key as the hash's initial state. The chain refuses a nullifier it has seen before, which is how double spends are stopped. See [nullifiers](https://docs.umbraprivacy.com/docs/state/nullifiers).

Without the key, nobody can link a nullifier to a note, even someone who knows the note's contents. The sender of a note knows its position and blinding factor, so a leaked nullifier key is what would let a sender watch for the moment you spend it.

## Outgoing viewing key

At registration your device splits your outgoing viewing key into three shares with a two-of-three Shamir split and sends one to each guardian node, and the registration proof shows the shares are of the same key that sits in slot 2. See [secret sharing](https://docs.umbraprivacy.com/docs/cryptography/secret-sharing).

From it, and from each transaction's three nullifiers and a random value published in the transaction, your device derives, among others, two keys per transaction under different hash domains:

- the **per-transaction viewing key**, which encrypts the transaction's sender record;
- the **transaction blinding key**, from which the note blindings, the encryption nonces and the randomness used to encrypt each new note to its recipient are squeezed.

Anyone holding your outgoing viewing key can therefore re-derive both, read every sender record you wrote and reproduce the encryption of every note you created. It cannot be used to spend: the spending key, nullifier key and blinders are never shared.

## Per-transaction viewing key

A per-transaction viewing key belongs to one transaction. The transaction proof splits it two of three among the guardian nodes. The record lists the sender's identity commitment, the token and amount of each spent note, and the owner, token and amount of each new note.

The random value in the derivation must never repeat for the same nullifiers, because the record's encryption is additive and two records under one key would expose the difference between them. The SDK records the value in its local outbox before it proves, so one transaction is never given two.

## Proof-authorisation key

Slot 3 holds a proof-authorisation key. The registration proof requires it to be non-zero, and transaction proofs carry its slot leaf without opening it. No current circuit uses the key itself.

## The encryption keypair

Your ML-KEM-768 keypair is derived from a 64-byte expansion of the identity master secret through FIPS 203 key generation, so it is as recoverable as everything else. At registration, the data endorser receives the 1,184-byte public key, checks that its Keccak-256 hash matches the hash in the registration payload, and archives it. The registration proof binds that same hash into slot 6 of your identity commitment. Senders fetch the public key from the archive to encrypt notes to you. See [receiving payments](https://docs.umbraprivacy.com/docs/account/receiving).

## Blinders

Each of the eight identity slots is hashed together with its own blinder, derived from the identity master secret under a separate label rather than from the key it covers. A party shown one slot's value and blinder cannot use them to test guesses about any other slot. The registration proof requires the blinders of slots 4 to 7 to be non-zero; the keys in slots 0 to 3 are forced non-zero directly.

## Journal key

The journal key is a 256-bit AES-GCM key, drawn from the wallet seed under its own purpose, `note-journal`, that encrypts your device's local note store. The store holds each note's blinding factors, which the note's sender chose and nothing else reproduces, so the key has to come back from the signature like everything else: a store sealed under a key the wallet could not derive again would be readable only after a full rescan. It never leaves the device and has no role on chain.

## Platform wallet key

The platform wallet's private key is a Solana Ed25519 key, derived from the wallet seed along Solana's SLIP-0010 path. The identity master secret is derived after it and binds its public key, so every identity key belongs to that one platform wallet. It signs the bind in the user registry, your registration and your deposits, and nothing else; a relayed transfer or withdrawal carries no signature from it. Whoever holds it controls the address, including any tokens or lamports left there between a funding and a deposit. See [the platform wallet](https://docs.umbraprivacy.com/docs/account/platform-wallet).

## What a leak of each would cost

The table shows what each key would give away if it leaked on its own.

| Key                         | If it leaks                                                                             |
| --------------------------- | --------------------------------------------------------------------------------------- |
| Spending key                | Not enough to spend alone, but one of the values that let a thief spend                 |
| Nullifier key               | Anyone who also knows a note's contents, such as its sender, can tell when you spend it |
| Outgoing viewing key        | Your whole sending history, and the contents of every note you created                  |
| Per-transaction viewing key | That transaction's sender record: its sender, recipients, tokens and amounts            |
| Proof-authorisation key     | Nothing today                                                                           |
| Slot blinders               | Needed, with the keys, to spend; on their own they reveal nothing                       |
| ML-KEM-768 secret key       | Every note sent to you, past and future                                                 |
| ML-KEM-768 public key       | Nothing; it is meant to be public                                                       |
| Journal key                 | Whatever is in that device's store                                                      |
| Platform wallet key         | Control of the address, including anything left in it                                   |

## Related

- [Your identity commitment](https://docs.umbraprivacy.com/docs/account/identity): How the keys fold into one public value.
- [Encryption](https://docs.umbraprivacy.com/docs/cryptography/encryption): Note encryption and the sender record.
- [Secret sharing](https://docs.umbraprivacy.com/docs/cryptography/secret-sharing): The two-of-three split of viewing keys.
- [Recovery](https://docs.umbraprivacy.com/docs/account/recovery): What comes back, and from where.


Last updated 12 October 2026