A View Key Is Not a Transparent Chain

Monero-class ledgers are opaque by default. Outsiders do not get a public graph of who paid whom or how much. The triad design lives in the companion note on Monero-class privacy. This note is a different cut: how optional disclosure works when you choose to show something, without turning the base chain into a transparent database.

Thesis, stated once: a private view key is an explicit allowance on an opaque ledger — not a second public ledger. Sharing it (or building a view-only wallet from it) can let a third party recognise incoming activity for an account. It does not hand them spend authority, and it does not make the rest of the network’s history suddenly readable. “I can share a view key with my accountant” is selective disclosure — not Bitcoin-style transparency with a friendlier label.

Educational only. Verify against the Moneropedia and docs you are reading. Protocol literacy — not a custody setup guide.

Two keys, two powers

Moneropedia’s account entry is the clean split: an account rests on a spend key and a view key. The private spend key is the single key required to spend funds. The private view key is the allowance that can reveal transactions to a third party — Moneropedia names auditing and accounting as the motivating examples.

Monero Docs puts the same split operationally: the private spend key builds one-time private keys that authorise spending related outputs; the private view key recognises your incoming transactions on an otherwise opaque blockchain. Under official deterministic derivation, the private spend key is also an alternate representation of the mnemonic seed. Lose the spend side and someone can move funds. Share only the view side and they still cannot sign spends from that material alone. Selective disclosure starts when you choose to export the private view key (or a view-only wallet from address + private view key).

What “private, optionally transparent” means

The view-key Moneropedia page states the contrast without fog: Monero features an opaque blockchain with an explicit allowance system called the view key, “in sharp contrast with transparent blockchains” used by cryptocurrencies not based on CryptoNote. The project’s phrase is “private, optionally transparent.”

That does not mean the chain has flip-switch public blocks. It means (1) the default published ledger does not hand outsiders a reusable address graph and clear amounts the way transparent chains do, and (2) the account holder can grant a cryptographic window — the private view key — so a chosen party can see activity related to that account. Everyone else still sees an opaque chain. Your accountant’s window is not a block-explorer free-for-all.

What a shared view key reveals — and what it does not

Moneropedia is blunt about the incoming scope: sharing a private view key allows access to view every incoming transaction for that address. Official user guides restate the same for view-only wallets: they see incoming transactions; they do not hold the mnemonic or private spend key; they cannot sign spends.

Equally important is the outgoing limit. Moneropedia warns that outgoing transactions cannot be reliably viewed from the view key alone, so a balance shown via a view key should not be relied upon. The view-only wallet guide is the practical twin: if the wallet has outgoing transactions, the displayed balance will not be correct until you import the accompanying key images of each output.

Mechanism, not footnote: recognising an output as “yours” uses the view key. Knowing whether that output was later spent needs key images — material the spend-capable wallet can export and a view-only wallet can import (export_key_images → import_key_images in the CLI reference and cold-signing docs). Without key images, a view-only surface can look like a growing inbox of receives while silently missing spends. With key images, it can reconcile spent status — still without gaining the private spend key.

A bare private view key is strong for “what landed,” weak as a solo proof of “what is left.” “Share with accountant” may need a key-image workflow if spend history matters — not a drop-in transparent explorer.

View-only wallets and narrower proofs

Official docs describe creating a view-only wallet from the main address plus private view key (monero-wallet-cli --generate-from-view-key …, or GUI restore-from-keys with spend key left blank). Named uses: validate incoming payments to cold or hardware setups, monitor donation inflows, library-level payment validation — receive-visibility jobs. View-only can help construct unsigned transactions for offline signing — still not “spend from the view key alone.” Cold-signing docs are explicit: without key images, outgoing history and balances stay wrong until images are imported from the spend-capable side.

If the goal is “prove this one payment,” wallet tooling exposes scoped proofs (get_tx_proof / check_tx_proof, spend proofs, reserve proofs) — a receipt, not continuous scanning. A view key is an ongoing lens; a transaction proof is one receipt. Transparent chains collapse that distinction: the explorer is always on. CLI docs also warn that tx-key / proof checks do not prove funds remain spendable (time-locks, already spent, or one-time-address duplication).

Subaddresses: one view key, many receive doors

Subaddresses publish a fresh receive door per payer or purpose without a pile of seeds. Monero Docs’ subaddress page is primary: indexes feed a derivation from the standard address’s private view key a:

m = Hs("SubAddr" || a || account_index || subaddress_index_within_account)

Public keys follow (D = B + m·G, C = a·D), with (0,0) as the standard address. Accounts are soft wallet groupings — not separate consensus objects.

Two disclosure facts. Scanning unity: docs state that deriving “sub view keys” from the main view key allows a view-only wallet that monitors the entire wallet including subaddresses — not “only the primary address.” Receive unlinkability is for outsiders, not for your view-holder: subaddresses help stop a payer from trivially linking payouts; someone holding your private view key has the scanning allowance. Do not confuse those roles. Docs caveat: sweeping many subaddresses in one transaction can link them on-chain. Lesson: one shared private view key is a wide lens, not a per-subaddress peephole, unless you structure separate wallets.

Audit without a public money graph

Transparent ledgers make every payment a permanent, world-readable row — useful to uninvited auditors, and also to employers, stalkers, competitors, and whoever buys a scrape later. Selective disclosure inverts the default: the ledger stays opaque; disclosure is an explicit grant with a known aperture.

Civil-liberty framing that travels: mutual-aid books, donor privacy, payroll under political risk, commerce where a permanent money graph is a safety hazard. Not “hide from lawful process” — auditability and mass surveillance are different shapes.

Looking ahead without rehashing rings

Today’s incoming view keys are the live allowance. Kayaba’s April 2024 getmonero.org FCMP development post lists outgoing view keys among features FCMP++-era work can support — spend detection with certainty and simpler “one view key” UX. Future vocabulary only; see the FCMP++ note. Honesty stays with Moneropedia now: incoming recognition is strong; bare view-key balances are not.

What this note deliberately does not do

It does not re-teach ring signatures, RingCT, or full-chain membership proofs beyond short cross-links. It does not rank wallets, walk cold-storage builds, or give tax workflows for any jurisdiction. It does not discuss prices, yields, swaps, or “how to disappear.” It does not claim a shared view key reveals nothing sensitive — incoming history is sensitive — only that disclosure is opt-in and account-scoped. It does not equate view-key sharing with making Monero “transparent like Bitcoin.”

Educational takeaway: opaque by default; disclose by allowance. Spend key moves funds. View key recognises receives. Key images reconcile spends for view-only balance truth. Subaddresses multiply doors under one scanning root. Proofs shrink disclosure to a receipt. None of that is a public explorer with a nicer UI.

Related on CryptoDecentral

• Privacy pillar
• Network metrics
• What Transparent Ledgers Leak — and Why On-Chain Privacy Matters
• From Rings of 16 to the Whole Chain: What FCMP++ Changes

Further reading (primary)

• View Key — Moneropedia
• Spend Key — Moneropedia
• Account — Moneropedia
• View-Only Wallets — user guide
• Private Keys in Monero — Monero Docs
• Subaddress — Monero Docs
• Offline Transaction Signing — Monero Docs
• monero-wallet-cli reference — proofs & key images
• Full-Chain Membership Proofs Development (outgoing view keys mentioned)