Zcash privacy
Zcash Address Types: Transparent, Shielded and Unified
Quick Answer
Zcash address types describe how a wallet can receive funds. Transparent receivers expose financial information, while shielded receivers support privacy-preserving transfers. A Unified Address combines receiver information in one encoded string. The address format is not a guarantee that every payment is shielded: the sending wallet and the receiver it selects also matter.
Key Takeaways
- Transparent and shielded receivers serve different transfer types.
- Unified Addresses combine receiver information into one encoded string.
- The sending wallet and selected receiver determine the relevant payment workflow.
Start with the receiver, not just the product name
ZIP 316 defines a receiver as information needed to transfer an asset using a particular transfer protocol. Its historical motivation lists transparent P2PKH/P2SH, Sprout and Sapling address types through Canopy and introduces Orchard as a new receiver type.
A Unified Address combines receiver items, whereas a legacy address is transparent, Sprout or Sapling. This is a specification taxonomy, not a statement that every historical type is recommended or supported by every current wallet.
One string is not a complete compatibility matrix
The abstract describes bundling different address types in a single encoding. The document also explicitly says a wallet can support Unified Addresses while supporting only a subset of payment methods.
Readers comparing wallets therefore need separate evidence for address parsing, receiving and sending, and the receiver/pool involved. A README saying Android wallet is not evidence for all of these tasks.
The local wallet database deliberately leaves unsupported claims out of its limited source-stated matrix.
Why the revision label matters
The pinned header is not a single undifferentiated Active status: Revision 0 is Active, Revision 1 Withdrawn and Revision 2 Draft. The same file includes future-design language.
In particular, Revision 2 visual distinction and information-leakage requirements must not be copied into an explanation as already deployed behavior. This guide does not assert that a currently installed wallet implements those draft requirements.
A revision-aware source is necessary before changing a public privacy claim.
Inspect an address workflow without sending us an address
For research, first record the wallet publisher, release and platform. Then inspect its official receiver and transfer documentation and compare that scope with the ZIP revision.
Do not infer transfer privacy from the word Unified alone. This site does not parse real wallet addresses, scan transactions, connect a wallet or request a seed, spending key or viewing key.
Readers can use the wallet database to inspect existing source statements rather than expose private account information.
FAQ
Does a Unified Address guarantee a shielded transfer?
No. Receiver choice, transfer protocol and wallet behavior require separate evidence; a bundled encoding alone does not establish the disclosure properties of a transfer.
Is every part of ZIP 316 active?
No. The retrieved header explicitly separates Active Revision 0, Withdrawn Revision 1 and Draft Revision 2. Do not promote draft requirements to installed-wallet claims.
Can I paste an address to check it here?
No. This is a source-reference guide and does not accept real wallet addresses or keys.
Sources and Methodology
Page updated: . Source observation dates remain separate.
Source checked: 2026-10-01T17:23:37.658606+00:00
Source version and supporting details
- Lines 14–17: Revision 0 Active; Revision 1 Withdrawn; Revision 2 Draft; MIT license.
- Lines 43–82: receiver, legacy address, Unified Address and viewing-key terminology.
- Lines 104–107 and 170–172: bundled encoding and subset-of-payment-method wallet support.
- Lines 217–237: Revision 2 requirements and encoding/receiver distinction.
a735caf76ed8d3fa0a50e4f6b706ca9dac39079b
02116bf336f760360b86a4ae646bc1c084f04722a25794678b1cde63cfdfe643
Methodology and technical limitations
Method, scope and limitations
Evidence is one immutable ZIP 316 source version. Definitions and explicit revision metadata are paraphrased from its terminology, abstract and model interaction flow; implementation coverage, independent chain activation and device behavior are not tested. The source-check date is retrieval time, not the creation or activation date.
Source dates describe the referenced observation or document, not a live price. How data is checked · Corrections