Note

A Payment Proof Is Not a View Key: What a Monero tx_key Actually Proves

A Monero payment proof is a receipt for one directed amount in one transaction — not a view key. What a tx_key, InProof, OutProof, or SpendProof actually shows, and what sharing a private view key still opens.

2026-11-06 · privacy, monero, payment-proof, tx-key, outproof, spendproof, view-keys, selective-disclosure, protocol-literacy, civil-liberties

Listen · 10 min · AI voice

Dark CryptoDecentral hex mesh: a single glowing teal receipt hexagon with a bronze seal floats left of a tall opaque bronze vault of locked hex cells; a thin dashed teal line touches only the receipt, never opening the vault. No text.

On a transparent chain, proving you paid someone is usually a block-explorer screenshot: transaction id, addresses, amount. On Monero the same dispute looks different, because that information is not sitting in public. The official prove-payment guide is blunt about the gap: "Monero, however, is private: that information is not available publicly on the blockchain. The steps are therefore a bit more involved."

Thesis, stated once: a payment proof is a receipt for one directed amount in one transaction — not a view key, and not selective disclosure of the whole wallet. Handing someone a transaction secret key (or a signed InProof/OutProof) lets them verify that payment. A SpendProof lets them verify the prover authorised that transaction, without naming the destination. Handing them a private view key opens an ongoing lens onto incoming activity for the account. Confusing the two is how "prove this tip" quietly becomes "watch everything I receive."

This sits beside the view-key selective-disclosure note, the Monero-class privacy triad, and why a subaddress is not a separate identity. Those covered continuous visibility and receive doors. This one covers the scoped receipt.

Mechanism one: the three pieces of a classic payment proof

The getmonero.org guide walks through Alice proving to Charlie that she paid Bob. She must supply three things:

the transaction ID (same role as on transparent chains),
Bob's address (again familiar),
the transaction's key — "which is new with Monero and other CryptoNote currencies."

That third piece is a one-time key generated for the transaction itself. In monero-wallet-cli, Alice retrieves it with get_tx_key TXID — but only if the wallet was set to store transaction keys (store-tx-info 1). Charlie then runs check_tx_key TXID TXKEY ADDRESS on an up-to-date chain. The wallet "will use the transaction key to decode the transaction, and display how much this particular transaction sent to this address." The GUI path is the same idea: History for the tx id and address, then a payment-proof (P) control for the tx key; Advanced → Prove/Check to verify.

Read the scope carefully. The proof binds one txid, one claimed destination address, and one amount to that address. It does not open Alice's other payments. It does not hand Charlie Alice's private view key. It does not, by itself, prove that Bob's address is really Bob's — the guide says Charlie "will want to double check with Bob the address is really his - same as with Bitcoin." And if Alice made several payments, "this needs repeating for each such transaction."

One caveat on the raw key: the check is scoped because Charlie supplies the address. The transaction key itself is not address-bound. Anyone who holds a copy can repeat check_tx_key against the same txid with other addresses. That is still one transaction, not a view key — but it is broader than a signed proof issued for a single destination.

Wallet RPC names the same operations: get_tx_key returns the transaction secret key for a txid; check_tx_key takes txid, tx_key, and address and returns received (atomic units), confirmations, and whether the tx is still in the pool.

Mechanism two: signed proofs without handing over the raw key

Raw tx keys are not the only receipt shape. Official Wallet RPC also exposes:

get_tx_proof / check_tx_proof — a signature over a txid, destination address, and optional message. Example signatures in the docs carry an InProofV1… prefix. The wallet emits an InProof when the address is one it received to (built from the private view key, without exporting that key) and an OutProof when it sent to that address (built from the transaction key). Verification returns good, received, and confirmation state. The optional message "further authenticate[s] the proving process"; a wrong message fails the check.
get_spend_proof / check_spend_proof — "Generate a signature to prove a spend. Unlike proving a transaction, it does not requires the destination public address." Signatures use a SpendProofV1… prefix. The CLI reference groups this under "prove you made the payment."

The CLI docs are explicit about lineage: learning and verifying the transaction private key r "was useful to create a proof of payment but got superseded by get_spend_proof." That command attests the prover authorised the txid; it does not replace the amount-to-address receipt. In practice, wallets still offer both families. The important literacy point is the same for either: you are exporting a per-transaction attestation, optionally bound to a message, not exporting the account's private view key.

What a matching proof proves — and what official docs say it does not

Docs and maintainers have tightened the wording on purpose. Wallet RPC's check_tx_key page states: "A matching key proves an amount was paid to the given address in that tx. It does not mean those funds are still spendable (time lock, already spent, or burnt one-time address). Same caveat as InProofs/OutProofs — see monero#8819." The check_tx_proof page repeats it: transaction proofs "do not guarantee that funds associated with a proof are spendable." The CLI reference Warning block says the same limit "applies to the getmonero.org prove-payment guide."

Issue #8819 (UkoeHB, citing Cremers, Loss, and Wagner) pressed for that clarification across CLI, docs, and guides: proofs do not imply spendability when outputs are time-locked, already spent, or burnt by one-time-address duplication. A clean received figure is still a directed-amount receipt — not a guarantee the recipient can spend those coins, and not Alice's live balance.

What the proof does leak to the verifier is real and intentional: that this txid directed this amount to this address (for tx-key / InProof / OutProof style checks), or that the prover authorised that spend (for SpendProof, without needing the destination). Share it only with parties who should know that payment. Do not treat "payment proof" as a euphemism for "wallet audit."

Why this is not a view key

Moneropedia's view-key entry draws the contrast the payment-proof tools are designed around. Monero has "an opaque blockchain (with an explicit allowance system called the view key)" and is called "private, optionally transparent." Sharing a private view key "allow[s] access to view every incoming transaction for that address." Outgoing activity is not reliably visible from the view key alone, so "the balance of a Monero address as shown via a viewkey should not be relied upon" without further material (key images — covered in the view-key note).

Line the instruments up by shape, not by convenience:

Instrument	Scope	Ongoing?	Spend authority?
Payment proof (tx_key / InProof / OutProof)	One tx → one address → amount	No — one receipt	No
SpendProof	Prover authorised this txid	No — one attestation	No (proves past spend authorship)
Private view key	Incoming for the account	Yes — continuous lens	No
Private spend key / seed	Authority over funds	Yes	Yes

A view key is selective disclosure of an account window. A payment proof is selective disclosure of a single directed payment. On transparent ledgers those collapse into the same explorer page. On Monero they are different keys and different RPC methods for a reason. Handing Charlie a tx_key so he can settle a dispute is not the same act as exporting view_key so an accountant can scan every inbound forever.

Moneropedia's transaction page reminds why the public chain alone is not enough: destinations are one-time public keys; recognising inbound needs the private view key. A payment proof is a deliberate bypass for one output path — a cryptographic receipt — without publishing that view key.

Why the receipt question travels

Opaque ledgers do not remove the human need to prove a payment. Freelancers, mutual-aid desks, open-source tip jars, and anyone arguing with a counterparty still need a way to show "this amount went there" without turning their whole wallet into a public spreadsheet. Payment proofs keep that civil-liberties use case available while preserving the default opacity that ring membership and the rest of the Monero-class stack are built for.

The practical habit is simple and global. When someone asks you to "prove the payment," ask whether they need a receipt for one txid or a lens on the account. When someone asks for a "view key to verify," ask whether a check_tx_proof / check_tx_key / check_spend_proof would settle the same dispute with less ongoing exposure. Scope is the privacy feature.

What this is not

This note does not rank wallets, explorers, or remote nodes, and it does not recommend running any particular service. It is not custody advice, and it does not discuss prices, yields, swaps, or trading. It does not claim every wallet UI labels InProof, OutProof, and SpendProof the same way, or that every installation has store-tx-info enabled. It does not call payment proofs useless because they omit spendability — they are receipts, and the official caveat is part of reading them honestly. It does not cover reserve proofs, multisig proof signing, or Seraphis-era renames beyond the InProof/OutProof/SpendProof vocabulary in today's RPC docs. And it does not re-litigate view-key or subaddress mechanics beyond the contrast required here.