What a Monero view key reveals

A Monero wallet has two key pairs. The spend key signs transactions; the view key finds them. In a wallet made from the standard 25-word seed the private view key is not chosen separately: account.cpp derives it as the Keccak hash of the private spend key, which is why one seed restores both.

What the view key shows

The private view key and the address are enough to recognise every output sent to the wallet, with its amount: the view key reproduces the shared secret the sender used to make the one-time address and to encrypt the amount, as how Monero privacy works describes. That covers the wallet's subaddresses too, since they are derived from the same keys. In the CLI wallet, viewkey displays it.

What it does not show reliably is spending. A spend is marked on the chain only by a key image, and a key image is made with the private spend key, so a view-only wallet cannot tell which of its outputs have gone. Moneropedia says as much: outgoing transactions cannot be reliably viewed, and the balance a view-only wallet shows should not be relied upon.

The remedy is to hand the view-only wallet its key images. The full wallet's export_key_images writes a signed set of them, and the view-only wallet's import_key_images reads it. After that the view-only wallet can show spends and a true balance, for the outputs it was told about, as of the moment of export.

Proofs instead of keys

Handing over a view key shows a wallet's whole incoming history. Usually the question is narrower, and the CLI wallet has a proof for each.

One payment, with the transaction key. get_tx_key prints a sent transaction's secret key, r; with it, check_tx_key lets anyone check the amount going to an address in that transaction. Only the sender has r, so this is how a sender shows they paid.

One payment, without disclosing a key. get_tx_proof makes a signature from either the transaction secret key or the view secret key, and its help text notes that this does not disclose the secret key; check_tx_proof verifies it. A recipient can make one with their view key to show they were paid.

That you made a transaction. get_spend_proof makes a signature with the spend secret key showing that you created a given transaction; check_spend_proof verifies it.

That you hold at least an amount. get_reserve_proof proves you own at least a given amount, or with all, your whole balance. It needs the full wallet, and it does not stay private over time: the proof carries the transaction id, output index and key image of every output it covers, and check_reserve_proof asks the node whether those key images are spent. Whoever holds the proof can later see when each of those outputs is spent.

Who should hold one

A view key is for someone who needs the whole incoming history and is trusted with it: an accountant, an auditor, a watch-only wallet on a phone that should not hold the spend key. For a single question — did this payment arrive, did you pay this invoice — a proof discloses less. A view key cannot move funds. It does disclose every incoming payment, past and future, for as long as the wallet is used.

What Carrot changes

Carrot, the addressing protocol that comes with FCMP++, splits the view key's job. In a wallet created under it, an incoming view key finds incoming payments, while a separate view-balance secret finds received and outgoing enotes alike, so a full view-only wallet can identify spent outputs. Between them sits a payment-validator tier that sees incoming payments but, unlike a view-only wallet today, cannot see the wallet's internal change; below it, an address-generator tier, meant for point-of-sale terminals, can make new addresses but cannot recognise any payment. The tiers apply only to wallets made under the new key hierarchy; existing wallets keep today's two keys, though the specification says they still gain its protection against the burning bug without migrating.