What Is a Zcash Viewing Key?

A Zcash viewing key is a credential that lets its holder see private information about a shielded Zcash account — incoming payments, amounts and memos — without giving them any ability to spend the funds. Zcash has several kinds of viewing key, and each reveals a different amount: an incoming viewing key shows only what arrives, while a full viewing key also shows spends.

That second sentence is the part most explanations skip. "Viewing key" is a family of keys, not one thing, and the difference between them is the difference between letting someone watch your deposits and letting them read your whole account.

A simple example

Alice keeps her ZEC in a shielded Zcash account. Her accountant needs to see what has been happening in it. Alice does not want to hand over her seed phrase or spending key, because either one would let the accountant move her money.

Instead, Alice exports a viewing key from her wallet and sends it to the accountant over a private channel. The accountant imports it into a wallet of their own, which scans the blockchain and displays Alice's account activity. They can look but cannot spend.

Exactly what the accountant sees depends on which key Alice chose:

• With an incoming viewing key, the accountant sees every payment Alice's account received, including the amount and any memo, but nothing about what Alice paid to others.
• With a full viewing key, the accountant also sees when Alice's funds were spent and, when Alice's wallet built those transactions in the standard way, where they went, how much, and the memo Alice attached.

In modern account-based usage, both keys apply to the account as a whole rather than to a single address, and both keep working for as long as the account is used. Those two facts drive most of the advice later in this guide.

Viewing keys vs spending keys

It helps to think of a Zcash account as having three separate levels of authority. This is an analogy, not a description of the cryptography, but it maps well onto how the keys actually behave:

• A receiving address is like a mailing address. Anyone who has it can send you ZEC. It reveals nothing about what you have received or spent.
• An incoming viewing key is like a window onto your mailbox. Whoever holds it can see what arrives, at any of your addresses, but cannot see what you send out.
• A full viewing key is like read-only access to the account ledger. Whoever holds it sees what comes in, sees when funds leave, and in the standard case sees where they went.
• A spending key (or the seed phrase that generates it) is the authority to move the money. It is the only one of the four that can spend.

Two things follow. First, a viewing key can never be "upgraded" into a spending key; the mathematics only runs one way. Second, having no spending authority does not make a viewing key harmless. Treat it as a sensitive, persistent read-access credential: once shared, it keeps granting that access.

Incoming viewing keys vs full viewing keys

Every shielded Zcash account has both kinds of key built in; your wallet uses them constantly to find your payments and keep your balance correct. When you "share a viewing key," you are choosing which of these to hand out.

An incoming viewing key (IVK) can:

• recognise and decrypt every payment sent to any address in the account,
• show the amount, the memo and which of your addresses received it,
• generate the account's receiving addresses, which also means it can tell that those addresses belong together.

It cannot see that a payment was later spent. A running total built from an incoming viewing key is therefore a "received so far" figure, not a balance.

A full viewing key (FVK) can do everything the incoming key can, plus:

• detect when funds in the account are spent, and whether the account was the only party spending in that transaction,
• decrypt the account's own outgoing payments when the wallet that sent them followed the standard protocol behaviour, revealing the recipient address, the amount and the memo,
• track the account balance, because it sees both sides.

The incoming viewing key is the narrower disclosure. If someone only needs to confirm that payments arrived, it is the right key to give them.

What are Unified Viewing Keys?

Modern Zcash wallets do not manage one shielded key at a time. A single account can receive through several "receiver" types at once: the Orchard shielded protocol (which the newer Ironwood pool also uses), the older Sapling shielded protocol, and optionally a transparent address. That is why a modern address usually starts with u1…: it is a Unified Address, which bundles several receivers into one string.

Viewing keys were unified in the same way, under the ZIP 316 standard:

• A Unified Full Viewing Key (UFVK) packages the full viewing keys for every receiver type in the account. On mainnet it starts with uview1….
• A Unified Incoming Viewing Key (UIVK) packages the incoming viewing keys instead, and starts with uivk1…. A wallet can derive a UIVK from a UFVK, but not the other way round.
• A Sapling extended full viewing key is the older, single-pool format for Sapling-only accounts and starts with zxviews1…. Some wallets still export it for accounts created before Unified Addresses existed.

The practical consequence is scope. A uview1… or uivk1… key is not "the viewing key for an address." In modern account-based usage, viewing authority generally applies at the account level rather than to a single diversified address, and a unified key covers every pool in that account. If the account has a transparent receiver, the unified key includes the account's transparent watching key too, so the holder can list and watch every transparent address the account uses and link them to the shielded activity. (All example prefixes in this guide are truncated placeholders; a real key is a long string that you should never paste into a web page.)

What can someone see with your viewing key?

Here is the comparison at a glance, from least to most powerful. "Account" means every address the account has generated or will generate.

A few qualifications matter, and they come from ZIP 310, the only formal write-up of what a viewing key holder learns. ZIP 310 describes Sapling keys and is an informational document still marked Draft. The Orchard protocol shares the same structure, so the same categories apply in practice, but there is no separate published analysis for Orchard and its guarantees should not be read as formally extended to it.

• Guaranteed information. With a full viewing key, the holder is guaranteed to learn when a note in the account is spent, whether the account was the sole spender, and that a given payment really did arrive at one of the account's addresses. Balances are guaranteed only as a lower bound: the exact figure is right when transactions follow the standard protocol behaviour used by normal Zcash wallets.
• Unverified information. A memo that says "this is from Bob" is just text; nothing in the protocol proves the sender wrote it. A viewing key holder should treat memo contents as claims, not facts.
• Undefined information. The protocol does not distinguish a payment from someone else from Alice moving funds between her own addresses, so "who paid Alice" is not something a viewing key proves. Likewise, the recipients of Alice's spends are visible only because standard wallets encrypt a copy of each outgoing payment to the sender's own outgoing viewing key. A wallet built to skip that step would leave the recipient undefined even to a full viewing key holder.
• Unrevealed information. A viewing key for Alice's account reveals nothing about anyone else's account. It does not expose the keys of her counterparties or their other transactions.

So "a full viewing key shows everything" is wrong in both directions. It shows more than most people expect about the account itself, including outgoing payments, and it proves less than people expect about who is on the other end.

What can't a viewing key do?

• It cannot spend, freeze or redirect funds. Only a spending key can authorise a transaction.
• It cannot be turned into a spending key.
• It cannot see other people's shielded activity. It decrypts only what involves the account it belongs to.
• An incoming viewing key cannot see spends or outgoing details at all.
• Neither key can prove who sent a payment or force a memo to be truthful.
• Neither key can change what is on the blockchain. A viewing key is a reading tool; the public chain still contains only encrypted notes, which is why the ZecZcash Explorer cannot show shielded balances or history for any address.

Why Zcash has viewing keys

Shielded transactions hide the sender, recipient, amount and memo from everyone; that is the point of Zcash, and it is what the shielded supply measures. But privacy from the public is not the same as secrecy from everyone. Businesses have accountants, funds have auditors, and people run wallets on more than one device.

Viewing keys let the owner of an account decide who gets to see it, at what level of detail, without publishing anything and without giving up control of the money. This selective-disclosure model is one of the defining features of Zcash's privacy design, and the standards behind it name two goals: auditing, and splitting authority between people or devices so that the system that watches the money is not the system that can move it.

View-only wallets and cold storage

The most common use of a viewing key is with yourself. Suppose your ZEC sits in a wallet whose seed phrase you keep offline. You still want to check the balance and see payments arrive.

Export the account's full viewing key from the offline setup, once, and import it into a "view-only" or "watch-only" wallet on your phone or laptop. That wallet scans the chain, shows the balance and history, and simply has no spend button. If the phone is compromised, the attacker gains a window into your account, which is a real privacy loss, but they cannot take the funds. Treasuries work the same way: signing on isolated hardware, monitoring and bookkeeping on ordinary computers that hold only viewing authority.

Auditing, accounting and business uses

The same idea extends to third parties, and a single rule makes it safe to apply: give viewing keys for dedicated accounts, not for everything you own. A Zcash wallet can hold many accounts, each with its own viewing keys. Disclosure is bounded by the account, so put the activity you intend to disclose in an account of its own.

• Accounting and tax. Share the full viewing key of your business account with your bookkeeper. They see every payment in and out, with amounts and memos. Your personal account, held separately in the same wallet, stays private.
• Auditing. An auditor can verify an organisation's shielded holdings and flows from a full viewing key, with the guarantees described above and none of the activity made public.
• Merchants and payment monitoring. A shop that accepts ZEC can run its payment-detection server with only an incoming viewing key. The server sees each customer payment and memo, so it can match orders, and nothing on that server could ever spend the takings. Because the incoming key does not see spends, it is the right key for this job and the wrong one for producing a balance.
• Charities and public transparency. Publishing a viewing key is possible, but it publishes every donation amount and memo, and a full viewing key would publish every outgoing payment too. A project that wants this should use a dedicated account and prefer the incoming key.

The privacy risks of sharing a viewing key

Because "it cannot spend" is true, it is easy to underrate what a viewing key gives away. Concretely, someone holding your account's viewing key can see:

• every incoming payment, with its amount and memo, to any address in the account;
• every one of your receiving addresses, and the fact that they all belong to the same account, which defeats the purpose of handing out a fresh address to each contact;
• with a full viewing key, every spend: when it happened and, for transactions made by a wallet following the standard protocol behaviour, the recipient's address, the amount and the memo you wrote;
• your balance, with a full viewing key;
• your transparent addresses, if the account has a transparent receiver, tied to the shielded activity above;
• the entire history of the account, back to the block where it was first used, and all future activity for as long as the account keeps being used.

Two further points are less obvious. Memos often contain the most sensitive information of all, such as invoice numbers, names or messages, and a viewing key reads them in full. And someone who collects viewing keys from several people can see the payments between them and the recipients they have in common, so the disclosure is not only about you.

None of this is a flaw; it is the intended behaviour of a key designed for auditors. The mistake is treating it like a public address. Share it over a private channel, share the narrowest key that does the job, use dedicated accounts, and keep a note of who has each one.

Can you revoke a Zcash viewing key?

No. There is no protocol mechanism that cancels a viewing key once it has been shared. The key is derived from the account's own secret material, and anyone holding it can keep scanning the blockchain indefinitely.

Two things do not help:

• Generating a new address in the same account. Every address an account produces shares the same viewing keys. A new diversified address is just as visible to the holder as the old one.
• Deleting your copy. The blocks are public; anyone with the key can decrypt the account's activity from them at any time.

The only real remedy is to stop using the account. Create a fresh account, which has entirely new viewing authority, and move your funds there. Be clear about what that achieves and what it does not:

• The move itself is a spend from the old account, so a holder of the old full viewing key will see it happen, including the amount and, in the standard case, the destination address.
• Everything that happened in the old account before the move stays readable to the holder forever. Historical disclosure cannot be undone.
• Activity in the new account is private from the old key holder, provided the new account's keys are never shared with them.

If the concern is that your seed phrase itself may have leaked, rather than a viewing key you handed out, treat it as a spending-key compromise: move funds to a wallet generated from a new seed, not just a new account under the old seed.

Sapling, Orchard and Ironwood

Zcash has had several shielded protocols. Two matter for viewing keys today, and a third pool reuses one of them:

• Sapling (2018) introduced the viewing-key design described above and the zxviews1… full viewing key format.
• Orchard (2022) kept the same idea with a redesigned internal structure. Its keys are what a Unified Viewing Key carries for the Orchard receiver.
• Ironwood, the pool introduced by the NU6.3 upgrade, is built on the Orchard protocol. It does not add a new category of viewing key: the same Orchard-protocol viewing keys detect and decrypt Ironwood-pool notes, and new payments to the Orchard receiver of an existing Unified Address are routed into the Ironwood pool. Your existing uview1… key keeps working through the Orchard-to-Ironwood migration, and a holder of it sees the migration transactions like any other activity. The pool has been active on mainnet since block 3,428,143; the wallet-side specifications for the migration, ZIP 318 and ZIP 326, are still marked Draft. See the Network Upgrade Tracker for current status.

For a normal user, the pool differences are handled entirely by the wallet.

Viewing keys vs payment disclosures

People sometimes ask for a viewing key when what they actually want is proof of one payment. Those are different tools:

• A viewing key is ongoing read access to an account. It is the wrong instrument for proving a single payment, because it reveals everything else too.
• A payment disclosure is a proposed mechanism for proving facts about one specific shielded payment, such as "this transaction paid this amount to this address," without revealing the sender's other addresses or transactions. It is specified in ZIP 311, which remains a Draft and is not a generally deployed feature of current wallets.

In the meantime, a recipient's own wallet record, a transaction ID and a memo can be useful practical evidence between the two parties, depending on context. They are not a substitute for a payment disclosure: a transaction ID on its own proves nothing about the recipient or amount of a shielded payment to an outside observer, and none of these carry the cryptographic guarantees ZIP 311 is designed to provide. Do not export a viewing key as a "verification step" for a single payment, and be suspicious of anyone who asks you to.

Which Zcash wallets support viewing keys?

The protocol supports viewing keys everywhere; individual wallets choose whether to expose export and import. Last verified: September 2026, from the projects' own source code:

• Zkool can create a view-only account from a Unified Viewing Key (full or partial), from a legacy Sapling extended viewing key, or from a transparent extended public key, and can export an account's Unified Full Viewing Key with a choice of pools. It is listed in the ZecZcash wallet directory.
• zingo-cli (the zingolib command-line wallet) can create a watch-only wallet from a UFVK with a birthday height.
• Zallet, the node-operator wallet that succeeds the zcashd wallet, is in beta. It can export the full viewing key for a Sapling or Unified Address, or the account's Unified Incoming Viewing Key with an option, and it can import Sapling extended full viewing keys as view-only accounts. Import of Unified viewing keys is planned but not yet available. One nuance from its own documentation: the incoming key it exports is scoped to the whole account, so it grants incoming visibility for every pool in the account even if you asked about a single Sapling address.

Support in other consumer wallets changes often; check the wallet's current release notes rather than an older guide. Instructions that begin with zcash-cli z_exportviewingkey describe zcashd, which reached end of support in July 2026; the current equivalents live in Zallet and in the wallets above.

Technical details for advanced readers

Everything above holds without this section. For readers who want the underlying structure:

• Key components. A Sapling full viewing key consists of a spend-validating key, a nullifier-deriving key and an outgoing viewing key; the incoming viewing key is derived from the first two. An Orchard full viewing key consists of a spend-validating key, a nullifier-deriving key and a randomiser from which the incoming viewing key, outgoing viewing key and diversifier key are derived.
• ivk, ovk, fvk. The incoming viewing key (ivk) trial-decrypts note ciphertexts addressed to the account. The outgoing viewing key (ovk) decrypts the copy of each output that a standard wallet encrypts to itself when spending, which is how a full viewing key learns recipients and amounts of outgoing payments. Nullifiers, derived with the nullifier-deriving key, are what let a full viewing key detect spends.
• Diversified addresses. One key set yields an enormous number of unlinkable receiving addresses (up to about 2^87 for Sapling, 2^88 for Orchard). They are unlinkable to outsiders, but trivially linkable to anyone holding the account's incoming viewing key, which is why address rotation does not help against a viewing-key holder.
• External and internal scope. Each account has an external key set for addresses you give out and an internal set for change and auto-shielding. A full viewing key derives both. An external incoming viewing key cannot derive the internal one or any outgoing viewing key.
• ZIP 32 accounts. Wallets derive shielded keys from a seed along the path m/32'/133'/account', with a matching transparent path under BIP 44. "Account" is the unit that viewing keys, and therefore disclosure, attach to.
• Unified key encodings. A UFVK is a Bech32m string containing one item per receiver type, in a fixed order, with a jumbling step that stops a key from being partially altered. The transparent item is the account-level public key, which is why a UFVK can watch both external and change transparent addresses; the UIVK carries the external-chain key only. ZIP 316 Revision 0 is the active standard; a Revision 2 draft proposes new prefixes (uvf, uvi, zu, tu), expiry metadata and multisig items, none of which are deployed at the time of writing.
• Ironwood key derivation. ZIP 2005 (Proposed) defines a use_qsk option for Ironwood-era accounts that changes how their Orchard-protocol viewing keys and addresses are derived, and ZIP 326 (Draft) describes how wallets scan for such accounts. It affects new accounts and wallet implementers, not the meaning of viewing keys for users.

Sources and methodology

This guide is based on direct review of the primary specifications and of the wallet projects' public source code, checked in September 2026. Technical claims come from the Zcash Protocol Specification (key components and note decryption), ZIP 32: Shielded Hierarchical Deterministic Wallets (Final), ZIP 310: Security Properties of Sapling Viewing Keys (Draft, Informational), ZIP 311: Zcash Payment Disclosures (Draft), ZIP 316: Unified Addresses and Unified Viewing Keys (Revision 0 Active, Revision 2 Draft), the NU6.3 wallet ZIPs ZIP 318 and ZIP 326 (Draft), and ZIP 2005 (Proposed). Wallet-support statements were verified against the Zallet repository (changelog, book and RPC source at v0.1.0-beta.3), the Zkool repository (v6.31.0) and the zingolib repository. Where a wallet's support could not be confirmed in its own source, it is not listed here. For what the public chain does and does not show without a key, see the ZecZcash Explorer; for the wallets themselves, see the wallet directory and, if something goes wrong with a view-only setup, Zcash Wallet Troubleshooting.