A unified address is 1 string that packs several receiving addresses inside it, and the sender's wallet decides which one actually gets paid. That much most explanations get to. What almost none of them mention is that the choice is not open: the specification fixes the order, and wallets are forbidden from letting you change it.
Search for the term and no page ranks. Search the broad version and the project's own address documentation comes fourth, without using the word unified even once.
So here is what the string holds, which receiver wins, why you cannot reorder the list, plus the one thing that decides whether any of it works.
What the string actually contains
Start with the problem it solves. Zcash has more than one way to receive a payment, and the ways were added over time. A sender's wallet may support all of them, some of them, or possibly only the oldest one, and the receiver has no way to know which before handing over an address.
The specification's own framing is exactly that. ZIP 316 says "Unified Addresses specify multiple methods for payment to a Recipient's wallet", and that "this enables the Consumer of a Unified Address to choose the Receiver of the best type it supports, providing a better user experience as new Receiver Types are added in the future".
Read the second half carefully. The design is aimed at receiver types that do not exist yet. A single string that already contains a slot for whatever comes next means a recipient does not have to publish a new address every time the protocol gains a capability.
Each thing inside the string is called a receiver, and each carries a typecode saying what it is. The address you paste is those receivers concatenated and encoded as one unit, which is why it is longer than any single address and why it looks like nothing in particular.
This is not a paper format. The reference wallet library has carried support for paying a unified address holding both Sapling and Orchard receivers, and for importing accounts from unified full viewing keys, across successive releases (source: librustzcash changelog).
Our guide to what a blockchain address is covers the general case, and our guide to Zcash address types covers the individual Zcash address types this container bundles.
The priority order, and how a sender picks a receiver
Here is the mechanism, and it is the part almost every explanation skips. When a sending wallet reads a unified address, it does not pick a receiver at random and it does not ask you. It walks a list in a fixed order and uses the first entry it can handle.
That order is written into the specification rather than left to each wallet to decide, which is what makes the format mean anything to the person publishing an address.
The specification sets that order out explicitly. The receivers may appear in a "fixed Priority List": the Orchard raw address first, then the Sapling raw address, then a transparent address (source: ZIP 316).
It also defines the word doing the work: "we say that a Receiver Type is 'preferred' over another when it appears earlier in this Priority List".
The order is neither arbitrary nor alphabetical. It runs from the newest shielded protocol, to the older shielded protocol, to the public one. Worth noting that this is the reverse of how the receivers are laid out inside the encoding, which is ordered by typecode ascending; the priority order is a separate rule from the storage order. So a capable wallet pays into the strongest available privacy, and a limited wallet falls back rather than failing.
That is the whole design in one sentence: a unified address degrades gracefully instead of breaking, and it degrades in a direction the recipient chose by publishing a shielded receiver at all.
There is a consequence worth noticing. Two people holding what looks like the same kind of address can receive payments into completely different pools, depending entirely on what the senders' wallets support. Nothing visible in the string tells you which happened.
Why the receiver list order is fixed
The obvious next question is whether a user can change that order to suit themselves. The answer is a flat requirement rather than a design preference, and it is one of the few places where the specification tells wallet authors what their software may not offer its own users.
A wallet "MUST NOT allow the user(s) to change the order of the Priority List used to choose the Receiver Type, except by opting into experiments". The requirement was set out in public and argued over in the specification's own discussion thread (source: zcash/zips issue 482).
That is stronger than it first looks. Reordering is not merely discouraged, it is prohibited for conforming software, and the only exception is an explicit opt-in to an experiment.
The reasoning follows from what a shared ordering is for. If every wallet chose its own preference, a recipient publishing one string could not reason about what they would be paid into, and the guarantee that a shielded receiver is used when possible would evaporate. The order is a promise made to the recipient by every conforming sender.
The specification does allow experiments to extend the list, and even then it says such additions "SHOULD maintain the intent of preferring more recent shielded protocols". The direction is fixed even where the contents are not.
Our guide to how crypto wallets work covers the software making this choice on your behalf, and our guide to address poisoning covers a different reason to look carefully at a string before paying it.
What a unified address is required to contain
A container that could hold anything would guarantee nothing, so the specification sets floors on what a valid one must include. There are two of them. The first mostly rules out nonsense. The second carries real weight for anyone deciding what to publish as a receiving address.
The general rule is minimal: "a Unified Address or Unified Viewing Key MUST contain at least one non-metadata Item". An empty container is not a valid address.
The rule that matters more is stricter. "A Revision 0 Unified Address MUST contain at least one shielded Item", which means a conforming unified address of that revision cannot be transparent-only.
That is a real guarantee and it is narrower than it sounds. It says the recipient offered a private option. It does not say the sender took it, because a sender whose wallet supports only transparent payments will walk down the list to the transparent receiver if one is present.
Both of those rules come from Revision 0, the Active revision, which is the one to reason from.
The requirement is enforced where it matters, in the code that reads these strings. The reference library exposes a unified address as a container of receivers with its own decoder, so a string that does not satisfy the rules simply fails to parse rather than producing a half-valid address (source: zcash_address::unified::Address).
That is worth knowing because it changes what a malformed address looks like in practice. You do not get a payment to the wrong place. You get a wallet refusing the string.
So the honest reading is that a unified address makes a shielded payment possible and never makes it certain. Our guide to Shielding ZEC after an exchange withdrawal covers what to do when a payment does land transparent, and our guide to Zcash privacy leaks and metadata covers what stays visible around a shielded one either way. For the trade in its general form, across any chain, start with crypto privacy basics.
Unified viewing keys, the parallel construction
The same bundling idea applies to viewing keys. Those are the credentials that let somebody read your activity without being able to spend from it, and they matter here because handing one over is a decision people make casually and cannot undo afterwards.
The specification defines a unified viewing key as "either a Unified Full Viewing Key or a Unified Incoming Viewing Key". The distinction matters if you ever hand one to anybody. A full viewing key sees more than an incoming one, and both are permanent disclosures rather than revocable permissions.
A caveat that changes how the rest of this should be read. The specification exists in three revisions with three different statuses: Revision 0 is Active, Revision 1 is Withdrawn, and Revision 2 is Draft (source: Zcash Improvement Proposals).
That matters because several of the more interesting viewing-key changes belong to the Draft revision, not the Active one. Revision 2 is the version that adopts separate uvf and uvi encoding prefixes and that "drops the restriction that a UVK must contain at least one shielded Item". It also introduces two new address variants, one prohibited from containing transparent receivers and one allowing them with metadata.
None of that is deployed by virtue of being written down, and this guide does not present it as current. Everything else here is Revision 0 material, which is the Active one.
The reference library implements the family that exists, describing itself as an "implementation of ZIP 316 Unified Addresses and Viewing Keys" and exposing separate types for the address, the full viewing key and the incoming viewing key (source: zcash_address).
The underlying distinction between public and private keys sits beneath all of this, and address reuse is the risk that grows when one receiving string gets handed out repeatedly.
Limits of a unified address
Four limits, and the first of them governs everything above rather than sitting alongside it. Each is a thing a reader could reasonably assume a unified address delivers, and each is something the format leaves to somebody else, usually to software neither party controls.
It does not work unless both wallets implement it. Every rule quoted here is a requirement placed on software, so the guarantees hold exactly where the software conforms and nowhere else. A sender running something that predates the format sees an unfamiliar string, not a fallback. The format is a coordination mechanism, and coordination mechanisms fail one participant at a time.
It does not tell you what happened. The string does not show which receivers it contains, and nothing about it records which one a given sender used. That is answerable from the chain afterwards, and it is not answerable from the address.
It does not make a payment private on its own. It makes a private receiver available and lets a capable sender reach it. Whether the payment ends up shielded depends on the sender's software, not on your address.
And it does not replace knowing which type you are dealing with. The project's own address documentation, which ranks fourth for the broad query, does not use the word unified at all (source: Zcash documentation), and plenty of services still speak only in the older vocabulary. Our guide to Zcash address types is the reference for that vocabulary.
BloFin has no stake in which receiver your counterparty's wallet picks, which is why what follows describes the ordering rule rather than recommending an address format.
Why the format exists at all
The problem it solves is easy to state and was genuinely painful before the format arrived.
Every generation of the shielded protocol brought a new address type, and a sender's wallet had to know which types the recipient supported. Handing out the newest address meant older wallets could not pay you. Handing out an older one meant funds landed in a pool you did not want them in. Handing out several meant explaining the difference to whoever was paying.
That last case was the common one, and it pushed a technical decision onto the person least equipped to make it. A recipient who wanted to be paid privately had to teach the sender what a shielded address was, and the sender frequently defaulted to the transparent option because it was the one their software handled without complaint.
A unified address removes the negotiation. It carries several receivers in one string, the sending wallet selects the best one both ends support, and neither party has to know which generation the other is running. The recipient publishes one thing, and it works.
The cost is that the string is longer and less legible, and that what actually happened is not visible to either party from the address alone. That is a genuine trade rather than a free improvement, and it is the reason the ordering rule matters: the outcome is determined by software rather than by either person's choice.
What to check when a payment lands somewhere unexpected
Three checks, in order, and the first resolves most cases.
Check which receiver the sender's wallet used. A payment that arrived transparent from a unified address means the sending software supported nothing better, which is a fact about their wallet rather than about your address.
Check whether your wallet published all the receivers you intended. Some software constructs unified addresses containing fewer receivers than the format allows, and a receiver that is not in the string cannot be selected.
Check the pool generation. A wallet that supports shielded addresses in general may support an older pool than the one currently open, and a payment landing in a superseded pool will need migrating before it can be spent normally.
None of the three is fixable after the fact for a payment already made. All three are worth establishing before publishing an address you expect to be paid at repeatedly.
The broader point is that a unified address moves a decision from the person to the software, and that is its whole value and its whole cost at the same time. The value is that nobody has to understand pool generations to be paid correctly. The cost is that when something lands in the wrong place, the explanation lives in software neither party controls, and there is no setting either of them could have changed.
That trade is worth taking, because the alternative it replaced was worse in practice. It does change what a recipient should verify, though. The address they published is almost never the problem. What arrived is where the answer lives.
What the format leaves out
Four things a unified address contains no information about, each of which people expect it to settle.
It carries no indication of which receiver a sender used. The string is the same before and after a payment, and establishing what happened requires looking at the transaction rather than at the address.
It carries no expiry. An address published once remains valid indefinitely, which is convenient and means an address handed out years ago is still receiving into whatever receivers it contained then.
It carries no amount and no reference. Those belong to payment request links, which are a separate construction built around an address rather than part of one.
And it carries no guarantee that every receiver inside it is currently useful. A string assembled by older software may contain receivers for pools that have since been superseded, and nothing about the address announces that.
Frequently asked questions
What is inside a Zcash unified address?
One or more receivers, each carrying a typecode that says what type it is, concatenated and encoded as a single string. The specification describes unified addresses as specifying multiple methods for payment to a recipient's wallet. That is why the string is longer than any individual address and why looking at it tells you nothing about what it holds. The contents only matter at the moment a sender's wallet reads it and picks one.
Which receiver does a sender actually use?
The first one it supports, walking a fixed order. The specification sets that order as Orchard first, then Sapling, then transparent, and defines a receiver type as preferred when it appears earlier in that list. So a wallet that can pay into the newest shielded protocol will, and one that cannot falls back rather than failing. The recipient does not choose per payment; they chose when they published an address containing shielded receivers.
Can I make my wallet prefer a different receiver?
Not in conforming software. The specification states that a wallet must not allow users to change the order of the priority list, except by explicitly opting into an experiment. The reason is that a shared order is what makes the format mean anything: if every wallet ordered differently, publishing one string would tell a recipient nothing about what they would be paid into. Even permitted experiments are told to maintain the intent of preferring more recent shielded protocols.
Does a unified address guarantee I get paid privately?
No. It guarantees that a private option was offered. A Revision 0 unified address must contain at least one shielded item, so a conforming address of that revision cannot be transparent-only. But if the sender's wallet supports only transparent payments, it walks down the list and uses the transparent receiver. The address makes a shielded payment possible; the sender's software decides whether it happens.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash Improvement Proposals repository, the reference address library's published documentation, and the Zcash project's own documentation. All facts independently verified against cited documentation current as of August 2026. This article names no wallet and makes no claim about which software supports the format.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Do your own research before making any decision.