A viewing key lets somebody see what your shielded transactions did, while leaving them unable to move a single coin. There are 4 kinds. They see different things, and choosing between them is the whole of what people mean when they talk about selective disclosure on this chain.
Most explanations mention two. The specification carries four, and the two that get skipped are the ones that let you show somebody exactly half of your history.
Search for the term and nothing ranks at all. The project's own introduction to Zcash uses the phrase once across eight thousand characters, and never mentions spending keys. So the concept that makes controlled disclosure possible on this chain has no explainer anywhere a reader would look.
What a viewing key is, against the key that can spend
Start with the distinction that makes everything else possible, because it is genuinely not obvious that a chain built to hide your transactions could show them to a chosen person at all. The trick is that hiding and spending are protected by different keys, and only one of those needs to stay with you.
A shielded transaction is encrypted to its recipient. Reading it requires a key. The insight is that the key which reads is not the key which spends, and the two can be handed out separately.
The protocol specification puts it precisely: for each spending key "there is a full viewing key that allows recognizing both incoming and outgoing notes without having spending authority".
Two phrases in that sentence do the work. Recognizing notes means seeing your transactions. Without spending authority means whoever holds it cannot move anything.
So a viewing key is a read credential carved off a write credential, and the carving happens by derivation rather than by permission. Nothing grants access and nothing revokes it. There is only which key somebody holds.
How thoroughly this is missing from the introductory material is worth a number. The project's own basics page, which ranks for the broad query, uses the phrase viewing key exactly once in 8,290 characters and never uses spending key at all (source: Zcash documentation).
A reader could learn what Zcash is from that page and come away with no idea that controlled disclosure exists.
Our guide to public and private keys covers the general relationship this specializes.
Incoming, outgoing, and full
Here is the taxonomy, and it is wider than almost every published description of it. Two of the kinds get mentioned routinely, while a third appears in the specification twenty-six times and almost nowhere else, and the difference between them decides whether somebody sees half of your history or the whole of it.
The specification derives, from a spending key, a full viewing key, then from that full viewing key both "an incoming viewing key" and "an outgoing viewing key".
An incoming viewing key shows payments made to you, and it is the one people mean when they say viewing key without qualifying the phrase further.
An outgoing viewing key shows the other direction. The reference library defines it as "a key that provides the capability to recover outgoing transaction information from the block chain".
A full viewing key holds both capabilities at once, which is why the specification describes it as recognizing incoming and outgoing notes together.
That gives a ladder rather than a switch. The spending key sits at the top with the power to move funds. Below it, the full viewing key sees everything and moves nothing. Below that, two keys each seeing one direction.
The counts in the specification make the point about how central this is: viewing key appears 111 times, incoming viewing key 52, outgoing viewing key 26, full viewing key 25. This is not a footnote in the design.
These are implemented types rather than a paper taxonomy, carried in a library that is versioned and updated alongside the rest of the wallet stack (source: librustzcash changelog).
Unified viewing keys, the fourth kind
The fourth kind is a bundle rather than a new capability, and it exists for the same reason unified addresses do: the chain runs several shielded protocols side by side, and anything built for one of them covers only that one. Packaging is the answer, and it has the same trade-offs packaging usually has.
There is more than one shielded protocol on this chain, and every one of them carries its own key material. Handing somebody a viewing key for one pool shows them one pool. The unified form packages the per-pool keys into a single string.
The reference library carries both variants as first-class types, constructing a unified full viewing key from optional transparent, Sapling and Orchard components (source: zcash_keys), and a unified incoming viewing key alongside it.
Notice the word optional. A unified viewing key covers whichever components it was built with, so two of them can differ in what they reveal while looking equally opaque to anyone holding them.
That is the packaging trade-off in one sentence. The convenience is that one string covers several pools; the cost is that the string does not announce which pools it actually covers, and neither does anything else about it.
Our guide to Zcash unified addresses covers the bundling format from the address side, including its revision statuses. For disclosure purposes what matters is narrower: a unified key is a convenience wrapper, and the capability question is still incoming against outgoing against full.
One practical consequence follows. If somebody asks you for a viewing key, the useful clarifying question is which pools it needs to cover, because a key built for the wrong component shows them nothing and looks the same as one that works.
Who you would actually give one to
This is the question the node exists to answer, and it has a small set of concrete answers rather than a general principle. Each one is a different person needing a different amount of your history, which is exactly the situation the four key kinds were designed for.
An accountant preparing your return needs to see what came in and what went out. That is a full viewing key, and it is the clearest legitimate case for the strongest read credential.
Somebody verifying that a payment reached you needs far less. An incoming viewing key answers that and shows nothing about what you subsequently did.
An auditor checking that funds left an organization to the places it claims needs the outgoing side, and giving them a full key would hand over incoming activity they had no reason to see.
A counterparty who wants proof a specific payment happened needs none of these. That is a question about one transaction, and handing over a key that reveals a history is a large answer to a small question.
The pattern is that the right key is the weakest one that answers the question, and the specification's own derivation order is what makes that possible, because the weaker keys are derived from the stronger one rather than issued as separate grants (source: Zcash protocol specification). What can be checked with no key at all is more than people expect on the transparent side, and reading a block explorer shows how.
Estate planning is the case people think of last and should think of first. Our guide to crypto inheritance planning covers the general problem, and viewing keys let someone establish what exists without being able to move it.
What handing one over actually costs
Three properties, and not one of them behaves like the access controls people are used to. This is the section to read twice before sharing anything. Intuitions built on revocable permissions fail here, and they all fail in the same direction.
It is permanent. A viewing key cannot be revoked. There is no server holding a permission that can be switched off, because the key is derived mathematics rather than an account setting. Once somebody has it, they have it for as long as the chain exists.
It is retroactive and prospective at once. A key handed over today reveals activity from before today and will continue revealing activity afterwards. Giving one to settle a specific year gives away every other year in both directions.
It cannot be narrowed. There is no way to grant a viewing key that covers a date range or a single counterparty. The granularity available is the four kinds, and that is all of it. The reference library's key types are the whole menu: incoming, outgoing, full, and the unified wrappers around them (source: zcash_keys).
Put together, the honest framing is that a viewing key is closer to publishing than to sharing. For the general shape of a disclosure that cannot be undone, crypto privacy basics is the starting point, and how crypto wallets work covers where these keys live in the first place.
The derivation structure underneath all this is standard hierarchical key material, and our guide to key derivation covers how one root produces many keys.
Limits of a viewing key
Four limits, and together they explain why this is a considerably narrower tool than it first appears to be. Two of them are reassuring and two of them are not, which is about the right proportion for a capability that trades away permanence in exchange for a degree of control.
It cannot spend, which is the entire point of the construction and is worth stating plainly, because the fear people have when handing one over is usually theft and theft is precisely the thing it does not enable.
It cannot be taken back, which was covered above and is repeated here because it is the property people most reliably forget at the moment a disclosure feels routine and administrative.
It cannot prove a negative. Showing somebody a viewing key demonstrates what that key can see, and it does not demonstrate that you hold nothing else. A second wallet with a different seed is invisible to it entirely.
And it cannot answer a policy question. What any organization requires of you, and whether a viewing key satisfies it, is not a property of the key. what follows describes a capability; the regulation node in this series covers the rest.
One more thing is about the tooling rather than the key. Whether the software you use can export any of these, and in which format, is a fact about that software. The specification and its repository define what exists (source: zcash/zips); what your wallet exposes is a separate question with a separate answer.
BloFin never asks for a viewing key, which is worth saying on a page that describes handing them out.
Before you share one: five questions
Handing over a viewing key is not reversible in any practical sense, so the decision belongs before the request rather than during it.
Which kind are you being asked for? Incoming, outgoing and full capabilities expose different things, and requests are frequently phrased in general terms by people who do not know the distinction exists. Establishing which one is needed often reveals that a narrower one would do.
What period does the recipient actually need? A key exposes everything it can see, for as long as it exists, with no way to scope it to a date range. If the requirement is one tax year, the capability handed over covers considerably more than that.
Can you revoke it? Not in any meaningful way. A key that has been copied stays copied, and the only remedy is moving funds to an account the key does not cover, which is a real operation with real costs.
Who else will hold it? A key given to a firm is a key held by that firm's systems, its staff and its backups, and its exposure is now their security posture rather than yours.
And is there an alternative that satisfies the requirement? A transaction list exported by your own wallet, or a statement you produce yourself, frequently answers the underlying need without granting an ongoing capability to anyone.
Why the request is easy to say yes to
The social shape of these requests is worth naming, because it does most of the work in getting people to agree to something they would refuse if it were phrased plainly.
The request usually arrives as administration rather than as a security decision. It is one line in a longer list of things somebody needs, phrased in the vocabulary of paperwork, and it does not look like the moment to push back.
The person asking often does not know what they are asking for. They need to verify some transactions, they have been told this is how it is done on this chain, and the distinction between a scoped export and an ongoing capability has not occurred to them.
And refusing feels obstructive out of proportion to the actual imposition. Saying no to a key while offering an export is entirely reasonable, and it takes a sentence, but the first instinct in an administrative exchange is to comply.
Knowing that shape in advance is most of the defense. The question worth asking is whether the capability matches the need rather than whether you trust the person. Trust is usually warranted; the match usually is not.
What to offer instead
Three alternatives satisfy most legitimate requests without granting an ongoing capability, and offering one of them converts a difficult conversation into an easy one.
A transaction export from your own wallet covers almost every accounting requirement. It contains dates, amounts and counterparties for the period requested, it is produced by you, and it stops at the boundary you choose. Most software can produce one directly.
A scoped statement covers the cases where a third party needs assurance rather than detail. A document listing the specific transactions in question, with whatever supporting references exist, answers the underlying question without exposing anything adjacent to it.
And a one-off demonstration covers verification requests. Showing that you control an address or that a specific payment occurred is a bounded action, unlike a key, and it is usually what somebody actually wanted when they asked for one.
If none of those three satisfies the request, the requirement genuinely is an ongoing capability, and at that point the five questions above are the right frame for deciding. What should not happen is arriving there by default because the alternatives were never raised.
There is one situation where the calculus genuinely changes, and it is worth naming so the caution above does not read as blanket refusal. An ongoing relationship with a professional who needs continuous visibility, over a period measured in years, is a case where repeated exports become the worse option and a scoped capability is the sensible one. Even there, the questions above still apply: which kind, held by whom, and covering what. The answer changes from no to a narrower yes rather than to an unqualified one.
Frequently asked questions
What exactly does a Zcash viewing key do?
A credential that reveals your shielded transactions to whoever holds it, while giving them no power to move funds. The protocol specification describes a full viewing key as one that allows recognizing both incoming and outgoing notes without having spending authority. It is derived from the spending key rather than granted by any service, which is why it works without a server and also why it cannot be switched off later.
What is the difference between incoming and full viewing keys?
Direction. An incoming viewing key reveals payments made to you and nothing about what you sent. An outgoing viewing key does the reverse, revealing what left. A full viewing key holds both capabilities at once. The specification derives the incoming and outgoing keys from the full one, so they are strictly weaker, which is exactly what makes selective disclosure possible: you hand over the rung that answers the question.
Can I take a viewing key back?
No. There is no revocation mechanism, because there is nothing to revoke. A viewing key is derived key material rather than a permission stored on a server, so nobody can switch it off. It also works in both time directions, revealing activity from before you shared it and continuing to reveal activity afterwards. Treat handing one over as closer to publishing than to sharing.
Does a viewing key show all my Zcash activity?
It shows what that key covers, which may be less than everything you hold. Several shielded protocols run on this chain, and a key built for one of them covers that one alone. Unified viewing keys bundle per-pool keys into a single string, and the reference library builds them from optional components, so two unified keys can differ in coverage while looking identical. A separate wallet with a different seed is outside any of them.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash protocol specification and the reference key library's published documentation. All facts independently verified against cited documentation current as of August 2026. This article names no wallet, describes no regulatory obligation, and makes no claim about what any organization requires.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Sharing a viewing key is irreversible. Do your own research before making any decision.