Check Monero Transaction Status and Prove a Payment: A Step-by-Step Guide

To check Monero transaction status and payments, there are two different questions, and they need two different tools. "Did this transaction happen, and is it confirmed?" Paste its transaction ID (the 64-character hash) into a block explorer such as our explorer: you will see whether it is waiting in the mempool or confirmed in a block, how many confirmations it has, its time, fee, size, number of inputs and outputs and ring size. "Did it send this amount to this address?" No explorer can answer that from public data, because Monero hides amounts and recipients. The sender has to give you the transaction key (from get_tx_key in the CLI, or the transaction details in the GUI and other wallets), or a payment proof (get_tx_proof), and you check it in a wallet with check_tx_key or check_tx_proof, or the GUI's Prove/check page. If you are the receiver, your own synced wallet is the authority: it shows the payment, its amount and the subaddress it arrived at.

This guide covers both questions step by step: finding the transaction ID, reading what the explorer shows, what each status means, how to prove and verify a payment in the GUI, CLI and other wallets, the other proof types (spend proofs and reserve proofs), and what to do in the situations that bring most people here, from "the exchange says it sent it" to "the transaction is not found".

Check Monero transaction status or payment: which check do you need?

Step 1: find the transaction ID

Every Monero transaction has an ID, also called the transaction hash or txid: 64 hexadecimal characters.

• Monero GUI: open Transactions (history), click the transaction, and copy the Transaction ID.
• Monero CLI: show_transfers lists incoming and outgoing transfers with their IDs; show_transfer <txid> shows one in detail.
• Feather, Cake Wallet and other wallets: open the transaction in the history; the ID is in its details.
• An exchange or service that sent you XMR: its withdrawal history should show the transaction ID (sometimes labelled "TxID" or "hash"). If it shows only an internal reference, ask support for the on-chain transaction ID.

The ID is public information. Sharing it reveals nothing about amounts or addresses; anyone can look it up and see only what is public.

Step 2: look it up on the explorer

Go to our explorer and paste the transaction ID into the search box. (The same box accepts a block height or a block hash.) The transaction page, at /tx/<hash>, shows what our own node knows about it:

And, stated on the page itself: there are no amounts or addresses, because Monero hides them by design. An explorer that claims to show the amount or the recipient of a Monero transaction from public data alone is wrong, or is using a key someone gave it.

If the transaction is waiting, our mempool page lists it with its fee and size alongside the other waiting transactions.

Step 3: understand the status

"Waiting in the mempool"

The transaction has been broadcast and our node has accepted it as valid, but no miner has included it in a block yet. Monero blocks arrive roughly every two minutes and have a flexible size, so a normal transaction is usually mined within a block or two. If it is waiting much longer than that, compare its fee with the others on the mempool page; during unusual traffic, transactions with the lowest fee priority can wait longer.

"Confirmed in a block"

The transaction is in the blockchain. The confirmation count tells you how deep:

• 1 confirmation: just mined. A reorganisation of the most recent blocks, while rare, could still move it.
• 10 confirmations (about twenty minutes): the outputs become spendable by the receiver. Until then, the receiver's wallet shows the funds as locked or pending. This is the standard rule for every Monero transaction.
• 60 confirmations (about two hours): the unlock point for coinbase (miner reward) outputs.
• More: services receiving large amounts may wait for more confirmations as a matter of policy, especially during unusual network conditions. Our network page shows the current height and hashrate as our node measures them.

"Not found"

Common causes, in order of likelihood:

1. Typo or truncated ID. Copy it again; it must be 64 characters.
2. Not broadcast yet. The sender's wallet may not have sent it, or an exchange may still be processing the withdrawal internally.
3. Wrong network. A testnet or stagenet transaction will not be found on a mainnet explorer.
4. Dropped from the mempool. A transaction that was never mined, for example because it conflicted with another spend, can disappear. The sender's wallet should then show it as failed or let them resend.
5. Very recent. Give it a minute and search again.

A double-spend warning

If our node has seen two transactions trying to spend the same output, the transaction page says so. Only one of them can be mined. If you are the receiver, wait for confirmations before treating the payment as received, and treat a merchant-facing "zero-confirmation" acceptance with care.

Step 4 (receiver): check your own wallet

If the payment was to you, your wallet is the best check. It is the only thing that can read the amount and see which of your addresses received it.

1. Make sure the wallet is fully synced. Compare its block height with the height on our network page. A wallet that is behind does not show recent payments.
2. Look in the history for an incoming transaction with the same ID.
3. Check the subaddress it arrived at, if you use subaddresses per payer (see the subaddress guide).
4. Wait for 10 confirmations before it becomes spendable.

If the explorer shows the transaction confirmed but your synced wallet shows nothing, the payment did not go to your wallet (wrong address), or it went to a subaddress your wallet is not scanning for after a restore. In the second case, create subaddresses up to the index you gave out, or widen the lookahead, and rescan. If you think it went to the wrong address, ask the sender for a transaction key and check it against your address, as below.

Step 5 (sender and verifier): prove a payment with the transaction key

Every Monero transaction is built with a random transaction private key. The wallet that created the transaction stores it. With the transaction ID, that key and the recipient's address, anyone can verify how much that transaction sent to that address, and nothing else. This is the method in the official Monero guide (getmonero.org: How to prove a payment was made).

Getting the transaction key (sender)

• Monero GUI: in Transactions, open the transaction's details; the GUI shows the transaction key (the official guide describes clicking the "P" button to show it).
• Monero CLI: get_tx_key <txid> prints the key.
• Cake Wallet: open the transaction in the history; the details include the transaction key. Cake publishes a tutorial for this (Cake docs: Prove a Monero payment).
• Feather: open the transaction details; Feather shows the key and offers proof tools.

Send three things to the person checking: the transaction ID, the transaction key and the recipient address you paid.

Checking it (verifier)

• Monero GUI: go to Advanced → Prove/check. Under Check, enter the transaction ID, the recipient address and the transaction key, then click Check. The GUI reports whether the transaction paid that address, how much, and the confirmations.
• Monero CLI: on an up-to-date wallet, run check_tx_key <txid> <txkey> <address>. It prints the amount received by that address in that transaction and the number of confirmations.

The check needs a synced wallet (any wallet; it does not have to be the recipient's) because it reads the transaction from the chain.

What the transaction key reveals

Anyone with the ID, the key and the address can see the amount paid to that address in that one transaction. They learn nothing about other transactions, other outputs in the same transaction (unless they also have those recipients' addresses) or the sender's balance. Treat it as a disclosure of that one payment.

Proving a payment with a signed payment proof

A payment proof (also called a transaction proof or OutProofV2/InProofV2 in the code) does the same job as a transaction key, as a signature instead of a raw key, and it can include a message, which ties the proof to a context such as an order number.

Creating it

• Monero CLI: get_tx_proof <txid> <address> [<message>]. The wallet writes the signature (to the console or to a file, depending on version). The sender creates it with the recipient's address; the receiver can also create one for an incoming payment, using their own address, to prove they received it.
• Monero GUI: Advanced → Prove/check, under Prove: enter the transaction ID, the address and an optional message, then Generate. Copy the signature.

Checking it

• Monero CLI: check_tx_proof <txid> <address> <signature> [<message>].
• Monero GUI: Advanced → Prove/check, under Check: enter the transaction ID, the address, the message (exactly as used) and the signature.

The result shows the amount and confirmations, as with the transaction key.

Transaction key or payment proof?

That fourth row matters: a sender's transaction keys are not recoverable from the seed. They live in the wallet file (the CLI keeps them when its store-tx-info setting is on, which is the default). If you delete the wallet file and restore from seed, you can no longer produce a transaction key for old payments. If proving payments matters to you, back up the wallet file or record the keys for important transactions when you make them.

Spend proofs and reserve proofs

Two more proof types answer different questions.

Spend proof: "I made this transaction"

get_spend_proof <txid> [<message>] in the CLI creates a signature showing that you own the inputs a transaction spent, without saying which ring members were real and without naming a recipient. check_spend_proof <txid> <signature_file> [<message>] verifies it. It works from the spend key, so unlike a transaction key it can be produced after a restore from seed. Use it when the question is "did you send this?" rather than "did you pay this address?".

Reserve proof: "I hold at least this much"

get_reserve_proof all [<message>] or get_reserve_proof <amount> [<message>] creates a signature proving that the wallet holds at least the given amount (or everything) unspent at the time of the proof. check_reserve_proof <address> <signature_file> [<message>] verifies it. It reveals the outputs involved to the verifier, which means they can see if those outputs are spent later. Use it for audits, solvency checks or escrow arrangements instead of handing over a view key.

The view key guide compares these proofs with sharing a view key.

Situations that bring people here

"The exchange says it sent my withdrawal, but I don't see it"

1. Ask the exchange for the transaction ID (not an internal reference).
2. Look it up on our explorer. If it is not found, the withdrawal has not been broadcast; the exchange needs to resolve it.
3. If it is confirmed, make sure your wallet is fully synced.
4. Still nothing? Check that the address the exchange used is yours (compare the first and last characters with your wallet). Ask the exchange for the transaction key, and run check_tx_key against your address, or use the GUI's Prove/check page. If the check shows zero for your address, the withdrawal went somewhere else.

"A customer says they paid, but my shop shows nothing"

1. Ask for the transaction ID and look it up.
2. If confirmed, ask for the transaction key or a payment proof and check it against the order's subaddress.
3. If the check shows the right amount to the right subaddress, your shop's wallet is behind or not scanning that subaddress; fix the sync or the lookahead.
4. If the check shows nothing for your address, the customer paid a different address. Point them to the proof result.

"I sent to the wrong address"

Monero transactions cannot be reversed. If the address belongs to someone you can contact, the transaction key proves what you sent them, which helps when asking for it back. If the address is invalid, the wallet would normally have refused it. If it is a valid address belonging to nobody you know, the funds are under the control of whoever holds that wallet.

"My balance is locked"

Received outputs are spendable after 10 confirmations (about twenty minutes), and change from your own sends counts as received too. That is why, right after you send, part of your balance shows as locked: the change is waiting. Wait for the confirmations. Custom unlock times, which could lock outputs for longer, are rare and are being removed at the FCMP++ upgrade (getmonero.org).

"The transaction has been in the mempool for a long time"

Check its fee on the mempool page against the others. In normal conditions Monero's flexible block size means waits are short. If a transaction stays unconfirmed for a long time and then disappears from the mempool, the sender's wallet should treat it as failed; the funds remain the sender's, and they can rescan (rescan_spent in the CLI) and send again.

"Someone sent me a screenshot of a transaction"

A screenshot proves nothing. Ask for the transaction ID and a transaction key or payment proof, and check them yourself. Fake payment screenshots are a common scam in peer-to-peer trades.

Checking with a hardware wallet

If the transaction was sent from a wallet backed by a Trezor or Ledger, the wallet software still holds the transaction details, but producing the transaction key may involve the device: some setups ask you to confirm exporting it on the device. Follow the prompts in the Monero GUI or Feather. Receiving-side checks work as normal. The hardware wallet guide covers the device side.

Peer-to-peer trades and automatic checks

On peer-to-peer venues, the transaction key is how the receiving side confirms an XMR payment it cannot otherwise see. Bisq, for example, has an option in which the XMR sender enters the transaction ID and transaction key, and the counterparty's client verifies them through proof services (Bisq wiki: Trading Monero). Whether a venue does this automatically or asks you to check by hand, the rule is the same: confirm in your own wallet, with enough confirmations, before you release anything. Our exchange comparison covers how each type of venue handles disputes.

What the explorer cannot tell you, and why that is the point

It can be frustrating that an explorer does not show the amount. It is also the reason Monero is useful. Every transaction you can look up on our explorer looks the same from the outside: inputs hidden among 16 ring members, outputs to one-time keys, amounts hidden in commitments. The disclosure tools in this guide let the owner of a transaction decide who sees what, one transaction at a time. How the hiding works is explained in Monero ring signatures and FCMP++ and is Monero traceable?.

Reading a block page

Every confirmed transaction links to its block, at /block/<height> on our explorer, and the block page is useful context when you are checking a payment.

The transaction list shows the coinbase transaction (the miner's reward) first, then the transfers. If you are looking for a specific payment, its hash will be in this list once it is confirmed.

A merchant's checklist for accepting a payment

If you sell something for XMR, these steps keep checks quick and disputes rare.

1. Use a new subaddress per order so the payment identifies itself. The subaddress guide explains why and how.
2. Detect payments with your own wallet, ideally a view-only wallet on the system that handles orders (see the view key guide), connected to a node you trust.
3. Decide your confirmation policy in advance. For small amounts, some merchants mark an order "paid, confirming" when the transaction is seen and ship at a few confirmations; for larger amounts, waiting for 10 or more is common. Write the policy down so staff apply it consistently.
4. Check the amount, not just the arrival. A payment to the right subaddress for the wrong amount is a partial payment. Your wallet shows the amount; for disputes, the transaction key check shows it independently.
5. Do not accept screenshots, forwarded emails or "pending" messages from a customer as proof. Accept the transaction ID plus a transaction key or payment proof, and check them yourself.
6. Keep records: order number, subaddress, transaction ID, amount, confirmation time. They answer later questions without anyone having to reveal more.

Zero-confirmation payments: what the risk is

A transaction that has been broadcast but not yet mined is in the mempool. Accepting it as final, "zero-confirmation", is fast and sometimes fine for small, low-risk sales, but it carries a specific risk: until a transaction is in a block, a conflicting transaction spending the same funds could be mined instead. Our transaction page shows a warning when our node has seen such a double-spend attempt.

After one confirmation, replacing the transaction requires reorganising the chain, which is much harder; after several, harder still. The Qubic episode of August 2025, in which a campaign of selfish mining produced a reorganisation of several blocks, is a reminder that the depth you wait for is a choice with consequences (Lee and Kim, arXiv 2512.01437). For anything valuable, waiting for 10 confirmations, the point at which the funds become spendable anyway, is the simple rule.

What to share, and with whom

Each proof in this guide is a disclosure of something specific. Matching the proof to the question avoids revealing more than needed.

No legitimate check requires your seed or private spend key. A request for either is a scam.

Quick reference: CLI commands

Type help <command> in monero-wallet-cli for the exact syntax of your version.

Checking from a phone

You do not need a desktop wallet for the basic checks.

• Looking up a transaction: our explorer works in a phone browser. Paste the transaction ID into the search box; the transaction page shows status and confirmations the same way.
• Your own incoming payments: any phone wallet shows them once it has synced. If a payment is missing, check the wallet's sync status first; phone wallets that have been closed for a while need time to catch up.
• Showing a transaction key: Cake Wallet and other phone wallets show it in the transaction's details, so you can send it to the person who needs to check your payment. Copy it carefully; a single wrong character makes the check fail.
• Verifying someone else's transaction key: this is easiest in the Monero GUI or CLI. Not every phone wallet offers a "check" screen; if yours does not, use a desktop wallet, or ask the other party to check on their side and send you the result along with the proof so you can verify it later.

For anything that matters, such as a large trade or a dispute, do the verification in a wallet you trust on a device you control, rather than relying on a website or on the other party's word.

Our recommendation

For security warnings and scam patterns worth knowing before you accept a payment:

• CCrypto_Crime_News@Crypto_Crime_NewsOPEN
  @Crypto_Crime_News: fake payment screenshots, scams and exploits
• Ccryptoresearch@cryptoresearchOPEN
  @cryptoresearch: research and explainers

FAQ

How do I check a Monero transaction?

Paste the transaction ID into a Monero block explorer to see whether it is confirmed, its block, confirmations, fee and size. To check the amount sent to a specific address, use the transaction key or a payment proof in a wallet, with check_tx_key or check_tx_proof in the CLI or the GUI's Prove/check page.

Why doesn't the explorer show the amount or the address?

Monero hides them by design: amounts are in cryptographic commitments, recipients receive at one-time keys, and inputs are hidden in rings. Only someone with the right key, given by the sender or receiver, can see a specific payment's amount.

How many confirmations does a Monero transaction need?

Received outputs become spendable after 10 confirmations, about twenty minutes. Miner reward outputs need 60. Services may wait for more for large amounts.

Where do I find my Monero transaction key?

In the transaction's details in the Monero GUI, Feather or Cake Wallet, or with get_tx_key <txid> in the CLI. It exists only in the wallet that created the transaction; it cannot be recovered from the seed.

Is it safe to share a transaction key?

It reveals the amount that one transaction sent to the address it is checked against, and nothing else about your wallet. Share it with the person who needs to verify that payment.

Can I prove I received a Monero payment?

Yes. As the receiver, create a payment proof with get_tx_proof <txid> <your-address> [message] (or the GUI's Prove/check page), and the other party verifies it with check_tx_proof.