How do Zcash shielded and transparent transactions differ?

Zcash is two ledgers sharing one chain. The transparent part works like Bitcoin: public addresses, public amounts, a public UTXO graph. The shielded pools hold encrypted notes whose sender, receiver and amount are hidden, with a zk-SNARK proving each transaction is valid anyway. How private a Zcash payment is depends on which side the funds are on, and on what leaks when they cross between the two.

The pools

Pool	Introduced	Proof system	Trusted setup	Addresses
Transparent	2016	None (Bitcoin-style scripts)	n/a	t1... (P2PKH), t3... (P2SH)
Sprout	2016	BCTV14, later Groth16	Yes	zc... (legacy)
Sapling	2018	Groth16	Yes (multi-party ceremony)	zs1...
Orchard	2022 (NU5)	Halo 2	No	Only inside unified addresses (u1...)

Sprout is legacy. Since the Canopy upgrade in 2020, funds can only leave it. New wallets use Orchard, with Sapling still widely supported.

What a shielded transaction reveals

Shielded value lives in notes. When you receive, the chain records a note commitment, a hash that hides the recipient, the amount and some randomness, and appends it to a Merkle tree. When you spend, you publish a nullifier, a value derived from the note and your key. Nodes reject any nullifier they've seen before, which prevents double spends without revealing which commitment was spent.

The zk-SNARK proves, without revealing the inputs:

• each spent note is in the commitment tree,
• you hold the key that can spend it,
• its nullifier is derived correctly,
• value in equals value out plus the fee.

Encrypted to the recipient: the amount, the recipient's address and a 512-byte memo. Public: nullifiers, new commitments, the fee, the transaction's size and number of actions, and any value crossing into or out of the pool.

Direction	Name	What's public
t → t	Transparent	Everything: addresses, amounts, graph
t → z	Shielding	Source t-address and amount going in
z → z	Fully shielded	Only that a transaction happened, and its fee
z → t	Deshielding	Amount coming out and destination t-address

Only z → z hides all three: sender, receiver and amount.

Unified addresses

Before 2022, a user had to pick between a t-address and a zs address. Unified addresses (ZIP 316) bundle several receivers, such as Orchard, Sapling and optionally transparent, into one string starting with u1. The sender's wallet picks the most private receiver it supports, so an Orchard-capable wallet pays Orchard, while an older one falls back to Sapling or transparent.

t1Kx...        transparent P2PKH
t3Vz...        transparent P2SH
zs1q...        Sapling payment address
u1r7...        unified address (Orchard, Sapling, optional transparent receiver)
tex1...        transparent-source-only address (ZIP 320)
uview1...      unified full viewing key
uivk1...       unified incoming viewing key

Two details matter:

• Every receiver in a UA can be decoded by anyone who has the address. If you publish a UA with a transparent receiver, that t-address, and every payment to it, is tied to your shielded identity. Publish shielded-only UAs.
• Shielded keys are diversified. One Orchard or Sapling key can produce many addresses that nobody can link. Give each counterparty a fresh one.

TEX addresses (ZIP 320) exist for exchanges that require deposits and withdrawals to come from transparent funds. A tex1 address tells the sender's wallet to pay only from transparent inputs. It's a compatibility tool, not a privacy one.

zk-SNARKs: Groth16 vs Halo 2

Sprout and Sapling proofs need public parameters generated in a trusted setup. Whoever holds the secret randomness from that setup (the "toxic waste") could forge proofs and create coins undetectably inside the pool. Zcash ran multi-party ceremonies, which are secure as long as at least one participant destroyed their share. Still, it's an assumption you can't verify after the fact.

That risk isn't hypothetical. In 2018 a flaw was found in Sprout's original BCTV14 parameters that would have allowed counterfeiting. It was fixed with the Sapling upgrade and disclosed in 2019, with no evidence it was ever exploited.

Orchard uses Halo 2, a proof system with no trusted setup. It is built on the Pallas/Vesta curve cycle and a polynomial commitment scheme that needs no secret parameters. The cost is larger proofs and slower verification than Groth16, which the network accepts in exchange for removing the toxic-waste assumption.

Viewing keys for audits and compliance

Shielded data is encrypted, but you can let specific parties read it without giving them spending power:

Key	Shows
Spending key	Everything, and can spend. Never share it.
Full viewing key (uview1...)	Incoming and outgoing transactions and amounts
Incoming viewing key (uivk1...)	Incoming transactions and amounts only

Exchanges, auditors, accountants and tax authorities can verify balances and history this way. Two cautions: a viewing key can't be revoked, so once shared it exposes everything that account does from then on, and it applies to the whole account. Keep a separate account for anything you'll need to disclose, and share only its key.

The turnstile

Because shielded amounts are hidden, nobody can directly audit how much ZEC sits in each shielded pool. The turnstile handles this. Every transaction publishes a value balance for each shielded pool it touches, the net amount entering or leaving. Nodes track the running total per pool, and consensus (ZIP 209) rejects any transaction that would make a pool's balance negative.

So even if a counterfeiting bug existed inside Sapling or Orchard, no more value could leave the pool than went in, and a sudden shortfall would be visible. The price is that every crossing is public, including moves between shielded pools: migrating funds from Sapling to Orchard reveals the amount that crossed.

Practical guidance

1. Stay shielded. Receive to an Orchard-capable UA, pay z → z, and keep funds in the shielded pool. Fully shielded transactions are the only ones that hide sender, receiver and amount.
2. Treat shielding and deshielding as public events. If you shield 12.3456 ZEC and deshield 12.3456 ZEC a day later, that pair is trivially linked. Research on Zcash's early years linked a large share of shielded activity this way. Vary amounts, don't round-trip quickly, and avoid deshielding to the same party you shielded from.
3. Don't merge t-addresses. Shielding from several t-addresses in one transaction links them, exactly as Bitcoin's common-input heuristic does. Reusing a t-address links every payment to it.
4. Publish shielded-only UAs, and use a fresh diversified address per counterparty.
5. Use your wallet's default fee. Zcash uses ZIP 317 fees: 5,000 zatoshis per logical action, with a minimum of two (10,000 zatoshis). Fees are public, so a custom fee can mark your transactions as coming from your wallet.
6. Mind the network layer. A light wallet talks to a server that sees your IP address and when you connect. Use Tor or a server you trust for sensitive use.

Summary

	Transparent	Shielded (Sapling / Orchard)
Model	Bitcoin-style UTXOs	Encrypted notes, commitments, nullifiers
Visible	Addresses, amounts, graph	Fee, action count, pool crossings
Proof	Signatures	zk-SNARK (Groth16 / Halo 2)
Auditing	Anyone	Whoever you give a viewing key
Use it for	Exchange compatibility	Holding and paying

Zcash's privacy is strong once funds are shielded and stay shielded. Most of what leaks happens at the edges.