What is a View Key?

Introduction

View keys are cryptographic keys that let someone see transaction data on a privacy-preserving blockchain without necessarily giving them the power to spend funds. They exist because private systems create a tension that transparent blockchains do not have: if transactions are hidden from everyone else, how does the recipient find their own payments, and how can a user selectively reveal activity to a wallet, an auditor, or an exchange without surrendering full control?

That tension is the heart of the idea. On a transparent chain, visibility is automatic because everything is public. On a shielded or encrypted system, visibility has to be reconstructed by the party who holds the right secret. A view key is that secret, or part of that secret. It turns privacy from an all-or-nothing property into something more precise: private by default, but optionally transparent to specifically authorized viewers.

The exact meaning of a view key depends on the protocol. In Monero, the private view key is part of a two-key wallet model and is used to recognize incoming outputs that belong to an address. In Zcash Sapling, there is a distinction between an incoming viewing key and a full viewing key, with the latter able to recognize both incoming and outgoing notes without spend authority. In Secret Network, viewing keys act more like access-control credentials for encrypted smart-contract state. These are related ideas, but not identical ones. The common thread is that a view key grants read capability over data that is not otherwise public.

Why do private blockchains need view keys?

The problem view keys solve becomes clearer if you start from first principles. Suppose a blockchain hides recipient information, hides amounts, or encrypts contract state. That gives privacy against the public, but it also removes the simple mechanism by which a user, wallet, or accounting system would normally observe activity. If every transaction looks opaque to outsiders, then it also looks opaque to the recipient until they apply the right secret to it.

So there are really two requirements at once. The system must hide data from everyone who is not authorized, but it must still let the rightful recipient scan the chain and detect, “this output is mine.” And beyond that, many real users need delegated visibility. A company may want an accountant to verify incoming payments. A donor address may need public monitoring without exposing spending power. A cold wallet may need an online companion that can watch for deposits but cannot spend them. View keys exist because these are not edge cases; they are basic operational needs in any private payment system.

This is why privacy systems often separate observation from authorization. Spending is dangerous; viewing is also sensitive, but it is a different capability. Once you separate those capabilities cryptographically, you can hand out limited access. That is the core design move.

How do view keys let recipients recognize private outputs on a public ledger?

The key idea is simple even if the cryptography underneath it is not: a private blockchain transaction is usually not addressed to your public identity in a way that outside observers can recognize.

Instead, each payment creates a fresh destination artifact that only the intended recipient can identify.

• often called a one-time address
• stealth output
• note
• encrypted record

A view key is what lets the recipient test each candidate output and determine whether it belongs to them.

In Monero and the CryptoNote design it builds on, the mechanism is tied to stealth addresses. A user has two keypairs: a view keypair and a spend keypair. The sender uses the recipient’s public keys together with fresh randomness to derive a unique one-time public key for the output. On-chain, observers just see that one-time key and cannot link it to the recipient’s published address. But the recipient, using their private view key, can scan outputs and recompute the expected one-time destination for themselves. If the recomputed value matches the on-chain output, they know the output belongs to them.

The formal pattern in the CryptoNote specification is this. Let the recipient have private keys a and b, with corresponding public keys A = aG and B = bG. The sender chooses random r, publishes R = rG, and creates the one-time destination key P = Hs(rA)G + B. The recipient checks outputs by computing P' = Hs(aR)G + B. Because aR = arG = rA, the recipient gets the same result when the output is theirs. That shared structure is the mechanism: both sides can derive the same hidden destination, but outside observers cannot.

What matters here is not memorizing the formula. What matters is the invariant it creates. **The sender can target the recipient without publishing the recipient’s identity, and the recipient can later recognize the payment without everyone else gaining that ability. ** That is the reason view keys exist in this form.

How does a view key differ from a spend key?

A common misunderstanding is to think that a view key is just a “weaker private key.” That is not quite right. A well-designed view key is not merely a reduced-permission interface layered on top of the same secret. It is usually part of a key structure where the ability to detect or decrypt is intentionally separated from the ability to authorize spending.

In Monero, the spend key remains the critical authority for moving funds. The view key lets you discover which outputs belong to the wallet. According to Monero’s documentation and technical guides, a person can use the view key to determine whether their address owns an output, while the spend key is needed to spend that output and to determine spending status retrospectively through key-image-related mechanisms. Sharing the private view key therefore grants meaningful visibility without directly granting spending rights.

That separation is why a view-only wallet is possible. Monero’s official user guide defines a view-only wallet as a wallet that can see incoming transactions but cannot sign transactions because it does not hold the mnemonic seed or private spend key. The wallet can monitor deposits, but by itself it cannot move funds. This is useful for donations, accounting, payment validation, and online monitoring of a cold wallet.

A similar separation appears in Zcash, but with more granularity. The Sapling protocol defines an incoming viewing key for recognizing incoming notes and a full viewing key for recognizing both incoming and outgoing notes without spend authority. That distinction is important because it shows that “viewing” is not a single universal permission. A protocol can expose only receipt-side visibility, or broader wallet activity visibility, depending on how its encrypted records and note ciphertexts are designed.

How can you monitor a private wallet without giving spending authority?

Imagine a team treasury that stores funds in a cold Monero wallet. The team wants day-to-day visibility into donations and customer payments, but they do not want the online machine that tracks balances to hold the spend key.

So they create a view-only wallet from the wallet’s main address and private view key. The online wallet software scans new blocks. For each candidate output, it uses the private view key to test whether the output matches the wallet’s address structure. When a matching output appears, the wallet marks it as incoming funds for that treasury. Staff can now confirm that a payment arrived, reconcile invoices, or monitor campaign income.

Notice what has and has not happened. The online system learned how to recognize incoming funds, but it never received the secret needed to sign a spend. If an attacker compromises that online machine, the attacker may learn a great deal about incoming payment history, but they still cannot directly drain the wallet.

This example also shows where the design is less than perfect. Monero’s official guidance warns that a view-only wallet does not, by default, reliably learn outgoing transactions. If the original wallet has spent funds, the view-only wallet’s displayed balance can therefore be wrong unless it also imports the relevant key images for spent outputs. In other words, recognizing incoming outputs and proving which of those outputs were later spent are different problems. The view key solves the first problem cleanly; the second depends on additional information.

That limitation is not an implementation footnote. It tells you something fundamental about the privacy model: in Monero, the protocol is deliberately designed so that spend activity is not trivially inferable from receipt-side visibility alone.

What transaction data does a shared view key expose?

The phrase “share your view key” sounds simple, but the consequences depend on the protocol.

In Monero, official documentation says that sharing a private view key allows access to every incoming transaction for that address. Technical material further explains that a third party with the view key can read transaction history in the sense of recognizing outputs that belong to the user and decrypting output amounts where the protocol permits. But the same body of documentation also cautions that outgoing transactions cannot be reliably viewed in a plain view-only setup, and therefore balance figures shown through a view key should not be relied upon without the extra spend-status information carried by key images.

That means a Monero view key is best understood as receipt visibility, not necessarily a complete independent audit of all wallet activity. If a business tells an auditor, “here is our view key, so now you can reconstruct our exact wallet balance and all outflows,” that statement may be too strong. The auditor can gain meaningful transparency, but the quality and completeness of that transparency depends on what additional wallet data is provided.

Zcash demonstrates a different point in the design space. Its Sapling full viewing key is specified to recognize both incoming and outgoing notes without spending authority. That does not make Zcash “more private” or “less private” in the abstract; it means the protocol chose a different selective-disclosure capability. The important lesson is that “view key” is a family resemblance term, not a single standardized permission set.

On Secret Network, the term shifts again. There, viewing keys are described as credentials that allow access to encrypted balances, transaction details, or smart-contract data that is private by default. The logic is similar (selective disclosure of otherwise hidden information) but the object being revealed is not just payment ownership on a shielded ledger. It may be contract state, token balances, or application data.

Why are view keys used with stealth addresses and shielded transactions?

View keys do not make sense in isolation. They exist because the system has already hidden something.

In a transparent system like Bitcoin’s base model, there is no need for a special key to see incoming funds. If you know an address, you can inspect it publicly. The privacy problem there is almost the reverse: how do you stop everyone from seeing too much? In a shielded system, the problem changes to: how do you let the right party see anything at all?

That is why view keys naturally sit next to stealth addresses and shielded transactions. Stealth addressing creates unique per-output destinations so observers cannot link payments to a recipient’s public address. Shielding or encrypted note systems hide amounts and metadata from the public chain view. Once those privacy layers are in place, the protocol needs a mechanism for the recipient to recover visibility. The view key is that mechanism.

RingCT in Monero adds another layer to this story by hiding amounts with commitments and per-output shared secrets. The recipient can recover the amount because they can compute the relevant shared secret, while outsiders cannot. Here again, the broad pattern is the same: hidden on-chain data becomes readable only to someone with the right secret.

What privacy trade-offs follow from sharing a view key?

The strongest reason to use a view key is selective disclosure. The strongest reason to be careful with one is that it creates a second privacy boundary.

If you reveal a long-lived address view key to a third party, you are not making the chain public to everyone. But you are making it significantly more transparent to that key holder; often across the full history of that address, and sometimes future activity as well. Reputable secondary analysis of privacy systems points out that the blast radius of compromise scales with the scope of the view key. A per-transaction disclosure artifact leaks one transfer. An address-scoped view key can leak an entire account history.

This is why custody matters. A shared view key may sit with an auditor, an exchange, a wallet provider, or internal finance staff. Each additional holder becomes a potential privacy failure point. General key-management guidance from NIST applies here even though it is not blockchain-specific: private and secret keys require confidentiality protection, and key management is a lifecycle process involving secure generation, storage, distribution, use, backup, and destruction.

In practical terms, that means a view key should be treated as sensitive key material, not as harmless metadata. The user may not lose funds directly if it leaks, but they may lose confidentiality over their transaction history or encrypted application data. In many contexts, that is a serious loss.

Where systems need stronger governance over key custody, threshold methods can help. A concrete example from industry is Cube Exchange’s decentralized settlement design: it uses a 2-of-3 threshold signature scheme in which the user, Cube Exchange, and an independent Guardian Network each hold one key share, no full private key is ever assembled in one place, and any two shares are required to authorize a settlement. That example is about spending authorization rather than view keys specifically, but it illustrates the general principle that sensitive cryptographic authority can be split across parties instead of concentrated in one custodian. The same custody logic is relevant when organizations decide how to store or delegate view access.

When do view-key assumptions fail and what breaks in practice?

The clean story is that a view key gives visibility without spend power. The less clean story is that this depends on protocol design, wallet tooling, and what exactly you mean by “visibility.”

The first assumption that can fail is completeness. Monero’s own documentation explicitly warns that view-only wallets do not inherently see outgoing transactions and may display incorrect balances unless key images are imported. So if you assume “view-only” means “perfect audit replica,” you will misunderstand the tool.

The second assumption that can fail is revocability. Most view-key systems do not behave like a modern SaaS permission panel where you can click “revoke access” and instantly make the other party forget what they already learned. If a third party had a persistent view key and used it to scan historical activity, that knowledge cannot be clawed back cryptographically. In some protocols, changing to a fresh wallet or new address structure may limit future leakage, but the old disclosures remain disclosed.

The third assumption that can fail is standardization. Across privacy systems, “view key” can mean a Monero-style private view key, a Zcash incoming viewing key, a Zcash full viewing key, a unified viewing key container, a per-transaction proof artifact, or an application-level access token for encrypted state. If you carry expectations from one ecosystem into another, you may overestimate or underestimate what the key reveals.

Even within the same ecosystem, there can be important distinctions. Zcash’s unified viewing key standards combine multiple viewing keys into a single container so wallets can handle multiple receiver types together. That is useful for interoperability, but it also reinforces the point that viewing authority can be composed in different scopes and layers. There is no single canonical shape for “read-only access” across private systems.

How are view-key concepts applied outside shielded coins (contracts and confidential transfers)?

The concept is broader than private payments.

Secret Network uses viewing keys because contract inputs, outputs, and state are encrypted by default. The question there is not, “which output on the chain belongs to me?” but, “who is allowed to see this private contract state or token balance?” The mechanism still serves selective disclosure: a wallet, explorer, or auditor can be granted visibility without making the data public to every node operator or chain observer.

Other systems arrive at similar goals through different tools. Solana’s Confidential Transfer extension uses per-account ElGamal and AES keys to encrypt balances and supports an optional auditor public key for selective disclosure of confidential transfer data. That is not branded as the same view-key model as Monero or Zcash, but the family resemblance is obvious: hidden on-chain values, combined with a cryptographic path for an authorized party to decrypt or inspect them.

Seeing these examples together helps avoid a narrow definition. A view key is not defined by a particular chain or formula. It is defined by the role it plays: granting read access into an otherwise private cryptographic system without necessarily granting write or spend authority.

Which aspects of view keys are fundamental versus protocol conventions?

The fundamental part is the separation of capabilities. A privacy system needs some way to keep information hidden from the public while still allowing authorized inspection. That is the enduring idea.

The convention is how a given protocol packages that capability. Monero packages it through a two-key address model and scanning for stealth outputs. Zcash packages it through incoming and full viewing keys derived from spending key material, plus encrypted note structures that support recognition of shielded activity. Secret Network packages it as access-control credentials over encrypted smart-contract data. Unified viewing keys in Zcash are a further convention about transport and interoperability, not the underlying reason the concept exists.

Another convention is whether view authority is wallet-scoped, address-scoped, output-scoped, transaction-scoped, or asset-scoped. Those are design choices with different privacy and governance consequences. The more scope a key has, the more useful it becomes for auditing; and the more damaging it becomes if leaked.

Conclusion

A view key is the cryptographic answer to a simple problem: in a private system, how can the right person see hidden data without making it public to everyone or giving away spending power?

The durable intuition is this: privacy hides by default; view keys selectively restore visibility. Everything else (the exact formulas, whether outgoing activity is visible, whether the scope is incoming-only or full-wallet, whether the data is payments or contract state) depends on the protocol’s design choices. If you remember that, the concept stays clear even as the implementations change.

What should you understand about view keys before depositing or delegating access?

Before delegating or relying on view keys, confirm what level of visibility the protocol grants and whether that visibility is sufficient for auditing or deposits. On Cube Exchange, factor that understanding into how you fund accounts and who you authorize to monitor activity so you don’t inadvertently expose historical or future transaction history.

1. Read the protocol and wallet docs to confirm whether the view key is incoming-only or a full viewing key (for example: Monero requires key images to prove spends; Zcash Sapling distinguishes incoming vs full viewing keys).
2. Create and share minimal credentials: export a view-only wallet or the private view key only, not the spend key, and label the key with scope and expiry for the auditor.
3. If you need outgoing/spend reconciliation, request key images or explicit spend proofs from the owner before relying on the view key for balances.
4. Fund your Cube account with fiat or supported crypto and, when depositing shielded assets, verify the deposit via the chain-specific confirmation threshold before trading or withdrawing.