Zcash Viewing Keys

Key Facts

• Viewing keys are not spending keys.
• They support disclosure without turning the whole ledger public.
• Use cases include audits, reporting, and shared visibility.
• Key handling needs careful wallet UX and user education.

Privacy with an audit path

The lazy argument says privacy and accountability cannot coexist. Viewing keys are one reason that argument is too simple.

A user can keep ordinary transaction details shielded, then disclose selected visibility when there is a real reason to do so.

The dangerous misconception

A viewing key is not a casual link to throw around. It can expose sensitive information depending on its type and scope.

Treat a viewing key like a financial credential: useful, powerful, and not something to paste into a random form. It cannot spend funds, but the information it reveals can still be sensitive.

Incoming, outgoing, and full visibility

Not every viewing key exposes the same direction or scope. Zcash key structures distinguish capabilities related to incoming notes, outgoing transactions, and fuller account visibility. Unified viewing keys can also package viewing capabilities across receiver types.

Before sharing a key, identify exactly what the recipient needs to verify. Giving an auditor broader visibility than required defeats the purpose of selective disclosure, even though spending authority remains protected.

Where viewing keys are useful

A business can use viewing access to reconcile receipts without putting every customer payment on a public ledger. A nonprofit can give a reviewer evidence about a shielded account. An individual can provide transaction visibility for accounting or compliance while keeping unrelated activity private.

The receiving software must support the relevant key type and scan the correct block range. A blank result can mean the key has no matching activity, but it can also mean the wallet has not finished scanning or does not support that key format.

Share the minimum and keep a record

Use an authenticated channel, confirm the recipient, and document which key was shared, why, and for how long the access is needed. Do not send viewing keys in the same casual message thread as public addresses and transaction identifiers.

If the disclosure relationship ends, assume the recipient retains whatever they already learned. Viewing access cannot make previously revealed information secret again, so minimization matters at the start.

FAQ