Monero’s promise is that nobody can see your balance or your counterparties. But that same privacy creates a practical problem: how do you prove to someone that you actually paid them? On Bitcoin you point at a public transaction and anyone can trace it. On Monero the recipient’s balance, your outputs, and the amounts are all hidden, so a screenshot proves nothing. The answer is view keys and transaction keys, and using them correctly means understanding exactly what each one reveals and what it keeps private.
The two keys inside every Monero address
A Monero wallet is built from two key pairs. The spend key pair controls the money: whoever holds the private spend key can spend the funds, full stop. The view key pair is the reader. The private view key is what your own wallet uses to scan the blockchain and detect which outputs belong to you, and it is the piece you can share selectively.
Hand someone your private view key and they can independently detect every incoming payment to your wallet. What they cannot do is spend anything, and, importantly, they cannot see what you spend. Outgoing spends are bound to key images, and those are derived with the spend key. This split is what makes selective disclosure possible in Monero at all.
Proving a payment to a third party
Say an exchange, an auditor, or a merchant asks you to prove a transfer. There are two standard methods, and they reveal different amounts of information.
Method one: the transaction private key. When your wallet constructs a transaction it generates a one-time transaction key. The command get_tx_key in the CLI wallet (or the equivalent in GUI wallets, usually under transaction details) returns it. Give the recipient the transaction ID, the transaction key, and your address. Their wallet runs check_tx_key and mathematically confirms that this transaction paid that address that amount, without any other transaction of yours being visible. This is the normal method for proving a single payment, and it leaks nothing about the rest of your wallet. It works because the recipient derives the same one-time public key the funds were locked to and can see the output and amount on the blockchain once they know where to look.
Method two: the private view key plus key images. An auditor who needs your full incoming history gets your private view key to scan every payment you have received. If they also need your outgoing history and running balance, you additionally export your key images with export_key_images. The key images let the auditor see which outputs have been spent, and crucially they can verify a spend happened and how much left, without ever being able to spend anything themselves, since spending still requires the private spend key. This is the standard setup for exchanges proving solvency of Monero reserves to an independent examiner.
What each piece actually reveals
It is worth being blunt about the tradeoffs, because sharing the wrong piece undoes the privacy you bought Monero for.
The transaction key reveals one payment: its recipient, its amount, and nothing else. The private view key reveals every incoming payment, ever, including future ones until you change it, but nothing outgoing and not your balance. Key images add the outgoing side and thus the balance. The private spend key reveals everything and hands over the money. Never paste that one into anything except a wallet you are importing into.
One more nuance: subaddresses exist partly to make view key sharing safer. If you gave every counterparty the same primary address, one leaked view key exposes every relationship in one list. If you gave each counterparty its own subaddress, the same view key still exposes the underlying wallet, but the auditor at least cannot trivially tell which payment came from whom. For a refresher on how primary addresses, subaddresses, and integrated addresses differ, see our guide to Monero address types and why two of them start with 8.
Common mistakes
Exporting key images from a wallet that is not fully synced produces a partial list, and an auditor comparing against a blockchain scan will report phantom unspent outputs. Always sync first. This is the same discipline that bites people restoring old wallets: the wallet must scan the entire history before any of its derived data is trustworthy, which we cover in detail in what actually gets recovered when restoring from seed.
The second mistake is treating a view key as revocable. It is not. Once shared, every payment to that wallet is readable by the holder forever. The only fix is sweeping to a fresh wallet, which costs a transaction fee and burns your address continuity.
The third is sharing a view key in a channel that identifies you, which turns a privacy tool into a self-incrimination tool. Use a separate channel for key material and for identity, the same separation of concerns that makes cold signing worthwhile for spending. If you have never worked through how a watch-only setup keeps keys offline, read our walkthrough of cold signing a Monero transaction.
Practice it once with a small amount
Before you need to prove a four-figure payment to a lawyer, run the whole loop once: send yourself a small amount between two wallets you control, fetch the transaction key, check it with check_tx_key, and export key images. Ten minutes of rehearsal means that when the real request arrives, you hand over the right key the first time instead of guessing under pressure. In Monero, as with key management generally, the expensive mistake is the one made in a hurry.