Metadata and network privacy

A transaction's contents are protected by its proof and its encryption. Everything around it is not: the network address a request comes from, when it is sent, and which service it is sent to. This page lists what your device sends, and to whom.

What your device sendsCopy Anchor Link

A transaction leaves your device as several requests to different services. The chart below shows each one and where it goes.

flowchart LR
D["Your device"] -->|"paths and payees"| C["Context service"]
D -->|"sync ranges"| I["Data service and CDN"]
D --> G["Umbra's gateway"]
G -->|"shares and fee openings"| E["Guardian nodes and fee enclave"]
G -->|"public payload"| A["Screener and data endorser"]
G -->|"finished transaction"| R[Relayer]

Every one of these receivers sees the network address and the time of the request, unless something between you and it hides them. The sections below say what else each request carries.

Paths and payees, to the context serviceCopy Anchor Link

Before a spend, your device asks the indexer's context service for the Merkle paths of the notes it will spend, the nullifier gaps that prove those notes unspent, and the identity of the recipient behind the address you are paying. The request carries your identity commitment, the positions of the notes you spend and the recipient's address. This is the request that links a spend to you; the section on spending below explains why.

Sync ranges, to the data serviceCopy Anchor Link

To find notes sent to you, your device downloads encrypted notes, nullifiers and records from the indexer's data service and its content delivery network. It asks for ranges of the whole feed, never for your notes in particular.

Shares and fee openings, to the enclavesCopy Anchor Link

Your device sends each guardian node its share of the transaction's viewing key, and sends the fee enclave the openings of the transaction's fee notes. Each is encrypted to the enclave that receives it, and travels through Umbra's gateway and the guardian nodes' relays, which carry it without being able to read it.

The public payload, to the screener and data endorserCopy Anchor Link

The screener and the data endorser receive the transaction's public payload through Umbra's gateway. It holds nothing the chain will not show once the transaction lands, but they see it before it lands.

The finished transaction, to a relayer or RPC providerCopy Anchor Link

The signed transaction goes to a relayer, which Umbra's SDK reaches through the same gateway, or to a Solana RPC provider if you submit it yourself. It carries its public payload and proof.

Syncing does not single you outCopy Anchor Link

To find notes sent to you, your device downloads every encrypted note and tries to decrypt each one with your key. It never asks for "my notes", so the service that serves the feed cannot tell which notes are yours. This is the one request whose design keeps the service from learning anything about you. See receiving and syncing.

Spending doesCopy Anchor Link

A spend needs Merkle paths for the specific notes you spend, and the context service is asked for them by position along with your identity commitment. That links the spend to you for whoever runs the service. Asking for paths to many notes, or rebuilding the tree locally from the chain, would avoid it; the current client does neither.

What the protocol cannot doCopy Anchor Link

The protocol has no control over network-level metadata. Your IP address reaches the relayer, Umbra's gateway and any RPC provider your wallet uses. If that matters to you, a network privacy tool between your device and those services is the only remedy.

RelatedCopy Anchor Link