SwapToZec

← All posts

Zcash unified addresses (u1…) explained

5 min readSwapToZec

A Zcash unified address (u1…) is one string that stands in for several. Behind it sit multiple "receivers" — one for the Orchard shielded pool, one for the Sapling shielded pool, and optionally one for the transparent chain — packed together with a small self-describing format. When you hand a u1… to someone, the sender's wallet picks the receiver it supports and pays that one.

The rest of this post walks through why the format exists, what the string encodes, and what you can and can't assume when funds land at your u1….

Why unified addresses exist

Before the Zcash network upgrade in mid-2022 called NU5, a Zcash user had two separate addresses. A t1… was a transparent address that behaved exactly like a Bitcoin address. A zs1… was a Sapling shielded address that took funds into the shielded pool. Every wallet had to show both. Every payment form had to accept both. Every user had to know which to hand to which sender.

That split was avoidable. The wallet already knew about both, so the address handed out could too. NU5 introduced a new shielded pool (Orchard) and a container format that could hold receivers for all three pools at once. That container is the unified address, defined by ZIP-316. NU5 activated on Zcash mainnet at block 1687104, mined on 31 May 2022 (activation record).

What's actually inside a u1…

A unified address is a list of receivers plus some framing. Each receiver is one of:

  • an Orchard receiver (typecode 0x03)
  • a Sapling receiver (typecode 0x02)
  • a transparent P2SH receiver (typecode 0x01)
  • a transparent P2PKH receiver (typecode 0x00)

The list is concatenated, padded, run through a transformation the ZIP calls F4Jumble, and finally encoded as Bech32m with the human-readable prefix u for mainnet and utest for testnet. The result is the string that starts with u1… you paste into forms.

You don't need to decode any of this by hand — the wallets that support unified addresses do it for you. The mechanical detail matters only because it tells you two things about a unified address you can't tell by eye:

  1. It's a package, not a single address. The same u1… can serve a transparent-only sender and a shielded-capable one — they see the address the same way but pay different receivers.
  2. The choice of receiver is the sender's. More on that below.

For the full encoding rules see the ZIP's encoding section.

What the sender sees, and why that matters

ZIP-316 states the sender rule directly: the sender "MUST use the Receiver of the most preferred Receiver Type that it supports from the set." The preference order the ZIP defines is Orchard → Sapling → transparent (P2SH before P2PKH).

Concretely, imagine you publish a u1… that bundles all three:

  • A modern wallet that supports Orchard pays the Orchard receiver. Your funds land in the shielded pool with the current strongest privacy guarantees.
  • A wallet from before NU5 that only knows Sapling pays the Sapling receiver. Funds still land shielded, in the older Sapling pool.
  • A transparent-only wallet — an exchange, a legacy tool, an integration that hasn't been updated — pays the transparent receiver. The receive is public on chain.

The address you shared didn't change. The pool your funds ended up in depended entirely on the sender.

Two consequences follow from that. First, you can't guarantee "shielded receive" just by publishing a u1… — you can only guarantee it if the sender's wallet supports a shielded receiver. Second, you can create a unified address that omits the transparent receiver, in which case a transparent-only sender simply can't pay it and has to send you a t1… some other way. Which trade-off you want depends on how much friction you're willing to add to the corner of your senders that hasn't upgraded.

What the recipient sees in their wallet

Wallets that support unified addresses treat the balance behind a u1… as one number. The wallet knows internally which pool each incoming payment landed in. Modern wallets — Zashi, Ywallet, Nighthawk — will show you incoming payments as line items and, if you look at each one, tell you whether it arrived shielded (Orchard or Sapling) or transparent.

If you receive to a transparent receiver on your unified address and want the funds shielded, your wallet can move them across with a t → z shielding transaction. That's a normal, supported operation.

Should you use u1… for a swap payout?

Yes, if your wallet supports it. Paste the u1… from your wallet's "receive" screen into the destination field. When the operator sends your ZEC, the sending wallet on their side picks the receiver it supports — same rule as for any other sender.

If your wallet only shows a transparent t1… or t3…, those still work — you just receive to the transparent chain and can shield the funds yourself afterwards.

At Swap2Zec, our destination-address validation accepts u1…, t1…, and t3…. Any of them works on the BTC → ZEC swap page, and the same is true of the other pair pages. See how the payout step of the swap flow works for the source-side of the same story, and /blog/zcash-shielded-vs-transparent-addresses for the underlying pool distinction that unified addresses paper over.

Common questions

"My wallet says u1… but the explorer shows a transparent transaction — why?" Because the sender's wallet chose the transparent receiver. The sender didn't do anything wrong; they used the receiver they supported. If you want that specific sender to pay you shielded, you need them on a wallet that supports Sapling or Orchard.

"Can I share my u1… publicly?" The address itself is safe to publish — that's the point of a receive address. What is public depends on which receiver gets paid. Transparent receives are visible on a public explorer; shielded receives are not. So a widely-published u1… that mixes public and shielded payments will show some incoming transactions on-chain and hide others.

"Do I need a new u1… for every payment?" No. Unified addresses stay valid indefinitely. The Zcash protocol supports diversifying addresses under the same viewing key if you want per-payment separation, but that's a wallet feature, not something you generate by hand.

Further reading