Zcash Z-Address vs T-Address vs Unified Address

Key Facts

• T-address activity is visible on the public Zcash ledger.
• Z-address is the familiar name for a standalone shielded address, most commonly a Sapling address.
• A Unified Address is a container of receivers, not a fourth value pool.
• The sender's wallet ultimately decides which compatible receiver it uses.

The short answer

Use a t-address when public ledger visibility is intentional or a service supports only transparent ZEC. Use a z-address when the wallet specifically asks for a standalone shielded receiver. Use a Unified Address when both wallets support it and you want the wallet to select the strongest compatible receiver without making the recipient juggle formats.

Address choice is not cosmetic. It changes what can appear on-chain, which wallets can complete the payment, and how much privacy depends on the sender's software.

T-address: transparent like Bitcoin

A Zcash transparent address begins with a t in its familiar mainnet encoding. Payments involving transparent inputs or outputs expose ledger data in much the same way as Bitcoin: addresses and values on the transparent side can be inspected and followed by anyone with a block explorer.

Transparent support remains useful for compatibility, but it should not be mistaken for privacy. Sending ZEC through several t-addresses does not make the graph private; it usually creates more public links.

Z-address: a standalone shielded receiver

Z-address is the long-standing shorthand for a shielded payment address. Sapling addresses commonly begin with zs, while older Sprout addresses begin with zc. A payment between supported shielded receivers can keep the sender, recipient, amount, and memo from being published in readable form on the blockchain.

A z-address is valid only where the sending wallet or service supports that shielded pool. An exchange rejecting a z-address is reporting a product limitation, not proving the address is malformed.

Unified Address: one string, several receivers

ZIP 316 defines Unified Addresses as containers. One can carry Orchard, Sapling, and, depending on the address variant, transparent receivers. The container itself does not hold ZEC and does not create a new privacy pool. It gives the sending wallet a structured list of destinations and preference rules.

That distinction matters. A Unified Address can make a shielded payment easier, but the sender's wallet still has to parse the address and choose a supported receiver. Modern shielded wallets typically prefer Orchard or Sapling over a transparent fallback. Newer ZIP 316 revisions also define encodings that can prohibit transparent receivers, but wallet support and the visible prefix can vary. Let trusted wallet software validate the complete address instead of guessing from its first character.

Which address should you share?

Share a Unified Address generated by a current shielded wallet when the sender also uses compatible software. It reduces receiver-format errors and gives the wallet room to route to the best supported pool. If a service accepts only a t-address, assume the payment boundary is public and decide whether that is acceptable before proceeding.

Never paste an address into an unofficial converter to make it work. Copy the entire string, confirm the wallet recognizes the network and receiver type, and use a small test payment when support is uncertain. A truncated or manually extracted receiver can change both compatibility and privacy.

The useful mental model

Think of t and z addresses as specific destinations. Think of a Unified Address as an envelope containing destinations the sender can choose from. The envelope improves coordination; the actual receiver selected determines the transaction path.

Before approving a payment, check what the wallet says it will do. A good wallet makes a transparent fallback obvious rather than hiding it behind a successful-looking send button.

FAQ