Short answer

To receive ZEC safely, generate the address inside a current shielded-capable wallet, learn which receiver the sender can use, share the complete address through an authenticated channel, and prove the path with a small deposit. A Unified Address improves coordination, but the sender's wallet still chooses the actual receiver and therefore the privacy path.

Key Facts

  • A Unified Address is a container of receivers; the sending wallet selects the most preferred receiver it supports.
  • A fully shielded receipt encrypts the recipient, amount, sender, and memo while transaction existence, fee, and public structure remain observable.
  • A transparent deposit publishes the transparent receiver and amount, even if the funds are shielded later.
  • Copy the complete address from the wallet and never use an unofficial address converter.
  • Wait for wallet synchronization and the wallet's required confirmations before treating ZEC as spendable.
  • Use a small test when the sender, exchange, receiver type, or wallet support is uncertain.

Start with the sender's actual capability

Receiving ZEC is not just displaying a QR code. First identify who is sending: a modern shielded wallet, an exchange, a hardware-backed account, or software that only understands transparent Zcash. The same receiving wallet can expose more than one route, and those routes do not publish the same information.

If both sides support a current Unified Address and a shielded receiver, that is normally the cleanest path. When a service accepts only a transparent address, do not pretend the payment is private. Treat the deposit boundary as public, then use the wallet's documented shielding flow before later spending.

Generate the receiver inside the wallet

Open the receive screen in the authentic wallet application. Read the account label, network, and receiver description before copying anything. A Unified Address may contain Orchard, Sapling, and sometimes transparent receivers. ZIP 316 requires a compatible sender to choose the most preferred receiver type it supports, but an old or limited sender may reject the address instead of using the shielded component.

Do not manually extract a receiver from a Unified Address, shorten the string, or paste it into a website that promises to convert formats. That changes a wallet-mediated decision into a manual security decision. If compatibility fails, return to the receiving wallet and use an address type it explicitly generates for that purpose.

Share the complete address in the right context

Use the wallet's copy or QR function and send the address through a channel where the other person can verify it came from you. For a meaningful transfer, confirm the first and last characters through a second channel. Clipboard malware and account takeovers are more ordinary than protocol failures, which is precisely why boring verification works.

Give the sender context with the address: Zcash Mainnet, the wallet or service it came from, and whether a shielded receiver is expected. Do not post a payment address beside personal details unless that association is intentional. Shielded receivers protect on-chain payment fields, not the identity information you publish around them.

Handle exchange withdrawals honestly

Many exchanges still accept only transparent Zcash withdrawal addresses. Zodl's current exchange-deposit guidance tells users to select its transparent receive address when a platform rejects the shielded one, then shield the incoming balance inside the wallet. That is a compatibility workaround, not a private withdrawal.

A transparent withdrawal exposes the receiving address and amount on-chain and may connect that address to an identified exchange account off-chain. Shielding afterward protects later shielded payment fields, but it cannot erase the public deposit or the records held by the exchange. Keep that boundary visible in your own records.

Use a test deposit before the real one

Send a small amount through the exact path you intend to use. A test catches the wrong network, unsupported receiver, stale wallet, scanning problem, or mistaken account before the meaningful amount moves. The extra transaction pays another network fee; that is cheaper than discovering a compatibility mistake with the full balance in flight.

Wait for the receiving wallet to synchronize and recognize the payment. A public explorer can confirm that a transaction exists, but it cannot display the encrypted recipient and amount of a fully shielded receipt. The wallet's own scanning and activity history are the authoritative user view for those details.

Separate received from spendable

A wallet may show a payment before it is safe to spend. Zodl currently requires ten confirmations for incoming transactions and three confirmations for change, while other wallets may implement different policies. Read the application's labels for pending, total, and spendable balance rather than assuming that a visible number is immediately usable.

Wallet synchronization matters as much as confirmation count. A device that has not scanned to the chain tip can miss a valid shielded note or show an old spendable balance. Let it complete the scan before reinstalling, restoring, or exposing recovery material in a panic.

Use memos as payment data, not a secret vault

A shielded output can carry an encrypted memo that compatible authorized wallet keys can read. That is useful for invoice references or payment context, but it is not an invitation to include passwords, recovery phrases, identity documents, or information the recipient does not need.

The memo is retained with the payment and may later be visible to someone holding relevant viewing authority or a wallet-history export. Write it as durable financial context. If the sender does not need a memo, leaving it empty usually creates less data to manage.

Troubleshoot without leaking the wallet

If the payment does not appear, first check the sender's transaction status, the receiver type selected, your wallet's sync height, and the confirmation policy. Confirm the address was copied completely. An explorer miss is not proof that a shielded payment failed because the protected destination is not a public search key.

Share a transaction identifier or sanitized screenshot only when necessary, and remove account labels or other unrelated activity. Never give support a recovery phrase, spending key, or full viewing key. Those credentials solve a different problem by exposing the wallet itself.

FAQ

What address should I use to receive ZEC?

Use an address generated by your current wallet. Prefer a Unified Address with a supported shielded receiver when the sender can use it; use a transparent address only when compatibility requires it and accept that the deposit will be public.

Is a Zcash Unified Address always private?

No. It can package several receiver types. The sending wallet chooses the actual supported receiver, so privacy depends on that selection and the complete transaction path.

Why can I see received ZEC but not spend it?

The transaction may still need confirmations, the wallet may still be scanning, or transparent funds may need shielding before the wallet treats them as spendable.

Can a public explorer confirm a shielded deposit amount?

No. It can show public transaction structure and inclusion, but the recipient and amount of a fully shielded output remain encrypted. Use the receiving wallet's scanned history.