> 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.

# Receiving payments (/docs/account/receiving)

> **Umbra's clients, not the protocol**
>
> Looking up a recipient's identity commitment and encryption key from their main wallet address is a service Umbra's clients use, not a protocol rule. The pool needs only a note committed to the recipient's identity commitment; how a sender learns that commitment and the key to encrypt to is up to the client.

There is no separate Umbra address. Someone pays you by naming your main wallet address, and the protocol resolves it, through public records, to the identity commitment your notes are made out to and the encryption key they are encrypted to.

## The resolution chain

1. Main wallet address: what the sender types
2. Latest bind: user registry
3. Platform wallet
4. Registration: signed by that platform wallet
5. Identity commitment: and its leaf in the identity tree
6. Encryption public key: from the data endorser's archive

*Every link is public. The indexer's context service walks the chain for the sender in one request.*

1. **Latest bind.** The context service finds the main wallet's most recent successful `bind_platform_wallet` that ran at the top level of its transaction, in a slot that was not abandoned. A later bind replaces an earlier one.
2. **Registration.** It finds the successful `register` instruction whose bound wallet is that platform wallet, and reads the identity commitment from it.
3. **Leaf.** It looks up the commitment's leaf in the identity tree of the pool index the sender is using, and returns a Merkle path to it. The transaction proof uses that path to show the recipient is registered.
4. **Encryption key.** It returns your ML-KEM-768 public key from the data endorser's archive of your registration, with the key hash your registration payload carried.

The sender's device encrypts each new note to that key. See [encryption](https://docs.umbraprivacy.com/docs/cryptography/encryption).

The chain can also start from an identity commitment instead of a wallet, which is how the service resolves the sender's own identity for the same request.

### When resolution fails

The context service answers with one of four refusals when the chain does not lead cleanly from a wallet to a key. Each one stops the payment before the sender's device spends any time on a proof.

**Unregistered.** No bind names that main wallet, or the platform wallet it names never registered. The service treats this as permanent until the recipient registers, and there is nothing a sender can do in the meantime.

**Not yet provable.** The recipient is registered, but the indexer has not yet mirrored the identity tree up to their leaf, so it has no Merkle path to return. The leaf is on chain already; retrying a few slots later finds it.

**Ambiguous.** The platform wallet has registered more than one identity commitment. Nothing on chain stops this, because registration refuses a repeated commitment, not a repeated wallet. The service will not choose between them, and the transaction endpoint names a recipient only by wallet address, so that address cannot be paid through it.

**Key missing.** The commitment is in the identity tree, but no archived registration carries its encryption public key. The chain stores only the key's hash, so there is nothing to encrypt a note to, and the payment cannot be made.

## What can be checked

Everything a sender relies on here is public except the encryption key itself, which the chain never stores.

- The bind and the registration are ordinary transactions anyone can read.
- The registration proof binds the Keccak-256 hash of your encryption public key into slot 6 of your identity commitment, and the same hash is in the registration payload on chain. A sender can hash the key the service returns and compare it with that payload.
- The data endorser checked the same hash before it signed your registration, and the pool would not have accepted the registration without that signature.

## Checking whether someone is registered

Anyone can check from chain data alone: find the address's latest bind, then look for a successful registration signed by the platform wallet it names. The context service answers the same question for an identity commitment. Registration is permanent, so a positive answer stays true.

## Notes owned by a Solana address

A note can also be owned by a Solana address instead of an identity, including a program-derived address. These program-owned notes differ from ordinary ones in three ways.

- **The owner is the address.** The note's owner field is a Poseidon hash of the address's two halves, which anyone can compute. The address does not need to be registered.
- **Spending needs the address's signature.** The pool accepts a spend of a program-owned note only if the owning address signs the transaction; a program-derived address signs through its program. The transaction is still built by a registered identity, because every transaction proves its sender is in the identity tree.
- **Spends are linkable.** The nullifier of a program-owned note is keyed by that public owner hash, not by a private nullifier key. Anyone who knows the note's contents, such as whoever created it, can compute its nullifier and see when it is spent.

The wallet sync described in these pages handles identity-owned notes only, and Umbra's relayer refuses program-owned spends, so the owner submits them itself.

## Related

- [The platform wallet](https://docs.umbraprivacy.com/docs/account/platform-wallet): The bind that starts the chain.
- [Receive and sync](https://docs.umbraprivacy.com/docs/operations/receive-and-sync): Finding the notes once they are sent.
- [Private transfer (Private Send)](https://docs.umbraprivacy.com/docs/operations/private-send): The transaction that pays you.


Last updated 12 October 2026