One ZEC, different visibility
How does Zcash provide privacy on a public blockchain?
Zcash uses zero-knowledge proofs to validate shielded transactions without disclosing the protected sender, recipient, or transferred amount on the public blockchain. ZEC remains the same Zcash network asset whether it is held in the transparent, Sapling, or Orchard pool.
Moving ZEC from the transparent pool into a shielded pool is called shielding; moving it back is called deshielding. If a transaction touches the transparent side, the associated addresses and amounts are public. The pools a wallet supports determine which transaction types its users can actually perform.
- ✓Zero-knowledge proofs validate without revealing plaintext
- ✓ZEC can move between value pools
- ✓The wallet determines available pools and transaction types
Transparent and protected
Transaction composition determines what is visible on-chain
Zcash transactions can contain transparent or shielded components. A fully shielded transaction can hide the sender, recipient, and transferred amount from public blockchain observers while still allowing the network to verify that the transaction is valid. If a transaction includes a transparent input or output, the addresses and amounts associated with the transparent component are public.
Even when a transaction is fully shielded, the transaction record, fee, and confirmation time remain observable on-chain. Network metadata or transaction IDs, amounts, and counterparty information shared off-chain may also create linkages.
Transparent
Public record- Addresses and amounts associated with transparent inputs or outputs are recorded publicly on-chain.
- Relationships involving the transparent component may be analyzed and linked.
- Specific support depends on the wallet or service.
Shielded
Encrypted protection- A fully shielded transaction can hide the sender, recipient, and transferred amount.
- The transaction's existence, fee, and confirmation time remain visible.
- Requires wallet support for the relevant shielded pool and workflow.
- ✓Transparent components: associated addresses and amounts are public
- ✓Shielding or deshielding: information on the transparent side is public
- ✓Fully shielded: addresses and amounts are hidden, but the fee remains visible
A new generation of shielded pool
How does Ironwood strengthen Zcash's long-term security?
Ironwood is a new shielded pool and v6 transaction format introduced with NU6.3. It reuses Orchard's core protocol and Halo2 proof system while maintaining its own commitment tree, nullifier set, and value-pool accounting. Funds migrating from Orchard into Ironwood pass through the publicly accounted turnstile, strengthening the network's ability to verify the circulating ZEC supply and reducing supply-integrity uncertainty associated with the previously remediated Orchard vulnerability.
Ironwood also adds quantum recoverability for newly created shielded notes. If quantum computing eventually threatens the current spend-authorization mechanism, a user holding the correct recovery material may still be able to regain control of the funds. This is a recovery safeguard, not complete post-quantum security. Users need an NU6.3-compatible wallet and firmware and should follow the official migration workflow.
- ✓NU6.3: the new Ironwood pool and v6 transaction format
- ✓Orchard to Ironwood: turnstile accounting strengthens supply verification
- ✓Quantum recoverability: a long-term recovery safeguard, not complete post-quantum security
Viewing and spending authority
How can an online wallet show a balance without directly spending ZEC?
A shielded account can separate viewing authority from spending authority. Depending on the integration, the online wallet uses the information required for account synchronization to scan encrypted on-chain records that belong to the user, calculate the balance, and construct transactions. That information is not the spending key that can authorize ZEC transfers.
Keystone isolates the spending key and receives signing requests by QR code. The wallet continues to handle synchronization, transaction construction, and broadcasting, while Keystone reviews and authorizes the fields it can parse in an offline environment.
- ✓Viewing authority is not spending authority
- ✓The wallet synchronizes, constructs, and broadcasts
- ✓Keystone isolates the spending key and authorizes spending
Two different protections
Shielded protects on-chain privacy; Keystone protects spending authorization
The shielded protocol can reduce information disclosed on the public blockchain, but it cannot stop malware from stealing a seed phrase or spending key, or stop a compromised wallet from constructing a signing request that does not match the user's intent.
Keystone isolates the spending key from the online environment and lets the user review transaction fields the device can parse. It does not hide IP-based network metadata for the online wallet or revoke viewing information already shared with a wallet or third party. Device review, recovery backups, and small test transactions therefore address different risks.
- ✓Shielded: protect on-chain transaction information
- ✓Keystone: isolate the spending key
- ✓User: review authorization and protect recovery material
From network to signing
Which ecosystem roles sit behind a ZEC transaction?
Zcash is not operated by a single wallet or company. Full nodes such as Zebra verify that transactions and blocks follow the consensus rules and propagate data across the network. Wallets such as Zodl, Vizor, and Noir synchronize accounts and construct transparent or shielded transactions according to the features they support, while exchanges, payment services, and block explorers provide access to trading, payments, and on-chain information.
Keystone sits at the signing layer. It does not replace the wallet or node; through compatible QR integrations, it isolates the spending key, parses the request, and signs the transaction. Two products that both “support ZEC” may not support the same shielded pools or transaction capabilities. What is actually available depends on the wallet, Keystone firmware, and specific integration version.
- ✓Nodes: validate rules and propagate network data
- ✓Wallets and services: determine available features and transaction composition
- ✓Keystone: review and authorize spending offline
Check the actual path before sending
One payment address can contain multiple ways to receive
A Zcash Unified Address can contain Orchard, Sapling, or transparent receivers. The sender's wallet selects the highest-priority receiver it supports, so seeing a Unified Address does not by itself guarantee a fully shielded transaction. Before sending, confirm the receiver and source of funds the wallet will actually use.
Before moving a significant balance, test the complete send-and-receive flow with a small amount and review the destination, amount, and transaction type that Keystone actually parses. If privacy matters, avoid casually sharing transaction IDs, amounts, or counterparty information.
- ✓A Unified Address can contain multiple receivers
- ✓The sender's wallet selects a supported receiver
- ✓Test with a small amount and review the fields shown on the device
Desktop
Browser
