View Key

The View Key grants a third party the ability to view the details of incoming and outgoing transactions for a specific shielded address. This is essential for:

• Regulatory Compliance: Exchanges or auditors can verify transaction history.
• Proof of Funds: Users can prove ownership and balance without revealing their private spend key.
• Accounting: Businesses can maintain transparent records for internal or tax purposes.

In protocols like Zcash and Monero, a View Key is derived from the wallet's private key material but is cryptographically separate from the Spend Key. It works by:

• Decrypting Memo Fields: Unlocks encrypted payment information attached to transactions.
• Scanning the Blockchain: Allows a wallet (or designated viewer) to scan the chain for transactions belonging to the associated address, which appear as random data to everyone else.
• Asymmetric Design: Possession of the View Key does not allow spending funds or viewing the transactions of other users.

Cryptocurrency exchanges dealing with privacy coins often require users to disclose their View Key. This enables the exchange to:

• Perform AML/KYC Checks: Monitor the source and destination of funds deposited from a shielded address.
• Track Transaction History: Ensure funds are not from illicit activities before allowing trading or withdrawal.
• Maintain Audit Trails: Provide a verifiable record for financial regulators without forcing the user to forfeit all privacy.

It is critical to understand what a View Key cannot do:

• Cannot Spend Funds: It is not a signing key. The Spend Key is required to authorize transactions.
• Cannot View Other Wallets: Access is scoped solely to the transactions of the specific address it's derived from.
• Optional Sharing: Users generate and control their View Key; privacy is opt-in, and transparency is user-granted.

Zcash's shielded addresses (z-addrs) utilize the zk-SNARK protocol. Each z-address has associated keys:

• Spending Key: Authorizes payments.
• Full Viewing Key: Contains the View Key and a separate key to derive all payment addresses for that wallet.
• Users can share just the View Key component for auditing, or the Full Viewing Key for more comprehensive access. This design is foundational for building compliant private DeFi applications.

A more granular tool is a Payment Disclosure, which proves a single specific transaction without revealing an entire history. It acts as a one-time View Key, providing:

• Targeted Proof: Evidence of a payment's amount, sender, and receiver.
• Lower Privacy Footprint: Minimizes exposed data compared to sharing a persistent View Key.
• Use in Commerce: Useful for providing a receipt or proof of purchase in a private transaction.

View keys enable third-party verification of transaction details without compromising the sender's full privacy. This is critical for:

• Regulatory compliance: Exchanges or auditors can confirm funds are not from illicit sources.
• Proof of payment: A merchant can verify a customer's payment without seeing their entire wallet balance.
• Tax reporting: Users can share transaction history with accountants.

Users can generate a view-only version of their wallet to monitor balances and incoming transactions on a separate, less secure device. This allows for:

• Secure portfolio tracking: Check balances from a phone or public computer without exposing spend authority.
• Watch-only wallets: Services can display aggregated balances from multiple private addresses.
• Inheritance planning: Heirs can be granted view access to assess an estate.

Institutions use view keys to satisfy Know Your Customer (KYC) and Anti-Money Laundering (AML) requirements while using privacy protocols. Key implementations include:

• Zcash (zcashd): The z_exportviewingkey RPC call generates a key for exporting transaction data.
• Monero: A "view key" is part of the standard wallet address, allowing incoming transaction detection.
• Auditor roles: Designated entities can be given view keys to monitor specific address activity on-chain.

View keys are a fundamental component of asymmetric privacy models, giving users granular control over their data. This contrasts with all-or-nothing transparency.

• Disclosure granularity: Users can reveal specific transactions to specific parties.
• Revocability: View keys can often be changed, revoking previous access.
• Selective transparency: Enables use cases like confidential payroll where only the employee and HR can view the transaction details.

The private key counterpart to a View Key, granting full authority to spend funds and authorize transactions. In privacy-focused systems like Monero or Zcash, the Spend Key is kept highly secure and separate from the View Key to enforce a principle of least privilege.

• Primary Function: Authorizes outgoing transactions.
• Security Model: Must be stored offline (cold storage) for high-value accounts.
• Relationship: Possession of both the Spend Key and View Key grants complete control over an account.

A cryptographic method that allows one party to prove the validity of a statement without revealing the underlying data. View Keys in zk-based systems (e.g., Zcash) rely on ZKPs to enable transaction verification.

• Core Mechanism: Enables selective transparency; the network validates transactions without exposing sender, receiver, or amount.
• Use with View Keys: A View Key can decode transaction details that are otherwise hidden by ZKPs, serving as a designated "audit" tool.

A one-time address generated for each transaction to a recipient, enhancing privacy by preventing blockchain analysis. A View Key is essential for finding transactions sent to one's stealth addresses.

• How it Works: The sender generates a unique, random address using the recipient's public View Key and Spend Key.
• View Key's Role: The recipient uses their private View Key to scan the blockchain for outputs created for their stealth addresses, enabling them to detect incoming funds.

The practice of providing verifiable transaction records to authorized third parties, such as auditors or tax authorities, using a View Key.

• Controlled Transparency: An entity can share its View Key with an auditor without granting spending authority.
• Regulatory Use Case: Required for Virtual Asset Service Providers (VASPs) under Travel Rule regulations (e.g., FATF Recommendation 16) to share transaction originator and beneficiary information.

The cryptographic process of generating multiple keys, like View and Spend Keys, from a single master seed or secret. This creates a hierarchical deterministic (HD) wallet structure.

• Standard: Defined in BIP-32/44 for Bitcoin and adapted for privacy coins.
• Benefit: A single backup seed phrase can restore all keys, including the View Key, for wallet recovery.
• Path Separation: View and Spend Keys are derived along different derivation paths for logical separation.

A network participant that downloads and validates the entire blockchain. To use a View Key, a wallet typically needs to scan data from a Full Node or a trusted server providing blockchain data.

• View Key Scanning: The wallet uses the View Key to cryptographically test every transaction output on the blockchain to find those belonging to the user.
• Privacy Consideration: Using a third-party server for scanning can leak information; running a personal full node is the most private method.