Monero Transaction Stuck or Unconfirmed: How to Fix It

What unconfirmed actually means

When you send Monero, your transaction first sits in the mempool, the waiting area for transactions that have been broadcast but not yet included in a block. Roughly every two minutes a new block is found, and your transaction gets picked up and recorded.

After that first inclusion, the network adds confirmations as more blocks stack on top. So a transaction that shows zero or a low number of confirmations is not stuck, it is simply young.

There is a second timer that catches people out. A newly received Monero output is locked for ten blocks before it can be spent, which works out at roughly twenty minutes. This is a consensus rule rather than a wallet preference, and no wallet can shorten it. A payment can therefore be fully confirmed and still unspendable at the same time, which is confusing but entirely normal.

Wallets display this inconsistently. Some show a locked balance as a separate figure, some show the full total and grey out the part you cannot touch, and some just put a small lock on the transaction row. If your total looks correct but the send button will not cooperate, check whether the balance is simply still maturing.

How Monero's mempool actually works

Every node on the network keeps its own transaction pool. When your wallet broadcasts, it hands the transaction to the node it is connected to, that node validates it and passes it to its peers, and within a short time most of the network holds a copy. Miners then select transactions out of their own pool when they assemble a block.

There is no global queue and no authoritative list of what is pending. Two nodes can briefly disagree about what is in the pool, which is why a transaction sometimes appears on one explorer a minute before another. That is ordinary propagation rather than a fault.

Monero also relays new transactions using Dandelion plus plus, which passes a transaction along a short private path before broadcasting it widely. This hides where a transaction originated, and it means there is a deliberate delay between you pressing send and the transaction being visible everywhere. If your transaction does not show up instantly, that is the privacy design working as intended.

Transactions do not sit in the pool forever. A node drops a transaction it has been holding for roughly three days if it never gets mined. Once that happens the transaction stops existing as far as the network is concerned, and the coins it would have spent were never spent at all.

Fee priority and what it actually buys

Monero wallets offer four priority levels, and the level you pick multiplies the fee you pay per byte of transaction data. A higher fee gives miners more reason to include your transaction ahead of others when the pool is crowded.

Under normal conditions Monero blocks are not full, so the lowest priority confirms in the next block or two exactly like the highest. Priority only starts to matter during a genuine surge, when more transactions are arriving than the current block size can absorb. Monero uses a dynamic block size that grows to meet sustained demand, which is why long fee backlogs are far rarer here than on chains with a hard block limit.

There is also a floor. Nodes will not relay a transaction whose fee falls below the network minimum, so any transaction your wallet successfully broadcast has already cleared that bar. If the wallet refused the send with a fee error, the transaction never entered the pool and there is nothing pending to wait for.

The practical takeaway is that on Monero the fee is rarely why your transaction has not confirmed. It is worth checking, but it is not usually the answer.

There is no replace-by-fee and no child-pays-for-parent

On Bitcoin, a stuck transaction can often be rescued by replacing it with a higher fee version, or by spending its output with a high fee child so the pair get mined together. Neither technique exists on Monero, and it is worth understanding why rather than hunting for a hidden setting.

Fee replacement does not work because a replacement would spend the same outputs and therefore publish the same key images. The network treats a repeated key image as a double spend and rejects it outright. That rule is what stops anyone from spending the same coin twice on a chain where nobody can see which coin was spent, and it applies to you just as much as to an attacker.

Child-pays-for-parent does not work either. You cannot spend an output until it has confirmed and matured, so while the parent is pending there is no child to attach a fee to. Monero miners also do not select transactions by package fee in the way that technique needs.

The consequence is calm rather than action. You cannot speed up a pending Monero transaction. You can only let it confirm, or wait for it to be dropped from the pool so the funds become spendable again and you can send a fresh transaction at a higher priority.

First, rule out a wallet sync problem

The most common false alarm is a wallet that is behind. If your wallet has not finished synchronizing with a node, it may not yet see that your transaction confirmed, or it may not show an incoming payment at all.

Check the wallet's block height against the current network height. If your wallet is still catching up, wait for it to reach the tip. If you use a remote node that is slow or out of date, switching to a healthier node or your own local node often makes a payment appear that was there the whole time.

Remote nodes go stale more often than people expect. An operator's node can fall behind, get overloaded, or quietly stop, and your wallet will keep reporting whatever height that node last gave it. The wallet then looks frozen at a block from an hour ago and every recent transaction looks pending. If your height differs from the real network height by more than a couple of blocks, the node is your problem and nothing else you check will help.

Switching nodes usually fixes this within seconds. Change the daemon address, reconnect, and let the wallet catch up. If you find yourself doing this regularly, running your own node removes the dependency entirely and is the most reliable cure for phantom stuck transactions there is.

Why a send can really sit in the mempool

The genuine causes are narrower than the panic suggests. The most common is a propagation failure, where your wallet lost its connection at the moment it broadcast and the transaction never reached more than one node, or none at all. A transaction the network never received cannot be mined, and it will not confirm no matter how long you stare at it.

A related case is broadcasting through a node that is itself isolated or misbehaving. Your wallet reports the send as successful because the node accepted it, but the node never relayed it onward. From your side these two situations look identical, and the fix for both is the same.

The last real cause is a genuine network surge combined with a low priority. This is uncommon on Monero because block size adjusts to demand, but it is not impossible, and it resolves itself once the pool drains.

Checking the transaction with a block explorer

You can look up a Monero transaction on a public explorer using its transaction ID. The explorer will tell you whether the transaction is sitting in the pool, which block it landed in, and how many confirmations it has. That single check separates a network problem from a wallet display problem faster than anything else.

If the explorer does not know your transaction ID at all, it never propagated. If it shows it in the pool, the network has it and you are waiting on a miner. If it shows it in a block, the transaction is done and any remaining confusion lives inside your wallet or the recipient's.

What you cannot do is look up an address. Monero addresses never appear on the chain, because every payment is delivered to a one-time stealth address that only the recipient can recognise. Pasting your own address into an explorer will show you nothing, and any site claiming to display a Monero address balance has either misunderstood the protocol or is lying to you.

Proving a payment is a separate tool. Your wallet can produce a transaction key and a transaction proof for a specific payment, and the recipient can verify that proof against the transaction ID and their own address. This is what an exchange or a merchant asks for when a deposit needs manual investigation, and it is worth saving alongside the transaction ID for anything that matters.

What to check on your side

Confirm your wallet is online and connected to a working node. Look at whether the transaction shows in your wallet's history as outgoing and pending. Note the transaction ID if one is shown.

If you control both ends, check the receiving wallet too, and make sure it is fully synced. Many reported stuck incoming payments are just a receiving wallet that has not finished scanning. Because Monero is private, you cannot simply paste an address into a public explorer to watch it, which is why checking inside the actual wallets matters.

Safe ways to nudge a stuck send

If a sent transaction has truly not propagated, the cleanest fix is to rebroadcast it. The CLI wallet and some other wallets let you resubmit a pending transaction so it reaches the network again. This does not change the transaction, it just re-announces it.

If you run your own node, the daemon can be told to relay a transaction that is already in its pool, which announces it to peers again. Where a wallet exposes no rebroadcast control at all, restarting it while connected to a healthy node is often enough, since wallets generally reattempt transactions they still consider pending.

Do not try to send the same funds again from a panic. If the original transaction is still valid and pending, the outputs it spends are locked, and attempting a duplicate can create confusion or fail outright. Give it time, rebroadcast if needed, and let it confirm rather than stacking new attempts on top.

Clearing a phantom pending state with a rescan

There is one situation that genuinely needs a manual fix. If a transaction was broadcast, never mined, and eventually dropped from the pool after three days, your wallet may still treat its inputs as spent, because it marked them locally the moment you hit send. The coins are yours and the chain agrees, but your balance shows less than you have.

The fix is a rescan. The command line wallet has rescan_spent, which re-checks which of your outputs are actually spent according to the chain, and rescan_bc, which rebuilds the entire wallet history from your restore height. Graphical wallets expose an equivalent rescan option in settings.

Neither operation touches your keys and neither can lose funds, so both are safe to run whenever a balance looks wrong. Start with the lighter one, because a full rescan takes as long as the original sync did. If the balance is still wrong afterwards, the full rescan is the next step and it will resolve almost anything short of a wrong restore height.

Deleting the wallet cache file and letting the wallet rebuild it achieves something similar. The cache holds only scanned history, not keys, so it can be regenerated. Do not delete the keys file, which is the one you cannot rebuild without your seed.

When it involves a swap or a third party

If you are waiting on a swap, remember there are two legs: the deposit you send and the payout you receive. A payout into Monero only begins after your incoming transaction has enough confirmations, so part of the wait is simply Monero doing its normal confirmation cycle.

With a non-custodial swap there is no account to log into and no support queue holding your coins, so the right move is to confirm both transactions on their respective networks and let the confirmations complete. If the deposit confirmed and the Monero side is still pending, it is usually the same young-transaction timing described above.

When to actually worry

Genuine loss is rare. A correctly broadcast Monero transaction does not vanish, and an unconfirmed one either confirms or, if it never propagated, can be rebroadcast or eventually drops out of the mempool so the funds return to spendable in your wallet.

Worry only if hours pass with a fully synced wallet, a confirmed broadcast, and still no movement, which points to a propagation failure worth rebroadcasting. Short of that, the honest answer is usually patience. Most stuck Monero transactions are just early in their confirmation cycle or hidden behind a wallet that needs to finish syncing.

The blunt summary is that Monero does not lose transactions. Either a transaction confirms, or it does not exist. There is no third state where money is in transit and unaccounted for. If it confirmed, the recipient has it. If it dropped from the pool, you still have it, possibly behind a rescan.

The mistakes that actually cost people money look nothing like this. Sending to the wrong address, sending an amount a service was not expecting, or omitting a required deposit reference are all real and all irreversible, and none of them present as a stuck transaction. A pending confirmation is very rarely the thing that hurts you, which is why the right response to one is to check your node, check the explorer, and then go and do something else for twenty minutes.