Monero
What Sharing a Monero Transaction Key Can Reveal
Learn what a Monero transaction ID, transaction key, and payment proof disclose, how to check a payment, and why the verifier's node still matters.
A Monero transaction key can let someone check how much a specified transaction paid to a supplied recipient address. Sharing it with the transaction ID and that address is a deliberate disclosure of payment information. It does not give the recipient your wallet's spending keys or expose every transaction in your wallet.
This guide explains that disclosure and the checks a payment dispute requires. It is separate from our coverage of legacy transaction-proof verification weaknesses, which concerns how wallet software handles information from a malicious node.
We checked the commands against Monero v0.18.5.4 on November 8, 2026, using the upstream source. We did not create or verify a live payment for this guide.
Transaction IDs, keys, and payment proofs
| Item | What it is | What sharing it does |
|---|---|---|
| Transaction ID, or TXID | The hash identifying a transaction | Identifies a public blockchain record. Your message can also link that record to you |
| Transaction secret key | Secret material associated with creating that transaction | Enables payment checks against supplied recipient addresses when the required keys and transaction data are available |
| Payment proof | A proof generated for a transaction and address, optionally bound to a message | Lets another person check that payment claim without receiving the raw transaction secret key |
The transaction secret key discussed here is different from the transaction public key recorded on the blockchain. It is also different from your private spend key and recovery seed. The latter control your funds and must remain secret.
A TXID alone does not disclose a normal modern Monero transaction's recipient address or hidden amount. Public data still includes such things as transaction structure and fees. Giving a TXID to a merchant or posting it beside your name adds context that the blockchain itself did not supply. Monero's payment-proof guide explains why a payment check needs more than a transaction ID.
An example: proving a payment to a merchant
Suppose Alice buys an item from Bob for 0.25 XMR. The amounts and participants in this example are hypothetical. Bob gives Alice an address, she pays it, and they later disagree about whether the payment arrived.
Alice can give a verifier the transaction ID, the address Bob supplied, and the transaction key. With valid transaction data, the verifier can check the amount sent to that address in that transaction. They still need independent evidence that the address belonged to Bob and was the one specified for the order.
That check does not prove what was ordered, whether Bob delivered it, or who is legally entitled to a refund. Nor does possession of a copied key establish that the person presenting it was the original sender. The key can be forwarded.
If Alice posts all three items publicly, anyone who receives them can perform the same check. Sending them privately to a dispute resolver limits the initial audience, but cannot prevent that recipient from retaining or forwarding the information.
Checking outputs without exposing the whole wallet
Monero creates one-time output destinations rather than placing the recipient's ordinary address directly in each payment output. The wallet's payment-checking code uses the transaction key and supplied address to derive expected output keys, find matching outputs, and decode the corresponding confidential amounts. It checks those amounts against the transaction's commitments. Tagged wallet implementation.
This is not a command to recover every recipient address from a transaction. The verifier supplies an address to test. A transaction can have multiple recipients, and disclosure can matter beyond the address included in your message. Someone with the relevant transaction key material can test other addresses they know against the same transaction.
Some transactions use additional transaction keys, including in subaddress-related constructions. The CLI can return the primary key followed by additional keys as one hexadecimal string. Do not shorten it to the first 64 characters because an older example shows only one key. The CLI's key-output and checking code handles this combined form.
A transaction key is not a wallet-wide view key. It does not, by itself, reveal all incoming payments, the wallet balance, or the true spent input among a ring's members. It also does not authorize spending the recipient's outputs. See the glossary for view keys and spend keys if you need to distinguish those roles.
Retrieving and checking a transaction key
The following commands run inside monero-wallet-cli, not in a shell and not in the monerod console. Replace the uppercase placeholders with the relevant values.
In the sending wallet:
get_tx_key TXID
This displays sensitive transaction information in the wallet's console. Avoid screen sharing and do not include that output in an unrelated troubleshooting log.
In a compatible wallet used to check the payment:
check_tx_key TXID TXKEY ADDRESS
Supply the exact recipient address and the complete returned key material. The wallet contacts its daemon for transaction data and reports the amount it finds for that address, along with available pool or confirmation information. The official payment-checking instructions describe this workflow.
The sender's wallet must have the necessary transaction key information. The CLI's store-tx-info setting controls saving outgoing transaction information. Enabling it after losing a key is not a way to reconstruct that key from a public TXID. Preserve wallet files when local payment records matter, and check hardware-wallet support in the software you use rather than assuming every device exposes the same commands.
Restoring a wallet from its seed can leave you without local payment records. Our Tails wallet backup guide explains why wallet files and recovery information serve different purposes.
A payment proof avoids handing over the raw key
The CLI also supports a proof bound to a specified transaction and recipient address. An optional message can identify the claim you intend to make. In the sending wallet, an example is:
get_tx_proof TXID ADDRESS invoice-2026-0042
The wallet saves a proof to a file and reports its filename. Give the verifier that file, the TXID, the address, and the exact message. In their wallet console, they can check it with:
check_tx_proof TXID ADDRESS PROOF_FILE invoice-2026-0042
PROOF_FILE is the path to the saved proof on the checking machine. If you omit the message when generating a proof, omit it when checking too. A message mismatch makes a different claim from the one signed. The v0.18.5.4 command parser defines these arguments.
A proof reduces disclosure of the raw transaction secret material, but still discloses the payment relationship it demonstrates. It can be copied. A message does not make the proof self-destruct or stop a recipient from publishing it.
Check the reported amount and transaction status as well as the signature result. A valid signature is not a promise that an unconfirmed transaction has settled. The verifier also needs a trustworthy view of the chain.
The remote node still matters
The payment-checking wallet obtains historical transaction information from a daemon. A remote daemon may lie or withhold information. Even when a proof binds the payment correctly, confirmation and pool information need separate scrutiny. Using a node you operate can reduce dependence on an unknown operator, but it is not a substitute for corrected wallet software.
As of the November 8 review, PR #11693 remains open. It addresses check_tx_key accepting altered amount information for a legacy version-1 transaction when a malicious daemon supplies data not properly bound to the requested transaction hash. PR #11696 also remains open and addresses related spend-proof input verification.
The preparatory PR #11654 merged into the development branch on November 7. The latest stable CLI release checked was still v0.18.5.4, published before that merge. A merge into development is not a released patch.
Do not treat switching to a payment proof as an unconditional workaround for every legacy verification issue. Proof types use different paths, and the version, transaction format, node, and exact check matter. The legacy-proof article documents those distinctions and the remaining verification gaps.
These issues concern the reliability of a payment or spend claim presented to a verifier. They do not establish that sharing a transaction key lets an attacker steal the wallet's funds or that Monero's transaction privacy has been broken.
Limit disclosure during a dispute
Confirm the recipient address from the invoice or another authenticated record. Decide who needs the payment evidence and use a private channel appropriate to that relationship. Keep the context needed to interpret the proof, including any message, but avoid adding unrelated wallet screenshots or transaction history.
Do the verification in software you trust. A website that offers to check a payment receives whatever you enter into it. It does not need your recovery seed or private spend key. If support requests either, stop and use the wallet project's documented support route.