How to Send Shielded ZEC

Key Facts

• Use a wallet that can spend from a current shielded pool; recognizing ZEC is not enough.
• Let the wallet parse the complete Unified Address and confirm it selected a shielded receiver.
• A fully shielded payment encrypts sender, recipient, amount, and memo, while transaction existence, fee, and public structure remain observable.
• The current ZIP 317 conventional fee starts at 0.0001 ZEC for a transaction within the two-action grace window.
• Send a small test through the same receiver path before meaningful funds.
• Shielding cannot repair a compromised device, leaked recovery phrase, exposed exchange identity, or metadata shared off-chain.

Make sure the balance is actually spendable

Open a current shielded-capable wallet and let it synchronize before preparing the payment. Read the spendable balance, not merely the total balance. A recent receipt, internal shielding output, or change note may still be waiting for confirmations even though the amount already appears in the account.

If the funds are still transparent, use the wallet's documented shielding flow first. ZIP 315 discourages spending transparent inputs directly to an external recipient without explicit per-transaction consent because that can reveal the source address, amount, and address relationships the user did not intend to publish.

Obtain the receiver through an authenticated channel

Ask the recipient for an address generated by their current Zcash wallet and enough context to understand it: Mainnet, intended account, and whether a shielded receiver is expected. Use an authenticated conversation or invoice. For a meaningful payment, confirm the first and last characters through a second channel before approval.

Do not paste the address into a converter, extract a component manually, or trust an address delivered by a newly created support account. Clipboard replacement and compromised messaging accounts are more realistic threats than breaking Zcash cryptography. Verify the whole string where the payment matters.

Let the wallet choose the receiver

A Unified Address can package several receiver types. ZIP 316 requires a compatible sender to use the most preferred receiver it supports, which normally lets an Orchard-capable wallet choose Orchard rather than a transparent fallback. Newer `zu` variants prohibit transparent receivers, but wallet and service support still varies.

The important evidence is the review screen, not the prefix you recognize. Confirm that the wallet says shielded, Orchard, Sapling, or another specific protected receiver. If it reports transparent output or unsupported address, stop and resolve compatibility with the recipient instead of forcing the transaction through an unofficial tool.

Review what the chain will and will not reveal

For a fully shielded payment, the sender, recipient, amount, and memo are encrypted. The network still sees that a transaction exists, when it is included, its fee, expiry and version data, and public structural information such as action counts. Privacy means protected payment fields, not an invisible blockchain event.

A transparent recipient changes that boundary: the destination and amount become public. A transparent input also exposes its public history. If the wallet needs to cross a public boundary, it should say so plainly and obtain consent rather than letting a green shield icon imply more than the transaction provides.

Use the wallet-calculated conventional fee

ZIP 317 currently sets a 5,000-zatoshi marginal fee and a two-action grace window, so a minimal conventional transaction pays 10,000 zatoshis, or 0.0001 ZEC. More complex transactions can cost more. The fee is public and is designed to be calculated from public transaction structure.

Let maintained wallet software choose it. A distinctive manual fee can create an unnecessary fingerprint, and a fee below node policy may reduce relay or inclusion. If the value looks wrong, inspect the wallet version and transaction complexity before overriding it.

Treat the memo as durable payment data

Shielded outputs can carry an encrypted memo for invoice numbers, order references, or a short note. Authorized wallet keys can recover it, and a recipient may export or disclose that history later. Encryption protects the memo from ordinary chain observers; it does not make the content temporary or harmless.

Never place a recovery phrase, private key, password, government identifier, or data unrelated to the payment in a memo. If the recipient does not need one, leave it empty. A memo is useful accounting context, not a private chat channel.

Test the exact path, then send the remainder

Send a small amount to the exact receiver through the same wallet flow you plan to use for the real payment. Wait for broadcast and confirmation, then ask the recipient to confirm the amount in their wallet. This test establishes receiver compatibility, wallet scanning, fee construction, and human coordination before the meaningful amount moves.

The test is a separate transaction and pays a separate fee. That cost is not wasted when the counterparty, address type, hardware signer, or wallet version is new. Once the test arrives, re-open the original authenticated address rather than copying it from a block explorer or unverified screenshot.

Confirm in the wallet and troubleshoot with public data only

Keep the wallet open long enough to broadcast and record the transaction identifier. A public explorer can confirm transaction existence and block inclusion, but it cannot display the encrypted recipient and amount of a fully shielded payment. The sender and recipient wallets provide the authorized view of those details.

If the payment stalls, share the transaction identifier, software version, sync height, and sanitized error text. Do not share a recovery phrase, spending key, or full viewing key. A read credential can expose financial history, and a spending credential can move the funds; neither is required to prove that one public transaction reached a block.

FAQ