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

# How privacy is lost (/docs/privacy/leaks)

Umbra's proofs reveal nothing about the notes they spend or create. Privacy is still lost in other ways: through what the protocol makes public on purpose, through the services a transaction passes through, and through patterns across many transactions. This page lists each one with where it comes from.

## What the protocol publishes

### Registration links your wallets to your identity

Registering publishes your identity commitment with your platform wallet as a signer and your main wallet as the fee payer, and the user registry's bind links the two wallets. From then on, anyone can tell that those wallets belong to one Umbra account. See [the platform wallet](https://docs.umbraprivacy.com/docs/account/platform-wallet).

### The public side of deposits and withdrawals

A deposit shows the depositing platform wallet, the token and the amount. Since the platform wallet is tied to your identity, a deposit is attributable to you.

A withdrawal shows the destination, the token and the amount, and not who withdrew. A relayer submits it, so no wallet of yours signs it, and the chain does not record which notes or which identity paid for it. Three things undo that: withdrawing to an address already tied to you, submitting the withdrawal yourself, which puts your wallet on chain as the fee payer, and the [escape hatch](https://docs.umbraprivacy.com/docs/operations/escape-hatch), which discloses the note's owner and your platform wallet.

The chain records no link between a deposit and a withdrawal, but amounts and timing can suggest one.

### The relayer tip

A tip's amount and token are public. Paying it in the token you moved tells observers which token moved.

### Program-owned notes

Spending a note owned by a Solana address publishes that address and which inputs it owns. Anyone who knows such a note, its creator for instance, can also compute its nullifier and see when it is spent.

### The escape hatch

An escape-hatch exit discloses twelve of the note's fields, including its owner and, for an identity-owned note, the platform wallet. See [the escape hatch](https://docs.umbraprivacy.com/docs/operations/escape-hatch).

## What parties in the transaction path learn

A spend passes through several services before it reaches the chain, and each learns something along the way. The chart below shows what leaves your device and where it goes; the sections after it explain each.

```mermaid
flowchart LR
D["Your device"] -->|"identity commitment, note positions"| C["Context service"]
D -->|"network address, timing"| G["Umbra's gateway"]
G -->|"one viewing-key share each"| N["Guardian nodes"]
G -->|"fee openings"| F["Fee enclave"]
G -->|"public payload"| A["Screener and data endorser"]
G -->|"finished transaction"| R[Relayer]
R -->|"public transaction"| S[Chain]
```

*What leaves your device during a spend, and which party receives it.*

### The recipient learns the sender

When a transfer spends an identity-owned note of the same token, each new note records the sender's identity commitment in its "funded by" field. The recipient reads it, and because registration is public, can follow it to the sender's wallets.

### The indexer's context service sees your spends

Before a spend, your device asks the context service for Merkle paths and nullifier gaps. The request names your identity commitment and the positions of the notes you are spending. Whoever runs the service can link the spend to you, whether or not it keeps a log. To receive, a sender asks the same service to resolve your address to your identity, so it also sees who pays whom.

### The fee enclave sees fee totals

The fee enclave opens the fee notes, so it learns each fee slot's token and total. With the rate, that approximates how much moved.

### Network addresses

The relayer sees the address your request comes from. Umbra's gateway, which the attesters and Umbra's relayer sit behind, sees it too, as does any RPC provider your wallet uses. See [metadata and network privacy](https://docs.umbraprivacy.com/docs/privacy/metadata).

## Patterns across transactions

The protocol hides each transaction's contents, but an observer can still compare transactions with each other. Four patterns narrow the set of notes yours could be.

**Matching amounts and times.** A deposit and a withdrawal of similar amounts close together suggest the same person, even though the chain records no link between them. The fewer other deposits of that size in between, the stronger the suggestion.

**Withdrawing to a known address.** A withdrawal's destination is public. If that address is already tied to you, the withdrawal is too, whatever happened inside the pool.

**Using what few others use.** Inside the pool every token shares one tree, so a token's identity stays private there, but deposits and withdrawals of a token only you use are public and easy to pair. A pool index few people use has its own small tree, so a spend from it has few candidates. See [the anonymity set](https://docs.umbraprivacy.com/docs/privacy/anonymity-set).

**Keeping a schedule.** Transactions at recognisable times, such as the same hour every week, can be grouped by their timing alone.

[Privacy practices](https://docs.umbraprivacy.com/docs/privacy/practices) lists what you can do about each.

## Related

- [What is private and what is visible](https://docs.umbraprivacy.com/docs/privacy/visibility): The same facts as a matrix.
- [Privacy practices](https://docs.umbraprivacy.com/docs/privacy/practices): Habits that keep the set large.
- [Metadata and network privacy](https://docs.umbraprivacy.com/docs/privacy/metadata): What leaves your device besides the transaction.
- [Trust assumptions](https://docs.umbraprivacy.com/docs/security/assumptions#who-holds-which-power): Every party's powers.


Last updated 12 October 2026