Storing ZEC is mostly the same job as storing any other crypto asset, and there is 1 part that is not. If you hold shielded funds, restoring your wallet from a seed phrase needs a second piece of information alongside the phrase, and almost nobody tells you that before you need it.
That second piece is a block height, usually called the wallet birthday. Without it a restore still works, it just takes far longer and your balance can look wrong while it runs.
Search for how to store Zcash and you get nothing at all. Search for a Zcash wallet and you get twenty-five rows: wallets, directories of wallets, plus one address-lookup tool. Not one of them mentions a birthday height.
What you are actually protecting
Before anything else, it helps to be precise about what has to survive. People say "back up your wallet" as if the wallet were the thing, and it usually is not. Three different objects get confused, and they have very different properties.
The seed phrase is the thing that matters. It is a short list of words from which every key in your wallet is derived mathematically. Anyone holding it can recreate every key you have, including keys you have not generated yet.
The keys are derived from the seed. You rarely handle them directly, and in Zcash there are several kinds, including viewing keys that let someone see your transactions without being able to spend.
The wallet file or app is software. It holds the seed. It tracks your balance and stores a local record of what it has already scanned. Losing it is inconvenient. Losing the seed is permanent.
Zcash adds a fourth object most assets do not have. Viewing keys let someone read your shielded activity without being able to spend from it. The specification that bundles modern Zcash addresses also "defines Unified Viewing Keys, which perform a similar function for Zcash viewing keys" (source: ZIP 316).
That is worth knowing at backup time rather than afterwards. A viewing key handed to an accountant or a tax tool is a permanent disclosure of everything that key can see, and it is not revocable in the way a password is.
Our guide to how crypto wallets work covers the general structure, and our guide to backing up a seed phrase covers the handling that applies to every asset, not just this one.
Everything from here is what Zcash adds on top of that.
One seed, more than one tree
Zcash derives keys from a seed the same way most modern wallets do, using a hierarchical scheme where a single root produces an entire structure of keys. The Zcash version of that scheme is specified, mature and marked Final, so this is settled ground rather than a moving target.
What is different is that Zcash has more than one shielded protocol, and each needs its own key structure. The specification says so directly: it defines "(mostly) equivalent, but independent, systems for deriving a tree of key components from a single seed" for the shielded pools, naming Sapling and Orchard (source: ZIP 32).
So one seed phrase sits at the root, and beneath it are separate derivation trees, one per pool, plus transparent keys derived the older way. That is invisible in normal use because the wallet handles it.
It becomes visible in exactly one situation, which is a restore. A wallet recovering from your seed has to rebuild every one of those trees. Then it has to work out which notes in the chain belong to which tree. That second half is the part that takes time.
There is a practical consequence worth stating. Because the trees are independent, a wallet that supports one pool and not another can hold your seed and still show you an incomplete picture, and it will not necessarily tell you that it is doing so.
That describes a wallet implementing part of the specification rather than a bug. That is normal, and the wallets article in this series covers it in detail.
Our guide to hierarchical key derivation covers the general scheme this extends.
The birthday height, and why a restore needs it
Here is the Zcash-specific trap. A shielded wallet cannot simply ask the network for your balance, because the network does not know which payments are yours. The amounts and addresses are encrypted, so the only way to find your funds is to download blocks and try to decrypt each shielded output with your keys.
That works. It is also slow, and how slow depends entirely on where the wallet starts scanning.
The reference implementation gives the concept a name and a precise definition. The birthday height is described as the height "of the first block to be scanned in wallet recovery". It lives in a structure whose stated job is "to set the birthday height for an account, and ensure that the initial note commitment tree state is recorded at that height" (source: zcash_client_backend).
In plain terms: the birthday is the block height at which your wallet was created, and a restore only has to scan from there forward. Anything before it cannot contain your funds, because your keys did not exist yet.
Write it down when you create the wallet. If you cannot get the height, note the date instead. Wallets that accept a date convert it to an approximate height and start a little earlier for safety, and an approximate height is worth far more than none.
If you have lost it, a restore still succeeds. The wallet just scans from much further back, which on a phone can mean a very long wait and a lot of data.
None of this is an obscure implementation detail. The birthday is a first-class object in the reference wallet backend, which exposes AccountBirthday and a birthday_height accessor on its account type.
One more reason to record it: the birthday is a fact about your wallet that no amount of cryptography can recover for you. Your seed can rebuild every key you have ever had, and it cannot tell any software when you first used them.
What a restore actually does, and why your balance may look wrong
The scan is not instant, and while it runs your wallet knows about part of your history and not the rest. That produces an effect worth expecting in advance. If it surprises you it looks exactly like money going missing, and that is the moment people make decisions they cannot take back.
What the wallet is doing during that time has a name in the reference code. Its scanning module provides "tools for scanning a compact representation of the Zcash block chain". They are built around "a set of keys to be used in scanning for decryptable transaction outputs", plus a trait for performing trial decryption (source: zcash_client_backend scanning).
Trial decryption is the operative phrase. The wallet is attempting to open every shielded output it encounters, and the ones that open are yours.
The same documentation that defines the birthday height also names the user-facing problem and its mitigation. Wallets may set a "recover until" height, and the wallet "is considered to be in 'recovery mode' until there exist no unscanned ranges between the wallet's birthday height and the provided recover_until height, exclusive". The stated reason is "to avoid confusing shifts in wallet balance and spendability that may temporarily be visible to a user during the process of recovering from seed".
Read that carefully, because it is a rare thing to find in developer documentation: an explicit acknowledgement that a partly-restored wallet shows numbers that will change.
What it means for you is simple. A balance that appears low during a restore is not evidence of a problem, and neither is a balance that goes up as scanning proceeds. Both are the expected behavior of a process that is still working through blocks.
The practical response is to let it finish before concluding anything. If a wallet offers a recovery-mode indicator, that indicator is the thing to watch rather than the balance.
Our guide to reading a block explorer covers how to check the transparent side of your history independently, which is possible in a way the shielded side is deliberately not.
Where your value actually sits while you move it
Storage is not only a question about the destination. There is a moment during any move off an exchange when the value is between places. On Zcash that moment has a property worth knowing about beforehand rather than after, because once it is on the chain it is permanent.
Value leaving an exchange arrives at an address you control. If that address is transparent, the arrival is a public event: the amount, the sending address and the receiving address are all visible to anyone. If the destination is shielded, the arrival is not.
The transparent side also carries a rule that only exists because of how venues receive deposits. A specification defining a distinct encoding for transparent addresses states that "wallets must ensure that no shielded notes are spent in transactions that send to a transparent address encoded in the specified fashion" (source: ZIP 320).
The detail matters less than what it demonstrates: the boundary between shielded and transparent is where the rules get complicated, and it is exactly the boundary a deposit or a withdrawal crosses.
That is a storage decision as much as a privacy one, because it determines what a future observer can reconstruct about your holdings. What an analyst can reconstruct from those public events is the traceability article's subject in this series, and it is pointed at here rather than repeated.
The exchange side of the same move is covered by the trading article in this series. Our guide to how exchange custody works covers what a venue holds on your behalf before you move anything, and our guide to what self-custody means covers the choice itself.
Two things are worth separating. Whether your funds are safe is a question about keys. Whether your holdings are private is a question about which addresses you used and when. Good storage answers the first and only partly answers the second.
Why old backup instructions still circulate
Most Zcash backup instructions you will find describe zcashd, the original full node. That documentation is detailed, thorough and still online. It is also being retired, and the project says so: users of that node and wallet "should migrate to these alternatives", naming its successors (source: zcash/zcash).
That matters here because the old documentation carries a caveat that is easy to read past. Its wallet export "includes a comment with an HD wallet seed and associated fingerprint", and that seed "is only for the wallet's Sapling shielded keys and addresses". The same page states that the import command "does not yet support importing HD seeds" (source: Zcash documentation).
So an export from that software could contain a seed that its own import command would not restore, and a seed that covers one pool rather than all of them. Anyone treating that file as a complete backup would be wrong twice.
The lesson generalizes past this particular software. A backup is only a backup if you know what it contains and have confirmed the thing that reads it can read it. An exported file that has never been restored is an assumption, not a backup.
Testing a restore is uncomfortable advice because it means handling the seed again, which is the one moment when it is most exposed. The honest version is that a restore test on a spare device, with a small amount, tells you something no amount of careful storage does, and that the alternative is finding out at the worst possible time.
Our guide to comparing wallet security models covers how to think about that trade, and our guide to hardware wallets covers the device category the coverage here deliberately does not evaluate. Which Zcash wallet to use is the wallets article's subject in this series, not this one's.
What safe storage still leaves open
Four limits, and they are the reason the coverage stops where it does rather than becoming a general security guide. Each is something a reader could reasonably expect a storage article to deliver, and each belongs to a different problem with a different answer. Naming them is more useful than gesturing at them.
It does not make your holdings private. Keys protect access. Privacy on Zcash depends on which addresses value moved through and when, which is a separate set of decisions and a separate article.
It does not survive a lost seed. Nothing does. A birthday height without a seed is useless. A wallet file without a seed is a record of an inaccessible balance, and there is no recovery path anywhere in the system for a lost phrase. Even the reference backend's rewind machinery refuses to go below a recorded birthday without an explicit acknowledgement (source: librustzcash changelog). That illustrates a general rule. These systems are built to prevent silent loss of state. They are not built to recover keys.
It does not remove the exchange from your history. Value that arrived from a venue leaves a record at that venue regardless of where you store it afterwards, and that record persists.
And it does not protect you from yourself at the moment of restore. The commonest failure here is not theft, it is someone seeing a partial balance mid-scan, panicking, then doing something irreversible with a second copy of the seed. Knowing that the number moves while the scan runs is the whole defense.
Our guide to inheritance planning covers the case left out here: what happens to any of it if you are not there to run the restore.
A backup that will still work in five years
Most backup advice describes what to write down. The harder problem is whether it will still be usable when you need it, and four things determine that.
The medium has to survive. Paper in a drawer survives most things and not water or fire. Metal backups exist for exactly this reason and are worth the cost for an amount you would mind losing. A photograph on a phone is not a backup; it is a copy in the least durable and most exposed place available.
The location has to be separate from the risk. A backup stored next to the device it backs up shares every physical risk that device faces. Two locations is the standard, and the second one only helps if it is genuinely elsewhere.
The birthday has to travel with it. Zcash restores need a date or block height to avoid scanning the whole chain, and that figure is not derivable from the recovery phrase. Write it on the same medium, at the same time.
And somebody has to be able to use it. A backup that only you can interpret is a backup that ends at you. If continuity matters, the instructions have to exist somewhere too, and our guide to inheritance planning covers that case properly.
The test that ties all four together is a restore you actually perform, on a second device, before you need it. It takes an evening once and it is the only thing that converts a backup from an assumption into a fact.
Five ways people lose access, in order of frequency
Five, and the order is not the one people expect.
Losing the backup entirely is the most common, and it usually happens through ordinary domestic events rather than through anything dramatic.
Never testing a restore is second. Backups that turn out to be incomplete, mistranscribed or for a different wallet are discovered at exactly the wrong moment.
Losing the birthday is third, and it is Zcash-specific. The funds are recoverable, and the restore may take hours instead of minutes, which people frequently misread as a failure and abandon partway through.
Storing the backup somewhere connected is fourth. A recovery phrase in a notes app, a password manager reachable from a compromised machine, or an email to yourself is a backup an attacker can reach.
And relying on software that stops being maintained is fifth. The funds are fine and the route to them narrows, which is a slow failure rather than a sudden one and is worth checking on periodically.
Limits of safe storage
Three limits, and each is a place where careful storage buys nothing at all.
It does not make your holdings private. Storage is about who can spend; privacy is about what is published. A perfectly secured balance sitting in a transparent address publishes everything it always did, and the two subjects get conflated constantly because both involve keys.
It does not protect against sending to the wrong place. Every wallet will construct a valid transaction to a valid address, and a mistake there is final regardless of how the keys were stored. The only defense is a small test payment to any destination you have not used before.
And it does not survive you. A backup only you can interpret ends when you do, which is a planning problem rather than a security one and is worth treating separately from everything above.
Frequently asked questions
What is a Zcash wallet birthday and do I need it?
It is the block height your wallet was created at, and it is the point a restore starts scanning from. The reference implementation defines it as the height of the first block to be scanned in wallet recovery. You do not strictly need it, because a restore without it still finds your funds, but it will scan from far further back and take much longer. Note it down when you create a wallet. An approximate date is a usable substitute, since a wallet can convert that to a height and start a little earlier for safety.
Why does my balance change while a shielded wallet is restoring?
Because the wallet is still finding your transactions. Shielded amounts and addresses are encrypted, so the only way to identify your funds is to scan blocks and attempt decryption with your keys. Until the scan has covered every block from your birthday height forward, the balance reflects part of your history rather than all of it. The reference implementation calls this recovery mode and describes it as avoiding confusing shifts in balance and spendability during recovery from seed. Let it finish.
Is one seed phrase enough to restore everything?
Yes for the keys, and it is worth understanding why the question comes up. Zcash derives independent key trees for each shielded pool from a single seed, so one phrase does cover Sapling, Orchard and your transparent keys. What the seed does not carry is your birthday height or your transaction history, which is why a restore has to rebuild the second by scanning and goes faster if you supply the first.
Are the old zcashd backup instructions still safe to follow?
Treat them with care. That node software is being retired and the project tells users to migrate to its successors. Its own documentation also notes that its wallet export includes an HD seed covering only Sapling keys, and that its import command does not support importing HD seeds. An export that its own importer cannot fully restore is not a backup in any useful sense. The general rule holds regardless of software: a backup you have never restored is an assumption.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash Improvement Proposals repository, the reference wallet backend's published API documentation, and the Zcash project's own repository and documentation. All facts independently verified against cited documentation current as of August 2026. This article recommends no specific wallet and gives no command as an instruction.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Losing a seed phrase is permanent and unrecoverable. Do your own research before making any decision.