Zcash Shielded Pools, Unified Addresses, and Viewing Keys Explained

In Zcash, a pool is not a company or exchange holding user deposits. It is a value state tracked under particular consensus rules. The transparent pool uses UTXOs. Anyone reading the public chain can inspect which output was created by a transaction, which later transaction spent it, and the visible amount. An address string is not a legal identity, but the public record still exposes address use and links between transparent inputs and outputs.

Shielded pools represent value with notes instead of UTXOs. The network records encrypted note data while checking commitment trees and pool-balance rules. “Shielded” therefore does not mean that transactions are unverified or moved into a separate custodian. Consensus still checks value conservation and double-spend prevention; the representation changes so ordinary observers cannot read a recipient address and note amount the way they can for a transparent output. The Zcash Protocol Specification defines both transparent UTXOs and shielded notes.

Zcash has gone through several generations of shielded protocols. Sapling and Orchard are separate shielded pools with distinct note-commitment trees, so their shielded state is not one interchangeable balance. Sprout was used for older shielded addresses and transactions, but new value can no longer be added to its pool after ZIP 211 activated. Current Mainnet Unified Addresses commonly receive through Orchard or Sapling, and may also carry a transparent receiver.

Network status should be dated. The Zcash ZIP index says NU6.2 is the latest settled Mainnet upgrade, activated at block 3,364,600 on June 3, 2026. A temporary mitigation had prohibited Orchard actions after a vulnerability was found; NU6.2 re-enabled Orchard with corrected circuit rules. NU6.3 is still a draft, and that proposal includes an Ironwood pool and changes involving Orchard. Do not describe draft behavior as a current Mainnet rule. ZIP 257 records the NU6.2 Orchard re-enablement, while the ZIP index and draft ZIP 258 show the latest settled upgrade and NU6.3's draft status.

A shielded receiver gets a note that associates value in a pool with the recipient's spending authority. The note's value, recipient details, and memo are encrypted so a wallet with the corresponding receiving information can decrypt them. The blockchain carries encrypted note data and a commitment to the note rather than the note plaintext. The commitment lets consensus validate that a well-formed note was created without publishing its contents.

When the note is spent, a corresponding nullifier is revealed. A person who knows the note proves which note is being consumed and publishes the nullifier; the network checks that the same nullifier is not reused. Observers can see the nullifier and commitment tree, but should not be able to identify which earlier commitment corresponds to the nullifier. This structure helps prevent double spending while hiding a direct link between an address and amount. It does not make every hash or commitment secret: Zcash combines publicly verifiable records with decryption authority.

Sapling and Orchard share that broad design, but use distinct protocols and cryptographic components. Wallet support for a pool, address type, and proof system matters. A note is not a public balance that can move arbitrarily inside a common account: spending requires the private authority corresponding to the shielded address that received it.

A Unified Address, or UA, is one encoded address that can contain multiple receiver items. The currently active ZIP 316 Revision 0 format generally starts with u and can contain Orchard, Sapling, transparent P2SH, or transparent P2PKH receivers. A Revision 0 UA must include at least one shielded receiver. The string is intentionally not designed for people to inspect and identify its receiver types by sight, so do not infer its pool contents from the prefix or length alone. ZIP 316 distinguishes active Revision 0 from proposed later formats.

The sender's wallet does not use every receiver in a UA. ZIP 316 Revision 0 orders receiver preferences as Orchard, Sapling, transparent P2SH, then transparent P2PKH. A sender must use the most preferred receiver in the UA that it supports. For example, a wallet that supports Orchard and receives a UA containing an Orchard receiver should use that receiver. If it does not support Orchard but does support Sapling, it may select Sapling. The actual pool used therefore depends on the sender wallet's supported protocols, not just the displayed address string.

ZIP 316 Revision 2 proposes zu shielded-only addresses and tu formats that can include transparent receivers, but the ZIP index currently labels Revision 2 a draft. Do not present those prefixes as the ordinary live Mainnet UA format. Check the wallet's displayed address type, selected network, and the receiver shown during payment review.

A transparent-to-shielded transfer (t→z) can combine spending public UTXOs with creating Sapling or Orchard notes. A chain observer can see the transparent inputs, changes to the transparent pool, and net value entering a shielded pool. The observer does not read the shielded output's ordinary receiving address or each note amount as if it were a transparent UTXO. Shielding value leaves boundary evidence even though note details are encrypted.

A shielded-to-transparent transfer (z→t) exposes the reverse boundary: transparent output addresses and amounts are public, and the corresponding change in shielded-pool value can be observed. A shielded payment that creates notes inside one pool may hide recipient and amount details, while a transfer between separate Sapling and Orchard pools can make per-pool balance changes informative. A public boundary value does not by itself identify a particular person or old note, but it can be combined with amounts, timing, and outside records.

So do not ask only whether an address is shielded; also ask where the value started and which pools it crossed. If an exchange withdrawal, merchant payment, or personal transfer has a known time or amount, it may be compared with public boundary information. Pool crossings can connect encrypted note details with public transparent records, but that does not reveal every note owner or internal recipient path.

ZIP 316 defines a Viewing Key as information needed to view payments to an address. A Full Viewing Key (FVK) can also view information from that address. An Incoming Viewing Key (IVK) can be derived from an FVK, and an address can be derived from an IVK. Unified Viewing Keys combine viewing-key items for multiple protocols. Exporting one to an accounting service or another wallet can expose shielded receipts or spending activity within its scope, so first understand what authority is being shared.

A viewing key alone cannot sign a spend. Spending authority belongs to a separate spending key or signing system. Still, a viewing key is not public data: the key type and wallet implementation determine what transaction range can be seen, and an account-level viewing key can reveal much more than one receive address. Before sharing it with an auditor or bookkeeper, check its scope, retention period, deletion options, and whether it is combined with other addresses.

A viewing key also does not remove other privacy clues from the chain. Transparent inputs and outputs were public already, and third parties can analyze amounts, timing, and transparent addresses without a viewing key. Conversely, a shielded transaction may not appear in an explorer or wallet that lacks the necessary support even if the chain recorded it. Do not confuse “the wallet does not display it” with “the chain does not contain it.”

Zcash is a privacy protocol where visibility depends on the pool and receiver type. A transparent-only flow reveals addresses, amounts, and UTXO links. A shielded-pool payment encrypts note recipients and values, but commitments, nullifiers, timing, and protocol data still appear on chain. Boundary transactions, supported pools, a counterparty's known payment time, exchange records, and shared viewing keys can each create separate clues.

A Unified Address is not a switch that forces all payments into Orchard. The selected receiver can depend on a wallet's implementation, version, settings, and transaction path. Do not infer a payment's privacy properties just from pasting an address; check the transaction preview or final result for the chosen pool. The [Monero privacy guide](/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) explains a different chain's privacy design, while the [Bitcoin address-reuse guide](/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) provides a comparison with links on a transparent ledger.

Network privacy is another layer. An RPC provider, light-wallet server, exchange, or payment service may observe transaction creation or relay requests and retain account, IP, or timing information outside the chain. Cryptographic proofs do not automatically erase those service logs. Instead of claiming a particular anonymity level, ask who received metadata and how that service stores it.

First verify that the wallet is connected to Mainnet or Testnet as intended. During payment review, confirm that the recipient address is unified and check which receiver the wallet selected. Since the address string is not visually parseable as a list of receiver types, read the wallet's display for pool, amount, memo, and fee information. If a recipient asked for a shielded payment but the sender wallet previews a transparent output, check protocol support on both wallets before sending.

To investigate an existing transaction, match its transaction identifier and network, then check which pools appear in its inputs and outputs. Transparent addresses and amounts are visible in public explorers; shielded note details may not be displayed by a tool that does not support them. If you need a viewing key for a particular check, establish why it is needed and what it reveals, and do not paste spending or viewing keys into an unfamiliar site. The custodial and non-custodial wallet guide also explains signing responsibility.

Avoid conclusions such as “I used a shielded address, so the payment is completely private” or “the explorer does not show a value, so the transfer did not happen.” Separating wallet history, network, transaction ID, chain status, confirmation level, and viewing authority helps narrow down a problem. If the recipient must confirm receipt, do not rely only on a chain explorer; check that the receiving wallet supports and has synchronized the relevant pool.

Suppose Lee sends 1.25 ZEC from a transparent UTXO to a recipient's Revision 0 Unified Address containing Orchard, Sapling, and transparent receivers. This amount is illustrative; it does not specify a fee rate or a wallet default. If Lee's wallet supports Orchard, ZIP 316's preference rule selects the Orchard receiver. The public chain shows the transparent input and boundary information such as net value entering a shielded pool, but not the recipient's shielded note address and amount as ordinary public outputs.

If Lee's wallet does not support Orchard but does support Sapling, it can select Sapling. A wallet that does not support any shielded pool may use a transparent receiver if that receiver and payment format are available. A Revision 0 UA must contain a shielded receiver, but the sender selects only a receiver its wallet supports. The same UA can therefore result in different pools and visible boundary data when it is used from wallets with different capabilities.

Finally, if the recipient separately shares a viewing key with an accounting service, that service may see shielded activity within the key's scope. The wallet showing a receipt, the explorer not showing note details, and the chain recording a transaction under consensus are three different facts. Unified Addresses make it easier to offer receivers from several protocol generations; they do not guarantee complete privacy or take over a wallet's receiver selection, key management, or network-exposure responsibilities.

• Zcash Protocol Specification v2026.7.0 (NU6.2)
• ZIP 316: Unified Addresses and Unified Viewing Keys
• ZIP 211: Disabling New Value to the Sprout Pool
• ZIP 257: NU6.2 and the Orchard Temporary Mitigation
• ZIP 258: Draft NU6.3 Deployment
• Zcash ZIP index: settled Mainnet upgrade and ZIP status