Privacy as a consensus property.

What a shielded note actually is

When the relayer ring settles a transfer, the output is an ordinary Orchard note. It has a recipient, a value and two pieces of randomness, and the only thing the network ever sees is a commitment to all four.

Note {
  recipient:  Address,      // derived from the diversified key
  value:      NoteValue,    // the amount, encrypted to the recipient
  rho:        Nullifier,    // ties this note to the one it replaced
  rseed:      RandomSeed,   // domain-separated randomness
}

// The commitment enters the global Merkle tree. It reveals nothing.
cm = NoteCommit^Orchard(g_d, pk_d, v, rho, psi)

// The nullifier is revealed only when the note is spent, and cannot be
// linked back to the commitment without the spending key.
nf = Extract(Poseidon(nk, rho) + psi) * G + cm

Validators check that the spend is authorised and the value balances — without learning the sender, the recipient or the amount. That property is enforced by the Halo 2 circuit every full node runs, not by a contract someone can upgrade.

Nullifiers, and why double-spends are impossible

Spending a note publishes its nullifier. The network rejects any nullifier it has seen before, which prevents double-spending — but a nullifier cannot be linked to the commitment that produced it without the spending key. The ledger therefore knows that some valid note was consumed, and nothing more.

Orchard versus Sapling

Proof system

Orchard: Halo 2 · Sapling: Groth16

Trusted setup

Orchard: none · Sapling: required

Curve

Orchard: Pallas/Vesta · Sapling: BLS12-381

Address format

Unified (u1…) · Legacy shielded (zs1…)

Anonymity set

Single pool, growing · Legacy, static

Z-Relay default

Orchard

Z-Relay settles into Orchard by default. Sapling remains supported for recipients whose wallets have not migrated, but it carries a legacy trusted setup and a shrinking anonymity set, so the SDK will warn when a Sapling address is supplied.

Unified addresses

Recipients are specified as unified addresses (u1…), which bundle receivers for several pools behind one string. The SDK parses the address, selects the Orchard receiver when one is present, and refuses outright if the address offers only a transparent receiver — silently settling a “shielded” payment into a transparent address would be the single worst bug this protocol could ship.

Encrypted memos

Each Orchard output carries a 512-byte memo field encrypted to the recipient. Z-Relay uses it to carry settlement context — an invoice reference, a payout period, a desk identifier — so that the receiving institution can reconcile a payment without any off-chain channel. The memo is visible to the recipient and to anyone they choose to give a viewing key, and to nobody else.

What is still observable

Honesty about the boundaries matters more than marketing:

• The EVM side is public. A deposit into ZRelayEscrow on Robinhood Chain is a visible transaction with a visible amount. What is hidden is where the value went and who now holds it.
• Timing correlation is real. A single large deposit followed seconds later by a single large Orchard output is a weak but non-zero signal. Batching and the ring's randomised delay window reduce it; they do not eliminate it.
• Your counterparty knows what you told them. A viewing key you share is shared. Selective disclosure limits scope, not recipients' memories.