Zcash Wallet Troubleshooting: Not Syncing, Missing Balance, Pending or Failed Transactions (2026)

Most Zcash wallet problems that look like missing money turn out to be one of a small number of things: a wallet that hasn't finished scanning, a restore that started from the wrong block, a payment that landed on a different receiver than expected, a transaction that expired before it was mined, or — new in 2026 — funds sitting in the Orchard pool while the wallet moves them into Ironwood. This guide is organized by symptom so you can go straight to the one you're seeing, work through the safe checks in order, and know at each step what the wallet is actually doing.

Everything here applies to the current generation of Zcash light wallets on the network as it exists in September 2026. If you're arriving from older software — zcashd, ZecWallet, YWallet, or an early Ledger setup — there is a dedicated section near the end; the advice in the main sections is not written for those tools.

Each section follows the same shape: what you're seeing, the quick checks worth doing first, what the wallet is actually doing underneath, the safe next steps, and the things not to do. If your problem spans two sections — a restore that shows zero is also a balance question — read both; they cross-reference each other.

1. Wallet won't sync

Symptom: the progress indicator sits at the same percentage for a long time, the wallet says "syncing" or "stalled" on every launch, or transaction history and balance never fill in.

Quick checks, in order

1. Is the app current? Since NU6.3, a wallet version from before late July 2026 can't read Ironwood activity at all and may stop making progress near the activation height. Update from the official store listing or the project's own releases page — not from a link someone sent you.
2. Is the app actually running? Scanning only happens while the wallet is in the foreground on a device that's awake. Leaving a phone locked with the app in the background is the single most common reason a sync "never finishes." Plug the device in, keep the app open, and let it work.
3. Is there disk space? A sync interrupted by a full disk can silently stop and, in at least one wallet, also switched off Tor without saying so. Free up space and relaunch.
4. Is the server reachable? Light wallets depend on a server (see below). If your wallet exposes a server setting, switch it from a manual entry to automatic, or to a different server, and try again. Zodl, for example, selects servers automatically and only switches when another one is meaningfully faster; a stalled sync there shows a "Sync has stalled" banner with a retry option rather than spinning forever.
5. Tor or VPN in the path? Routing through Tor protects your IP address from the server but adds latency and occasionally fails outright. Turning it off for one sync to test is a reasonable diagnostic — just understand the trade-off: without Tor or a VPN, the server and your network provider can associate your IP address with the blocks your wallet requested. Turn it back on afterwards if that matters to you.

What is actually happening

A modern Zcash wallet is a light wallet. It doesn't hold the blockchain and it doesn't ask anyone for your balance, because for shielded funds nobody else can compute it. Instead it connects to a lightwalletd server, downloads a compact version of each block, and tries to decrypt every shielded output in it with your own keys. The chain of dependencies is:

your wallet → a lightwalletd server → a Zebra node → the Zcash network

A problem anywhere along that chain looks the same from the wallet's side: no progress. The scan itself is the slow part, and it's slow on purpose — trial-decrypting outputs locally is what keeps your balance private from the server. Until the wallet has scanned close to the current chain tip, it can't know which of your notes are still unspent, so it shows a spendable balance of zero, or masks the balance entirely. Current wallets are explicit about this: Zodl's engine, for instance, reports the spendable balance as "masked" until it has confirmed a fresh chain tip, and recent versions no longer display a bare zero while that's being worked out.

How far behind am I?

Compare the block height your wallet reports with the current mainnet height. ZecZcash's Halving Countdown and Mining pages show the current height, read from a third-party data source and refreshed every couple of minutes — so that figure can itself lag briefly. A gap of a handful of blocks is normal. A gap of hundreds or thousands of blocks means the wallet genuinely hasn't caught up, and nothing about your balance should be read into it yet.

If it still won't sync

Only once the app is current, the device stayed awake through a full attempt, and a server change didn't help, consider the heavier options — and only with a verified recovery phrase in hand (see the warning at the top):

• Rescan (where the wallet offers it) discards the local scan state and rebuilds it from your birthday. Your keys stay put.
• Restore from recovery phrase in a fresh install does the same, and is the only option in wallets without a rescan button. Choose the birthday carefully — section 3 explains why.
• If a full rescan repeatedly stalls at the same point, that's worth reporting to the wallet's support channel with the height where it stops. Keep the recovery phrase out of the report.

What not to do: don't uninstall as a first step, don't restore into a different wallet app just because the first one is slow (different wallets restore differently — section 3), and don't send funds anywhere "to be safe" from a wallet you can't fully see.

2. Balance is zero or lower than expected

Symptom: the wallet opens and shows 0 ZEC, or a balance noticeably lower than what you remember, or a balance that briefly appeared and then went to zero.

This is the section where the distinction that matters most is between what the wallet is displaying and what the blockchain actually holds. Most zero-balance reports are the first kind.

Display and scan states

• Not synced to the tip. As explained in section 1, a wallet can't report a confirmed-spendable balance until it has scanned to the current chain state. Zero here is a placeholder, not a finding.
• Birthday too late. If a restore started scanning at a block after your funds arrived, those notes were never seen. In the worst case a wallet can even show a negative balance: it sees you spending a note it never saw you receive. This is a known limitation of the underlying wallet library, and the fix is a restore with an earlier birthday.
• Migration in progress. After NU6.3, wallets move Orchard funds into Ironwood. While that runs, the part still in Orchard is typically counted as pending or confirming rather than available. Cake Wallet shows a "migrating to Ironwood" row under the balance; Zodl shows a banner for any residual left in Orchard afterwards.
• Transparent receiver. A Unified Address bundles several receivers, and an exchange or older wallet that can't send shielded may have paid your transparent one. The funds are real and public; your wallet will offer to shield them. Some wallets display that transparent amount separately from the shielded balance, which reads as "missing" if you were expecting one number.
• Outdated wallet, Ironwood notes. A wallet that predates NU6.3 can't recognize funds that were delivered into Ironwood — including payments to your existing address, since a current sender delivers to Ironwood now. Update the wallet and let it rescan.
• MAX isn't fundable. Zcash fees scale with the number of "logical actions" in a transaction (see section 6). A wallet holding many small notes can display a spendable total that, once the fee for spending all of them is added, can't actually be sent in one go. The balance is correct; the maximum the send screen offers isn't.

On-chain reality

If the sync is complete, the birthday is right, and the balance is still not what you expect, the remaining explanations are about the chain, not the display:

• The funds moved. Every spend from your wallet is a transaction. Check the wallet's history for sends you don't recognize — including migration self-transfers, which are legitimate — and, for anything involving a transparent address, look it up on the Explorer.
• The funds went to different keys. A payment sent to an address from a different wallet, account, or recovery phrase won't appear here no matter how long you sync. This is far more common than it sounds: a second account in the same app, a phrase from an old wallet, a hardware wallet's account rather than the software one.

What no one can promise from a zero balance alone is that the ZEC is safe — that requires finding it. What a zero balance also doesn't establish is that it's gone. Work the list above before drawing either conclusion, and don't reset the wallet while you're still investigating.

3. Restored wallet shows nothing

Symptom: you entered a recovery phrase into a fresh install, the wallet finished syncing, and the balance and history are empty — or show a different balance than the original wallet did.

What a recovery phrase does — and doesn't — restore

A recovery phrase encodes the master secret your keys are derived from. It does not contain your transaction history or your balance; those exist only as encrypted data on the blockchain. A restoring wallet has to derive the keys, then scan the chain to rediscover which outputs belong to them. Two things follow: an empty wallet immediately after restoring is expected, and the scan has to start early enough to see everything.

Wallet birthday

The birthday is the block height (or the date the wallet translates into one) where scanning starts. It exists to make restores fast: a wallet created last month doesn't need to scan ten years of blocks. But a birthday set after your first incoming payment skips the blocks that contain it, and the wallet will never see those funds until you restore again with an earlier birthday.

The rule: when unsure, choose earlier. A too-early birthday costs you time. A too-late birthday costs you visibility of your funds. Zodl estimates a birthday from the approximate date of your first transaction; if you don't know it, err toward the wallet's creation date or before.

Same phrase, different wallet, different result

A valid recovery phrase does not guarantee that every wallet app reconstructs the same accounts and history from it. Verified reasons the same phrase can show different results:

• Transparent derivation differs. Zcash-native wallets derive transparent addresses per ZIP 32; Bitcoin-style wallets (Ledger's transparent app, Exodus, Trust Wallet and similar) use BIP 44-style paths, and some rotate transparent addresses. Zkool imports "BIP 44 transparent keys" specifically for Ledger and Exodus compatibility and, after its first scan, prompts you to scan for alternative transparent addresses; Zodl added restore support for Bitcoin-style transparent address rotation and for transparent-only wallets such as Trust Wallet. If a transparent balance is what's missing, this is the first suspect.
• Word count and passphrase. Zcash-native phrases are 24 words. A 12-, 18- or 21-word phrase usually comes from a different wallet family; Zkool accepts several lengths plus an optional passphrase, while Zodl restores 24-word phrases (12-word support was still an open request at the time of writing). A BIP 39 passphrase, if one was set, is part of the key — omit it and you restore a different, empty wallet.
• Legacy Sapling keys. Wallets from the zs1 era sometimes hold Sapling extended spending keys rather than a phrase. Zkool can import those directly; a phrase-only wallet can't.
• Imported keys. Any key you imported separately (a transparent private key, a viewing key, a legacy shielded key) was never derived from the phrase and won't come back with it.
• View-only accounts restore as view-only. They show funds but can't spend them, and were never meant to.
• Post-NU6.3 scanning. The NU6.3 wallet rules require a restoring wallet to scan for two possible key configurations until it can tell which one the account used. An up-to-date wallet does this automatically; an old one may miss Ironwood-era notes. Restore with a current release.
• Hardware wallets derive their own accounts. A hardware wallet's funds appear when the software wallet is paired with the device (Zodl with Keystone; Zkool with Ledger via Ledger's own documented connection), not when its phrase is typed into a phone.

If Zodl unexpectedly shows the onboarding screen

A recent Zodl release returns to onboarding when it finds the device's secure key store empty (after certain OS-level restores, for example). That is a prompt to restore from your recovery phrase, not to create a new wallet. Creating a new wallet doesn't destroy anything on-chain, but it gives you an unrelated empty wallet and a second phrase to keep track of.

What not to do: don't keep restoring the same phrase into more and more apps hoping one shows the balance — each restore is another place the phrase now lives. Identify which wallet and which derivation the funds were originally received with, then restore once, deliberately, into a wallet that supports it.

4. ZEC sent but not received

Symptom: someone (or an exchange, or you from another wallet) sent ZEC, and it hasn't appeared where you expected.

Step 1 — get the transaction ID

Every Zcash transaction, shielded or not, has a public transaction ID (TXID). The sender's wallet shows it in the send confirmation or history; an exchange shows it in the withdrawal record, sometimes after a delay. Sharing a TXID reveals nothing beyond the fact that the transaction exists — it is safe to ask for and to give.

No TXID yet? Then the payment may not have been broadcast at all. Ask the sender to confirm the transaction actually shows as sent (not "Sending…" or failed) in their wallet, and to share the ID once it does.

Step 2 — look it up

Paste the TXID into the ZecZcash Explorer. There are four outcomes:

Not found. The transaction isn't in the Explorer's data. That can mean it was never broadcast, that it expired before being mined (section 5), that the ID was copied incompletely (it's exactly 64 characters), or that the Explorer's own data provider doesn't have it right now. "Not found" does not by itself prove the transaction expired — the Explorer can't see expiry — so treat it as "no evidence it was mined" and go back to the sender.

Unconfirmed. The Explorer has seen it, but it hasn't been included in a block. Wait. If it stays unconfirmed for more than about an hour, it has most likely expired and needs to be re-sent.

Confirmed, with a transparent output. The Explorer shows the transparent destination address and the amount. If that address is yours, the funds are on your transparent receiver — sync, then shield them. If it's an exchange's deposit address, the remaining question is on the exchange's side (section 7). If it's an address you don't recognize, the sender used the wrong destination, and no amount of syncing on your side will change that.

Confirmed, with shielded activity. The Explorer can prove the transaction exists and is confirmed, and can show which shielded pools it touched and — for the pools it models — how many shielded actions it contains and the net value that crossed a pool boundary. It cannot show who received it, how much any individual shielded transfer moved, or the memo. That's the design working. From here, the recipient's wallet is the only place the payment can be seen: make sure it's fully synced (section 1) and, if it's a fresh restore, that its birthday predates the payment (section 3). If the sender attached a memo, it appears only in the recipient's wallet.

What not to do

Don't send the payment again because the first one hasn't shown up "yet." Confirm the first one's state first — a still-live transaction and a duplicate can both confirm. And don't treat an exchange or third party as able to "look into" a shielded destination it doesn't control: nobody can.

5. Transaction pending or expired

Symptom: a send has been sitting at "pending," "sending," or "awaiting confirmation" for a long time, or your wallet has marked a transaction as expired.

How Zcash handles a transaction that isn't mined

When a Zcash wallet builds a transaction, it stamps it with an expiry height. If the transaction hasn't been included in a block by that height, nodes remove it from their mempools and it can never be mined in that form. That rule (ZIP 203) exists precisely so an unconfirmed transaction can't hang around forever, and it's why Zcash has no "stuck for days" state the way some networks do.

The default a wallet sets is 40 blocks ahead. Under the current, pre-NU7 block timing of about 75 seconds per block, that is roughly 50 minutes. NU7 is expected to shorten the target block time substantially; if it activates, check whether the default expiry in blocks has been adjusted before assuming the same number of minutes.

Three consequences for troubleshooting:

• Broadcast is not confirmation. A wallet saying "sent" means a server accepted the transaction. It can still expire unmined. Current wallets are more explicit here — Zodl now shows "Sent · awaiting confirmation" rather than an indefinite "Sending…" once a server has accepted a transaction — but the distinction is the same everywhere.
• Expired means re-send. Once expired, the transaction is gone from the network and the funds never left your wallet. Your wallet's balance returns to what it was (sometimes only after its next sync), and you make the payment again. Nothing was lost; nothing needs to be "recovered."
• Don't duplicate a live transaction. If the transaction is still within its expiry window, sending a second one doesn't speed the first up — and both can confirm. Wait out the window (or check the TXID on the Explorer) before re-sending.

What to do while it's pending

Keep the wallet open and synced. If the wallet reports a broadcast failure rather than a pending state, that's section 6. If the Explorer shows the transaction as confirmed but your wallet still says pending, the wallet is behind the chain — sync (section 1).

About confirmations

There is no protocol-defined number of confirmations that makes a Zcash transaction "final." Wallets and exchanges each choose their own thresholds, and those thresholds change. A transaction with zero confirmations should never be treated as settled — that's true on every blockchain, and ZIP 203's own text says as much for Zcash. Beyond that, use the threshold the receiving party publishes, not a number from an article.

6. Transaction failed

Symptom: the wallet reports an error when you try to send, or a send that appeared to go out is later marked failed.

Causes, most common first

1. The wallet is outdated. Since NU6.3, the network rejects any transaction that tries to create a new Orchard output for someone else. A wallet built before Ironwood still tries to do exactly that when it pays a shielded address, and the transaction fails at the network — often with an unhelpful error. Update the wallet. This is the single most common "failed" cause in late 2026.
2. Chain state changed between review and confirmation. If a note you were about to spend got spent (by a migration transfer, for instance) or a new block arrived that invalidated the proposal, the send fails. Wallets increasingly say so — Zodl added explicit messaging for this case — and the fix is simply to let the wallet sync and try again.
3. Insufficient funds for the fee. See below.
4. Not synced. A wallet that hasn't reached the chain tip may be trying to spend notes whose status it doesn't actually know. Sync first.
5. Server or broadcast problem. Transient. Current wallets retry broadcast in the background and, in Zodl's case, broadcast to several servers at once; if the failure persists, switch servers (section 1).
6. Hardware signing. Keystone paired with Zodl needs firmware 3.0.2 or later (the "Cypherpunk" edition) to sign Ironwood or migration transactions. Older firmware fails at the signing step.

Fees, and why "insufficient funds" can be right and wrong at the same time

Zcash fees are not a flat 0.0001 ZEC. Under ZIP 317, the fee is proportional to the number of logical actions a transaction contains — roughly, how many notes it spends and creates across the transparent and shielded parts — at 5,000 zatoshi per action, with a minimum of two actions. A simple payment costs 10,000 zatoshi (0.0001 ZEC); a payment that has to gather many small notes costs more, and the change output adds an action of its own. The transaction fee glossary entry has the short version.

This is where "MAX" can mislead. A wallet's spendable total is correct, but the fee to spend all of it depends on how many notes that involves — and the change output the wallet adds can push the transaction over the fee it quoted. At the time of writing, Zingo's mobile wallet has a confirmed, open bug of exactly this kind: pressing MAX proposes an amount the wallet then can't fund, and typing a slightly smaller amount (a fraction of a cent less) succeeds. That workaround — send slightly less than the displayed maximum — is safe in any wallet, because it only ever leaves a little more behind as change. Just be clear about what it is: a wallet-side bug being sidestepped, not a rule of the protocol.

What not to do

Don't "fix" a failed shielded send by moving the funds to a transparent address and sending from there — you'd be trading a wallet update for your privacy. Don't retry in a loop against the same error; each failure has a cause above, and the first three are all resolved by updating and syncing.

7. Exchange deposit or withdrawal problems

Symptom: an exchange hasn't credited a deposit, has rejected your withdrawal address, or a withdrawal from an exchange hasn't reached your wallet.

Exchange policies change often, so this section stays deliberately general. For what individual exchanges currently support, ZecZcash maintains a directory of exchanges with Zcash support and updates it separately from this guide.

Withdrawing to your wallet

• "Invalid address." Most exchanges only send ZEC to transparent addresses. If you pasted a Unified Address (u1…) or a Sapling address (zs1…) and the exchange refused it, that's the exchange's limit, not a problem with your address. Give it your wallet's transparent address instead — every current wallet shows one (in Zodl: Receive → Transparent Address). A small number of exchanges do support Unified or shielded withdrawals; where yours does, use that.
• Funds arrived, but on the transparent side. Expected when the exchange paid a transparent address, and also possible when it paid a Unified Address without shielded support: the sender picks the most private receiver it supports, and for an exchange that is usually the transparent one. Shield the funds once they arrive; until then they're publicly visible on the chain, like a Bitcoin balance.
• Withdrawal shows "complete" but nothing arrived. Get the TXID from the withdrawal record and follow section 4. If the Explorer shows it confirmed to your transparent address, sync your wallet.

Depositing to an exchange

• Use the exchange's current deposit address. Some exchanges rotate deposit addresses; a payment to an old one may not be credited automatically. Check the address in the exchange's deposit screen at the moment you send.
• Send from a transparent address, or deshield first. If the exchange states that it only accepts transparent deposits, a payment from a shielded pool that lands on the exchange's transparent address is still a transparent receipt on their side and is normally fine — but a few venues restrict what they credit, and some (Kraken, at the time of writing) state that they won't accept mining block-reward payouts sent directly to a deposit address. Read the exchange's own deposit page.
• Confirmations. Exchanges credit deposits after their own confirmation threshold, which they publish and change. If the Explorer shows your transaction confirmed to the exchange's transparent deposit address and the exchange still hasn't credited it after its stated threshold, the remaining steps are with the exchange's support — you have the TXID and the on-chain proof they need.
• Around upgrades, deposits pause. Exchanges routinely suspended ZEC deposits and withdrawals around the July 28 Ironwood activation, and will likely do so again around NU7. A deposit sent during a pause is usually credited once processing resumes, but confirm the exchange's notice before sending.

What an exchange cannot do is look inside a shielded destination it doesn't control. If you sent to your own shielded address by mistake instead of the exchange's deposit address, the funds are in your wallet, not lost, and no exchange can see or retrieve them for you.

8. Orchard and Ironwood: migration questions

Symptom: the wallet says part of your balance is "in Orchard," is "migrating," won't let you spend it, or you see several outgoing transactions you didn't create.

What changed

Zcash's shielded funds live in pools. Orchard was the current pool from 2022 until July 2026. After a flaw was found in Orchard's proof circuit in May 2026, the NU6.3 upgrade introduced a new pool, Ironwood, built on a corrected design, and changed the rules for Orchard: value can still leave the Orchard pool — to Ironwood, to Sapling, or to a transparent address — but no new value may enter it, and Orchard-to-Orchard payments between different addresses are no longer allowed. Ironwood is where new shielded activity goes.

This is what "Orchard is exit-only" means, and it is the whole of it. Your Orchard funds were not moved, frozen, or taken by the upgrade. They are yours to spend out of the pool, and the recommended way to do that is to migrate them into Ironwood.

The facts, plainly

• Nothing was lost or locked. The upgrade changed what can go into Orchard, not who controls what's already there.
• No new address is needed. Ironwood didn't change address formats. Your existing Unified Address keeps working, and a current wallet delivers new payments to it into Ironwood.
• There is no protocol deadline. ZIP 318, which defines the migration, sets no cut-off. That said, Orchard is a pool you can only spend out of, so there's no reason to leave funds there indefinitely, and the wallet ecosystem's guidance is to migrate.
• Migration requires a current wallet. An app that predates NU6.3 can't build Ironwood transactions, so it can neither migrate Orchard funds nor spend them to an Ironwood recipient. Until you update, those funds look unavailable; that's the wallet, not the chain.

How migration works in your wallet

Current wallets offer a guided flow — Zodl calls it "Move to Ironwood" and has offered it since early August 2026; Cake Wallet starts migration automatically the first time you open a synced wallet holding Orchard funds; Zkool, Zingo, and Unstoppable Wallet ship their own. Most present two options, which come straight from ZIP 318:

• Migrate immediately. One transaction moves everything. Fast, but the full amount crossing the pool boundary in a single step is visible on-chain as a net pool flow.
• Migrate with privacy. The wallet splits your balance into standard round amounts — 1, 2 or 5 times a power of ten ZEC (100, 50, 20, 10, 5, 2, 1, 0.5 … down to 0.01 ZEC) — and sends each one as its own transaction on a randomized schedule, with delays that can each be an hour or more. Because the amounts are standard and the timing is staggered, an observer can't tell your migration apart from anyone else's.

You confirm the plan once; the wallet then broadcasts the individual transfers in the background while it's open and synced. This is why, after choosing the private option, you'll see several outgoing transactions you didn't manually create. Each is a transfer from your own wallet to your own wallet. Cake Wallet's documentation says it well: they can look alarming, but they are your own funds moving between your own pools.

Two things that look wrong but aren't

• A small amount stays in Orchard. The private migration works in fixed denominations, so a remainder below 0.01 ZEC is left behind by design. Zodl shows a banner for it and offers to sweep it (which is identifiable on-chain) or leave it locked so it isn't accidentally spent. A tiny leftover is not a failed migration.
• The available balance drops while migrating. Funds in flight are counted as confirming, not available. Cake Wallet labels this "migrating to Ironwood" under the balance; the available figure climbs back as each transfer confirms.

If migration is stuck

Keep the app open and synced — background transfers only broadcast while the wallet is running. Update the app: early migration releases had real bugs (Zodl fixed a case where migration "got stuck on transient failures" and another where wallets "didn't detect spendable funds after migration," both in August 2026). For Keystone users, signing migration transactions requires firmware 3.0.2 or later on the Cypherpunk edition; note that Keystone states this firmware can't be downgraded to the standard Multi-Coin or BTC-only editions afterwards. If a wallet still shows unmigrated Orchard funds after all of that, its support channel needs the wallet version and what the migration screen shows — never the recovery phrase.

Wallet-by-wallet, briefly

Zodl (formerly Zashi)

Guided "Move to Ironwood" flow since v3.9.0 (August 2026), with immediate and private options; a home-screen banner for residual Orchard ZEC; Keystone signing supported for migration with firmware 3.0.2+. Migration and post-migration balance bugs were fixed through 3.9.x — update if you're on an earlier build. Zodl and Zashi are the same app: the rename in February 2026 arrived as an update, with no reinstall and no new phrase.

Cake Wallet

Migration starts automatically on the first synced open; the unmigrated portion shows as "migrating to Ironwood" under the balance and is counted as confirming until each chunk lands. Multiple outgoing self-transfers are expected. A residual below 0.01 ZEC in Orchard is normal.

Zkool, Zingo, Unstoppable Wallet

All three ship Ironwood support and Orchard-to-Ironwood migration in their current releases. Zkool is also the destination for former YWallet users (see the legacy section). Unstoppable Wallet's recent releases added stall detection and automatic server switching on iOS, which matters here because migration transfers only broadcast while the wallet is synced.

Brave Wallet

Brave's built-in wallet has offered shielded ZEC on desktop since 2025 and has been building Ironwood support through 2026; the change enabling it by default was merged into Brave's development builds on September 23, 2026. Whether the Brave version you're running includes it depends on your release channel — check the release notes for your version before relying on it, and if your Brave wallet holds Orchard funds it can't yet move, waiting for the update is the safe option rather than moving the phrase elsewhere.

Keystone 3 Pro

Ironwood and batch signing arrived in Cypherpunk-edition firmware 3.0.2 (July 27, 2026); Zodl's migration walkthrough requires it. Keystone notes that once upgraded, the device can't be downgraded to the 3.0.0 Multi-Coin or BTC-only firmware.

What not to do

Don't move Orchard funds to a transparent address "to get them out" — you'd give up the privacy the migration is designed to preserve, for no benefit. Don't treat the ZecZcash Explorer as a way to verify migration amounts yet (see section 4); your wallet's history is the reference. And don't let the exit-only rule read as urgency: it's a reason to migrate at a calm moment with a current wallet, not a reason to do anything hastily.

Reference: how a Zcash light wallet syncs

The wallet holds your keys. A lightwalletd server, run by the wallet team or a community operator, sits in front of a full node (Zebra, since zcashd's retirement) and serves compact blocks over an API. The wallet downloads those, and for every shielded output in them tries a decryption with its own keys; successes are your incoming notes. It also tracks nullifiers — the public markers that reveal a note has been spent, without revealing which — so it knows which of your notes are still unspent. Your balance is the sum of the unspent ones, computed entirely on your device.

The server therefore learns your IP address and which blocks you asked for, but not your keys, your balance, or your addresses. Tor or a VPN hides the IP; nothing hides the fact that a scan is expensive, which is the honest reason syncs take as long as they do. Full details and the privacy trade-offs are on the Zcash privacy page.

Reference: address types and receiver selection

Zcash has three address formats you'll meet, and one rule that explains most surprises:

• Transparent — t1… (and t3…): public, Bitcoin-like. Balance and history are visible to anyone. See transparent addresses.
• Sapling — zs1…: the older shielded format. Still valid, still private; most current wallets no longer generate new ones. See shielded addresses.
• Unified — u1…: the current format. A Unified Address is a container that can hold several receivers at once — typically a shielded receiver plus a transparent one. It is not "an Orchard address" or "an Ironwood address"; it's a bundle, and Ironwood didn't change its format or its contents.

The rule: the sender's wallet chooses the most private receiver it supports from the bundle. A current wallet paying a Unified Address delivers into the Ironwood pool. An exchange or an older wallet that only understands transparent addresses pays the transparent receiver inside the same address — which is why a payment to your u1… address can arrive as a public, transparent balance that your wallet then offers to shield. The receiving wallet had no say in it.

Shielded vs. Transparent Zcash Transactions Explained covers the privacy consequences of each format; the Unified Address entry has the short definition.

Reference: what a block explorer can and cannot prove

That is the same boundary the ZecZcash Explorer draws: searching a shielded or Unified address there confirms the address is validly formed and nothing more, because the blockchain contains nothing that links a shielded address to any transaction. Net pool flow is the one item people don't expect — moving ZEC out of a shielded pool to a transparent address reveals the amount that crossed, and so does a single-transaction migration between pools, which is exactly why the privacy-preserving migration in section 8 exists.

Reference: viewing keys, and why to be careful with them

A viewing key lets its holder see the transactions of a shielded account without being able to spend from it. Zcash defines full viewing keys (incoming and outgoing history) and incoming viewing keys (incoming only), and some wallets — Zkool, for example — can import one to create a view-only account. That's a legitimate tool for your own accounting or for a bookkeeper you trust.

It is not a casual proof-of-payment mechanism. Sharing a viewing key discloses the entire history of that account, past and future, and the disclosure can't be revoked — there is no way to un-share it. If you need to prove a single payment to someone, the recipient's own wallet, the TXID, and the memo are the proper evidence; older "payment disclosure" features from the zcashd era were experimental, never covered current pools, and are not part of any mainstream wallet today. Don't let anyone talk you into exporting a viewing key as a "verification" step.

Legacy wallets: zcashd, ZecWallet, YWallet, old Ledger setups

If your Zcash lives in software from an earlier era, the sections above don't apply directly, and the instructions you'll find in old documentation are for tools that no longer run on today's network. This is the current situation for each:

• zcashd (the original node and wallet) stopped for good at block 3,417,100 on July 18, 2026. Commands from its documentation — -rescan, -reindex, zcash-fetch-params, zcash-cli, backing up wallet.dat — belong to that software and are not steps a 2026 wallet user should follow. If you still hold a wallet.dat, the maintained path is Zallet, the zcashd wallet's successor, which is aimed at node operators and was still in beta at the time of writing (and had an open issue about spending some very old transparent outputs). For most people, the practical route is to export the relevant keys or phrase with the tools you have and restore them into a current wallet that accepts legacy keys — Zkool imports Sapling extended keys and Bitcoin-style transparent keys. Do this deliberately, once, and move the funds on to a fresh wallet afterwards.
• ZecWallet (Lite and full-node) is unmaintained, and its public servers are down. Restore its 24-word phrase into a current wallet, with a birthday from when you first used it.
• YWallet removed Zcash support entirely on August 23, 2026; it continues only as a Ycash wallet. Its developer's successor app, Zkool, accepts the same phrases and keys. Don't follow guides that still recommend YWallet for Zcash.
• Nighthawk is no longer a Zcash wallet at all; the project moved to a different network. Restore its phrase into a current wallet.
• Ledger. Two different things carry the Ledger name. Ledger's own app (in Ledger Live / Ledger Wallet) handles transparent ZEC only, and Ledger's support documentation has noted that shielded transactions and some very old transparent transactions aren't supported there; if you hold pre-2018 ZEC on a Ledger, check Ledger's current Zcash support article before assuming either way, and use Ledger Live's coin-control feature to select spendable outputs where it offers one. Separately, a Zcash Shielded app for Ledger exists as of mid-2026: per Ledger's support article (last updated July 21, 2026) it runs on the Nano S Plus, Stax and Flex, and is not yet available on the Nano X or Nano Gen5; it pairs with companion wallets such as Zkool, which Ledger documents connecting to directly. Which shielded pools the shipped app covers is something to confirm in Ledger's and the companion wallet's current documentation rather than assume.
• Trezor supports transparent ZEC only. There's nothing to troubleshoot on the shielded side because there's no shielded side.

The wallet directory lists what every wallet currently supports; How to Choose a Zcash Wallet and Best Zcash Wallets in 2026 cover picking a current one.

Getting help without getting scammed

Wallet support exists — Zodl, for example, takes support only by e-mail and states that it will never message you first on Discord, Telegram, X or anywhere else, and that anyone asking for your recovery phrase or steering you to file a ticket somewhere other than its published address is a scam. That pattern holds for every legitimate project.

When you ask for help, share: the wallet name and version, the device and OS, what the screen shows, the block height it reports, and — for a specific payment — the TXID. Never share the recovery phrase, spending keys, or a viewing key, and don't screen-share a wallet with anyone who contacted you. If a "support agent" needs any of those to help, they aren't support.

ZecZcash is an independent community site; we don't operate a wallet and can't see your funds. If you believe this guide is wrong or out of date, tell us through the contact page — the network and the wallets around it change quickly, and the verification date at the top of this page is when these facts were last checked.

Sources

Protocol rules referenced above are from the Zcash Improvement Proposals as published in the zcash/zips repository: ZIP 203 (transaction expiry), ZIP 229 (v6 transaction format), ZIP 258 (NU6.3 deployment), ZIP 316 (Unified Addresses), ZIP 317 (fees), ZIP 318 (Orchard-to-Ironwood migration) and ZIP 326 (NU6.3 consequences for wallets). Node and activation facts are from the Zebra release notes and the zcashd end-of-support notice; wallet behavior from the published changelogs, repositories and support articles of Zodl, Zkool, Zingo, Cake Wallet, Unstoppable Wallet, Brave, Keystone and Ledger, as of the verification date shown above. The Zcash network upgrades timeline gives the dates and heights of every upgrade mentioned here.