How to Shield Transparent ZEC

Key Facts

• Shielding does not erase the transparent deposit or its public history.
• Use a wallet-controlled internal shielded receiver rather than an external recipient during shielding.
• ZIP 315 recommends keeping funds shielded long term and avoiding opportunistic shielding inside a payment.
• Wallets should avoid combining unrelated transparent receivers in one shielding transaction because that links them.
• The current ZIP 317 conventional fee starts at 10,000 zatoshis for two logical actions and increases with transaction complexity.
• Wait for the wallet's confirmation policy before treating the shielded output as spendable.

What shielding changes

A transparent Zcash output behaves like a public UTXO: its receiving address and value are visible on-chain. Shielding spends that public output into a shielded note controlled by the same wallet. Future fully shielded transfers can protect sender, recipient, amount, and memo fields instead of carrying the public UTXO forward into ordinary spending.

The move is useful, but it is not retroactive privacy. An observer still sees the transparent address, the amount leaving it, the shielding transaction, its fee, and its inclusion in a block. What becomes private is the internal shielded destination and the protected payment details of later shielded activity.

Use the wallet's dedicated shielding flow

Choose a current wallet that documents both the transparent balance and the shielded destination it controls. In Zodl, a transparent deposit triggers a Shield prompt and the wallet creates an internal transaction into its Orchard address. Other wallets may auto-shield, expose a manual shield action, or give power users direct pool controls.

Do not copy a random shielded address from another account and improvise the transfer. A dedicated internal flow lets the wallet manage change, scanning, key scope, and the distinction between pending and spendable funds. Confirm that the destination belongs to the account you have backed up.

Read the public boundary before approving

The source transparent receiver and the value crossing from the transparent pool are public. If several unrelated transparent addresses are spent together, the transaction can link them under common control. ZIP 315 therefore recommends that wallets not auto-shield funds from multiple transparent receivers in the same transaction.

This is why shielding should be shown as a privacy transition, not a magic erase button. The transaction improves the state of the funds going forward. It cannot remove an exchange's account record, a public withdrawal amount, or the transparent address history that existed before the move.

Let the wallet calculate the fee

ZIP 317 defines a conventional fee based on logical actions. The current formula uses a 5,000-zatoshi marginal fee and a grace window of two actions, so a minimal conventional transaction is 10,000 zatoshis, or 0.0001 ZEC. Transactions with more public inputs, outputs, Sapling components, or Orchard actions can cost more.

The fee is public and can become a fingerprint when chosen unusually. Use the wallet's current default unless you understand its transaction builder and the relay consequences of underpaying. An old support page or screenshot may quote a previous flat fee; ZIP 317 is the current protocol policy reference.

Confirm, then wait for spendable status

Review the source account, amount, destination pool, and fee inside the wallet. Approve the shielding transaction and keep the wallet synchronized long enough to broadcast and recognize its own shielded output. The transaction identifier can confirm broadcast and block inclusion without revealing the encrypted destination note.

Do not immediately assume the shielded balance is spendable. Zodl currently waits for ten confirmations on incoming transactions and applies its own policy to internal change; other wallets can differ. Use the application's spendable label rather than counting blocks from a generic rule copied from somewhere else.

Do not shield and immediately mirror the amount out

A recognizable transparent deposit followed shortly by a similarly sized transparent withdrawal creates a strong timing-and-value story. The shielded pool prevents a direct readable link, but it cannot stop an observer from making an inference when the pattern is unusually exact. Zodl's shielding guidance calls out this pass-through risk directly.

Treat shielded storage as the normal state for funds intended for private use. Let wallet software manage ordinary transaction construction and spend from the shielded balance over time. Do not invent extra transparent hops; that creates more public graph without adding protocol privacy.

Handle small or fragmented transparent outputs carefully

A wallet may hold several transparent UTXOs, including tiny outputs whose value approaches the fee needed to move them. ZIP 315 says automatic shielding should not consume inputs when the fee would exceed their economic value. Power-user wallets may expose selection controls, while consumer wallets may defer or combine outputs according to policy.

Do not repeatedly retry with custom fees or consolidate unrelated addresses merely to clear a warning. Check the wallet's documentation, update to a current release, and understand whether the problem is confirmation, synchronization, dust, or unsupported receiver state before changing transaction construction.

Verify the result without exposing secrets

After confirmation, confirm that the wallet reports the funds in the expected shielded account or pool and can construct a small shielded spend. A public explorer cannot show the encrypted destination amount as your private wallet history does. That difference is the feature, not a sign that the funds disappeared.

If support is required, share the software version, sync height, public transaction identifier, and sanitized error text. Never share the recovery phrase, spending key, or full viewing key. Those credentials can expose far more than the one shielding transaction you are trying to diagnose.

FAQ