Zcash viewing keys: proving a shielded payment without giving up your keys
A Zcash viewing key grants read access to a shielded address without spend authority over it. Hand one to an accountant and they can see what arrived; they cannot move anything. That separation is the whole point, and it is the answer to a question shielded users hit constantly: how do I prove this payment happened when the block explorer shows nothing?
Because that is the trade. A fully shielded transaction publishes that it exists, its block, its fee and its size — and nothing about who sent it, who received it, or how much. Wonderful for privacy, awkward the moment someone legitimately needs to verify a payment reached you.
The problem viewing keys solve
On Bitcoin, proving payment is trivial: point at the transaction on an explorer. On Zcash, a transparent (t1…) transaction behaves the same way.
Shielded transactions do not. Confirming a shielded payment is done in your own wallet, not on an explorer, because the explorer genuinely cannot see it. So when a counterparty, an accountant or an auditor asks you to demonstrate a payment, you need a way to show them without handing over control of the funds.
The naive answer — share your seed phrase — gives away everything, permanently. Viewing keys exist so you don't have to.
What the different keys actually reveal
Zcash separates capability across several key types. The distinction matters, because handing over the wrong one reveals more than you intended.
| Key | Reads incoming | Reads outgoing | Can spend |
|---|---|---|---|
| Spending key | Yes | Yes | Yes |
| Full viewing key (FVK) | Yes | Via the OVK it derives | No |
| Incoming viewing key (IVK) | Yes | No | No |
The structure is more layered than a simple two-way split. Under ZIP 310, a Sapling full viewing key derives two further components: an incoming viewing key (IVK) and an outgoing viewing key (OVK).
The IVK detects incoming transactions and confirms which payment addresses belong to that key. It says nothing about what you subsequently did with the funds. A bookkeeper reconciling revenue usually wants exactly this and nothing more.
The OVK is what reveals outgoing payments — the recipient's diversified payment address, amounts, and memos sent to recipients. It is derived from the FVK, so sharing a full viewing key is broader than sharing an incoming one.
Neither viewing key can spend. That separation is structural, not a policy setting.
One limitation worth knowing: ZIP 310 notes that the protocol "does not distinguish between Bob sending Alice funds, and Alice moving funds between different addresses." So outgoing activity visible through an OVK does not reliably tell the holder whether a payment left your control or simply moved between your own addresses.
Unified viewing keys
Unified addresses (u1…) bundle several receivers into one string, so they need a matching key format. ZIP 316 defines a Unified Full Viewing Key (UFVK), which grants authority to view payments to and from an address, and a Unified Incoming Viewing Key (UIVK), restricted to incoming payments. A UIVK can be derived from a UFVK, so the narrower capability is available without managing a separate key per pool.
If you are new to the u1… format, unified addresses explained covers what is inside the string and why the format exists.
When you would actually hand one over
Realistic cases, roughly in order of how often they come up:
- Accounting. A bookkeeper reconciling revenue received at a shielded address needs to see incoming payments, not to spend them.
- Audit or tax. Demonstrating the history of an address to someone with a legitimate claim to see it.
- Proof of payment to a counterparty. Showing that you sent what you said you sent.
- Transparency by choice. A charity publishing a viewing key so donations can be independently verified — privacy technology used to prove openness rather than hide.
What a viewing key does not do
Three limits worth being clear about, because each has surprised someone:
There is no revocation mechanism. ZIP 310 specifies no way to invalidate a viewing key once it has been shared, so in practice someone holding one can read that address's activity indefinitely. Rotating to a new address is the practical remedy.
It is not selective per transaction. A viewing key exposes the address's activity, not one payment. If you need to disclose exactly one transaction and nothing else, a payment disclosure is the narrower tool.
It weakens privacy beyond the single address. ZIP 310 notes that multiple full-viewing-key holders can collectively infer common recipients and cooperative spending patterns, and that memo contents are unverified and may themselves expose a sender. Combined with information from elsewhere, a viewing key can reveal more than the address's balance history alone.
How this relates to swapping
Nothing in the SwapToZec flow asks for a viewing key, and nothing ever will. You give a destination address; ZEC is paid to it. We do not need to read your history to send you funds, and a swap service that asked for a viewing key would be requesting something it has no use for.
The connection is downstream. If you receive ZEC at a shielded or unified address and later need to prove to someone that it arrived, a viewing key is the mechanism — the payout transaction itself is not visible on an explorer in the way a Bitcoin payment would be.
If you are choosing an address type to receive at, shielded vs transparent addresses covers the trade-off, and how on-chain confirmations work covers what to expect while a payment settles.
The short version
A viewing key is read access without spend authority. Prefer the narrowest key that does the job — an incoming viewing key rather than a full one, where incoming is enough. Treat sharing one as permanent, because in practice it is. And remember that the reason you need it at all is the same reason you chose a shielded address: the chain deliberately is not telling anyone what happened.