To substantiate a specific Monero payment, agree on the transaction, recipient address and kind of proof the verifier will check. A txid alone does not publicly reveal the recipient and amount as a transparent-chain receipt would. A transaction key or supported signed proof can provide more evidence, but a successful check still does not establish that the funds are currently spendable or that a service credited the right order.
Decide which disputed fact needs evidence
“I sent it,” “this transaction directed an amount to that address,” and “the recipient can spend it now” are different statements. So is “the service has allocated it to my order.” Write down the statement you need checked before exporting anything from the wallet. A request described vaguely as “proof” can otherwise turn into unnecessarily broad disclosure.
The official payment-proof guide describes checking a transaction with its key and the recipient’s address, and emphasizes verifying that the address belongs to the intended recipient. A mathematically consistent result for an unrelated address does not resolve your invoice. Keep the original payment instruction as part of the evidence.
| Evidence offered | Question it can help answer | Conclusion to keep separate |
|---|---|---|
| Transaction identifier | Which transaction should be investigated? | Who received how much |
| Transaction key with address and txid | What amount the check associates with that address | Current spendability and customer-account credit |
| Supported signed transaction proof | Whether the specified proof verifies for the supplied context | Every other statement about the payer or order |
| Spend proof | Whether the claimed spend can be verified | A specific destination amount without further evidence |
| Private view key or wallet export | Broader wallet-inspection questions | That broad disclosure was needed for one payment |
A transaction key is not the wallet’s spend key
Use the wallet’s supported transaction details for the particular outgoing transfer. The transaction-specific key described in the guide is different from a wallet recovery phrase or private spend key. Do not send an entire wallet backup because a support agent asked for “the key.” Ask which exact evidence format is required and why.
A wallet may not retain the information needed for every proof method. The official guide specifically conditions transaction-key retrieval on saved transaction information. If your restored wallet does not offer it, record that limitation and ask the recipient to reconcile the transaction with its own wallet. Do not assume that changing a setting now recreates every item missing from an older wallet file.
In a fictional dispute, Rosa has the transaction identifier and the original recipient instruction but cannot retrieve a transaction key. Her useful next step is to ask the receiving service what evidence it can inspect and which proof methods it accepts. Paying a new “proof generation” deposit would create another payment without establishing the disputed one.
Signed transaction proofs have their own verification context
The current wallet RPC reference documents a signed transaction-proof check using the transaction identifier, recipient address, proof signature and any associated message. The same message must be used for checking. It reports proof validity separately from received amount, pool state and confirmations; one field should not stand in for the others.
Keep those inputs together in the case record. If the proof fails, compare the supplied address, transaction and message before concluding that the payment never existed. If it succeeds, record exactly what was checked. A proof file forwarded without its original context can become an impressive-looking attachment that nobody has actually verified.
The wallet API definitions also distinguish transaction-proof and spend-proof operations. They are not alternative names for one universal receipt. If a verifier needs evidence that a party made the spend, ask for the appropriate supported proof rather than inferring authorship from possession of a copied transaction-check result.
Successful verification does not establish a usable current balance
The Monero CLI reference explicitly warns that transaction-key and transaction-proof checks do not guarantee spendability. Funds can be locked, already spent or otherwise unavailable. Do not turn a successful amount check into an assurance that the recipient presently has an unlocked balance, or that every output was usable.
For an exchange or other receiving service, its internal allocation remains another question. The verifier should compare the checked address and amount with the actual order requirement and its own wallet records. A proof for a previous order, another receiving address or the wrong amount does not satisfy the current instruction merely because its signature verifies.
Rosa’s case can therefore end with a precise finding: a proof verifies for the stated transaction and address, while service allocation is still under review. That is useful progress. Replacing it with “everything is proven” would hide the unresolved part. Keep the recipient’s accounting answer distinct from the cryptographic check.
Choose a disclosure scope suitable for one payment
The Moneropedia view-key description explains that a private view key can reveal incoming transaction information for its scope. This is broader than giving evidence about one named transaction. The view-key guide provides more context on what this access means; it should not be the default response to an ordinary receipt request.
Prefer a private, verified support channel and the narrow evidence format the legitimate verifier can use. Do not place transaction keys, recipient links and invoices into a public forum simply because a proof does not grant ordinary wallet spending access. They can still reveal payment information. A copied proof can also be forwarded; adding a message does not make the disclosed document impossible to copy.
An evidence workflow for the sender and verifier
- Identify the disputed payment, original receiving instruction and exact transaction identifier.
- Confirm which proof method the verifier accepts, distinguishing transaction key, signed transaction proof and spend proof.
- Produce only the supported evidence for that transaction in a trusted wallet; do not reveal recovery words or private spend keys.
- Send the proof with its required address and message context through the agreed private channel.
- Have the verifier check the result independently and record amount, confirmation state and any remaining limitation.
- Reconcile the result with the recipient’s wallet and order record before closing the dispute.
If several transactions funded one obligation, list them separately and avoid counting the same verified payment twice. If the recipient disputes ownership of the supplied address, return to the original instruction instead of searching for a new address that makes the proof look successful. A receipt is useful when it explains the real transaction, not when it merely produces a positive screen.
The Monero transfer timing guide covers the separate confirmation and availability context. Before a simple swap, keep the order reference and outgoing record so a later support request can identify the payment. This guide describes Monero evidence mechanisms; it does not promise that KOT.CASH accepts every proof format or that a proof guarantees a deposit outcome.
FAQ
Is a Monero transaction key the same as my private spend key?
No, the transaction-specific key is different from the secret material that controls your wallet. Never substitute a recovery phrase or private spend key for a requested payment proof.
Does a Monero proof of payment establish a currently spendable balance?
No, transaction-key and transaction-proof checks have an explicit spendability limitation. They also do not establish that a service has allocated the payment to the intended customer order.
Can a Monero payment proof be checked with a different message?
Use the same message that formed part of the signed proof’s context. A mismatch can make verification fail without establishing that the underlying payment did not occur.