Zcash Private Keys and Seed Phrases Explained

A Zcash seed phrase is the single backup from which a modern Zcash wallet derives all of its keys: spending keys that can move ZEC, viewing keys that can only see activity, and the addresses you give out. In Zodl it is 24 words plus an optional birthday height. Anyone who learns the words controls the funds, so they never belong on a website.

This guide follows the chain from those words to an address, explains what each key in it can do, and ends with the safety rules that matter more than any of the cryptography. For the full story on viewing keys, read our separate Zcash viewing key guide; this article only summarises them.

The Zcash key hierarchy at a glance

Think of it as a family tree in which every branch can be recomputed from the root, but no branch can be used to climb back up:

1. Seed phrase. Words such as word01 word02 … word24 (placeholder) that encode the wallet's random seed.
2. Seed. The bytes the words stand for. Everything else is computed from it.
3. Account. A numbered "bucket of funds" under one spending authority, derived along a fixed path defined in ZIP 32.
4. Spending keys. One per account and protocol: transparent, Sapling and Orchard. They authorise spends.
5. Full viewing key. Derived from the spending key. Sees incoming payments and spends, cannot spend.
6. Incoming viewing key. Derived from the full viewing key. Sees only incoming payments.
7. Addresses. Derived from the viewing keys. Many different addresses can belong to one account.

Each step only goes downwards. A viewing key cannot rebuild a spending key, and an address reveals neither. That is why it is safe to hand out an address and never safe to hand out the seed.

The seed phrase: 24 words that stand for everything

A seed phrase (Zodl calls it the recovery phrase) is a human-readable way to write down random data. The usual format is BIP 39: random entropy plus a short checksum is split into 11-bit groups, and each group picks one word from a fixed list of 2,048 words. The words are then turned into the binary seed the wallet works with.

Zodl's Help Desk describes its phrase as "a collection of 24 words in a specific order, alongside an optional block height (the wallet birthday)", and adds that anyone with access to it "will be able to spend the Zcash in your wallet and view your past and future transaction history".

Why Zcash wallets use 24 words

ZIP 32, the Final standard for Zcash key derivation, says the seed "MUST ensure that it has at least 256 bits of entropy" and that this "also applies to any mnemonic". In BIP 39's own table, 128 bits of entropy give 12 words and 256 bits give 24 words. ZIP 315, a wallet best-practice document still marked Draft, draws the conclusion: when generating a seed, "a 24-word mnemonic will be needed" (or a share length of 33 words for SLIP 39 secret sharing).

So a 12-word phrase is not a Zcash-specific format. It is common in other coins, but it would carry only half the entropy ZIP 32 asks for.

The wallet birthday

The birthday is the block height at the time the wallet was created. Zodl's Help Desk lists it as the optional second part of the backup, and the restore guide asks for it: knowing it lets the app skip every block from before your wallet existed, so the sync is faster. If you did not note it, Zodl offers an "Estimate block height" option where you choose when you created or first used the wallet (the guide mentions the year and month). The birthday is not secret in the way the words are, and it is not needed to find your funds, only to find them faster. Our block height glossary entry explains the term.

Restoring from a shorter phrase

ZIP 315 (Draft) says a wallet MAY accept a BIP 39 phrase of fewer than 24 words when restoring, but MUST NOT generate one, and SHOULD warn that the restored wallet is weaker than expected and recommend moving the funds to a new wallet once it has synced.

Accounts and derivation paths

ZIP 32 (Status: Final) adapts the hierarchical wallet idea from Bitcoin's BIP 32 to Zcash's shielded pools. Sapling and Orchard each derive their own master key from the same seed, then follow the same three hardened path levels:

m / 32' / 133' / account'

• 32' is the purpose, a constant that marks the ZIP 32 tree.
• 133' is the coin type. ZIP 32 reuses the registry in SLIP 44, where 133 is ZEC.
• account' counts up from 0. ZIP 32 describes an account as a "bucket of funds" under the control of a single spending authority.

The apostrophe means hardened derivation: keys at these levels can only be derived from the secret parent key, never from a parent viewing key. Orchard supports only hardened derivation.

This is why one seed can hold several separate accounts, and why two wallets restored from the same words can look different: one may show only account 0, another may scan more accounts or more pools.

Spending keys: the authority to move ZEC

A spending key is what actually authorises a payment. Zcash has three kinds in use today, one for each protocol (transparent, Sapling, Orchard), and a ZIP 32 wallet derives all of them for an account from the same seed.

Transparent keys

Transparent addresses (t1…, t3…) work like Bitcoin's. A t1 address is a hash of a public key on the secp256k1 curve, and spending from it takes an ECDSA signature with the matching private key (Protocol Specification §4.1.7 and §5.6.1.1). Wallets that derive these from the seed use the BIP 44 path; ZIP 316 gives the receiving address path as m/44'/133'/account'/0/index. Transparent funds are public on the chain, as our shielded vs transparent guide explains.

Sapling spending keys

For Sapling, the Protocol Specification (§3.1, §4.2.2) defines an expanded spending key with three parts: a spend authorizing key (ask), a nullifier private key (nsk) and an outgoing viewing key (ovk). A ZIP 32 extended spending key adds a diversifier key and a chain code. When it is written out as text on mainnet, it begins with secret-extended-key-main1… (placeholder, truncated).

Orchard spending keys

For Orchard, a single spending key (sk) is the starting point. From it a wallet derives the spend authorizing key and a full viewing key made of ak, nk and rivk; the incoming and outgoing viewing keys come from that full viewing key (Protocol Specification §3.1, §4.2.3). ZIP 32 also defines an Orchard extended spending key encoding, secret-orchard-extsk-main1… (placeholder), but says it expects "most wallets will only expose the regular Orchard spending key encoding to users".

The Protocol Specification adds a useful reminder: the composition of these keys "should not normally be exposed to users". In practice your wallet handles all of this, and the seed phrase is the one secret you manage.

Ironwood and the proposed quantum spending key

Ironwood, the shielded pool added by the NU6.3 upgrade, does not bring a new kind of address or key. ZIP 229, whose status is Draft, defines it as a new value pool of the Orchard protocol and states that Orchard spending-key and viewing-key material "grants authority to spend or view notes in both the Orchard and Ironwood pools". It also says the pool "does not change address structures or encodings".

ZIP 2005, Ironwood Quantum Recoverability, has the status Proposed. Among other things it describes a use_qsk option with an alternative "quantum spending key" (qsk), intended for keys generated with FROST distributed key generation or for hardware wallets where exporting the Orchard spending key is undesirable. For backups its key sentence is that, with ZIP 32 derivation, qsk "need not be backed up separately from the seed phrase", because it is computed from the derived spending key. Our quantum resistance guide covers what ZIP 2005 does and does not do.

Viewing keys in brief

A viewing key lets its holder see an account's shielded activity without being able to spend:

• A full viewing key sees incoming payments and spends, and, for transactions built the standard way, outgoing details. Sapling's encoded form begins with zxviews1… (placeholder).
• An incoming viewing key sees only payments received.
• Unified viewing keys bundle these per account under ZIP 316: uview1… for a Unified Full Viewing Key and uivk1… for a Unified Incoming Viewing Key (Revision 0, Active). Revision 1 is Withdrawn, and the Revision 2 draft proposes the new prefixes uvf and uvi.

A viewing key cannot spend, but it is a permanent read credential that cannot be revoked. Who should get one, and what they will see, is covered in depth in our viewing key guide and the viewing key glossary entry.

ZIP 316 defines unified addresses and unified viewing keys only. It does not define a "unified spending key" string, so on the spending side the seed phrase remains the thing you back up.

Addresses are derived, not keys

An address is the end of the chain. Shielded addresses are built from an incoming viewing key and a diversifier, which is why one account can hand out a fresh address to every payer without anyone being able to link them. ZIP 32 puts the limit at about 2^87 addresses per account for Sapling and 2^88 for Orchard. A Unified Address (u1…) packs receivers for several pools into one string.

Our address types guide explains t1, t3, zs1, u1 and tex1, and the Address Checker tells you which type a string is. It checks the format in your browser and only ever takes an address, never a key.

What each key can do

A spending key can see everything its viewing keys can, because it can derive them. A seed phrase can do everything any key derived from it can.

What a wallet backup really needs

For a Zodl wallet, the Help Desk is specific: the 24 words in the correct order, plus the optional birthday height. The restore guide says that "all funds from your Zodl wallet can be restored with your recovery phrase". You do not need to back up individual keys or addresses, because the wallet recomputes them.

Zodl's storage advice:

• Write the words on paper and keep them somewhere secure and offline.
• Do not take a screenshot or a photo and do not store the phrase digitally.
• Durable options such as steel backups are worth considering.
• Enter the words on a restore only where no people or cameras can see them.

Back up before you reset or uninstall the app. Zodl warns that you will need the phrase to restore and cannot view it any more after a reset. If you want a second, independent wallet, generate a new seed in it rather than copying the old one.

Never type a seed or key into a website

The rule is short and has no exceptions: no website, form, browser extension, chat, e-mail or support agent ever needs your seed phrase or a spending key. That includes this site. Zodl puts it bluntly: "Anyone asking for your recovery phrase is attempting to scam you", and if the request appears to come from Zodl, someone is impersonating it.

Common traps to recognise:

• A "wallet validator", "sync fixer" or "airdrop claim" page that asks for the 24 words.
• A balance checker that wants a key instead of an address. To look at a transparent address, our balance checker and explorer need only the address. Shielded balances are private by design and only your wallet can show them.
• A direct message from "support" offering to fix a stuck wallet. Our wallet troubleshooting guide covers sync problems without any key.

If you have ever typed your phrase into a site like that, treat the seed as compromised: create a new wallet with a new seed on a device you trust and move the funds there. A new account under the old seed does not help, because the old words still control it.

Hardware wallets

A hardware wallet is designed to keep the seed on a dedicated device and to sign transactions there, so the phone or computer never holds the spending key. You still have to protect the device's own recovery phrase. How this works with Zcash today is covered in our Keystone and Zodl guide and our Ledger guide; support depends on firmware and app versions, so check those guides rather than older forum posts.

If you lose the seed phrase

While the wallet app still works, you can view the phrase again in Zodl under '...' menu > More > Advanced Settings > Zodl Recovery Phrase and write it down now. If the phone and the phrase are both gone, the funds are lost. Zodl states that it has no access to your phrase and "cannot help you recover it". No wallet maker, exchange, website or support service can recreate a seed. Anyone offering to do so is running a scam.

Technical details for advanced readers

• Mnemonic to seed. BIP 39 turns the words into a 64-byte seed with PBKDF2 (HMAC-SHA512, 2,048 iterations). ZIP 32 accepts seeds of 32 to 252 bytes.
• Master keys. ZIP 32 derives separate master keys for Sapling and Orchard from the same seed, using different BLAKE2b personalisations (ZcashIP32Sapling, ZcashIP32Orchard).
• Internal keys. Each account has an external key set for addresses you hand out and an internal set for wallet-internal operations such as change and auto-shielding; ZIP 32 specifies both for Sapling and Orchard.
• Encodings. Sapling extended spending keys use the Bech32 prefix secret-extended-key-main, Sapling extended full viewing keys zxviews, Orchard extended spending keys secret-orchard-extsk-main. Unified viewing keys use Bech32m with a jumbling step (ZIP 316).
• Sprout. The original Sprout pool is historical. ZIP 32 lists its former derivation constants as reserved values that should not be reused, and Sprout is not part of the derivation described here.
• Out of date documents. Some older Zcash documentation predates Orchard and Unified Addresses. Prefer the ZIPs and the Protocol Specification.

Sources and methodology

Checked on October 17, 2026 against ZIP 32: Shielded Hierarchical Deterministic Wallets (Final; sections "Wallet seeds", "Key path levels", "Sapling key path", "Orchard key path" and the key encodings), ZIP 315: Best Practices for Wallet Implementations (Draft; section "Wallet seeds"), ZIP 316: Unified Addresses and Unified Viewing Keys (Revision 0 Active, Revision 1 Withdrawn, Revision 2 Draft), ZIP 229: Version 6 Transaction Format (Draft; definitions and "Ironwood pool"), ZIP 2005: Ironwood Quantum Recoverability (Proposed), the Zcash Protocol Specification (version v2026.7.0-318-ga34cfc, dated October 16, 2026; §3.1 "Payment Addresses and Keys", §4.2.2 "Sapling Key Components", §4.2.3 "Orchard Key Components", §4.1.7 "Signature", §5.6.1.1 "Transparent Addresses"), BIP 39, SLIP 44 and Zodl's Help Desk articles Backing up your Zodl recovery phrase (last updated February 24, 2026) and Recovering your Zodl wallet (last updated September 28, 2026). We did not test key export, passphrase options or restores between different wallets, and this guide makes no claim about them. New articles first appear in the ZecZcash Telegram channel.