A stuck transaction, and what to do about it

The wallet says pending. It has said pending for twenty minutes, then an hour. Nothing has moved, the interface offers no explanation, and every instinct says to send it again — which is the one action most likely to make things worse.

A stuck transaction is one that has been broadcast to the network but not included in a block. It is not lost, it has not failed, and in most cases it has not cost you anything yet. What matters is understanding why it is waiting, because the fix depends entirely on the reason.

Why transactions wait

Four causes, and they need different responses.

• The fee is too low. The most common by far. You offered less than the network is currently charging, and your transaction sits in the queue until either the price falls to meet it or it is dropped.
• A nonce gap. Transactions from one address execute in strict order. If transaction 42 is stuck, 43 and 44 cannot execute even with generous fees — they are waiting behind it, not on their own merits.
• Network congestion. A spike in demand raises the going rate, and a fee that was adequate when you signed is inadequate ten minutes later.
• It was never broadcast. A connectivity failure at the moment of sending means the network never received it, and your wallet is showing you a local record of something that does not exist elsewhere.

A stuck transaction is queued, not failed. Nothing has been deducted, and until it confirms it can still be replaced — which is the whole basis of the fix.

Finding out which one you have

Three checks, in this order, before doing anything.

1. Look it up on a block explorer using the transaction hash. If the explorer has never heard of it, it was not broadcast — and that is a different problem with a simpler answer.
2. Check the pending queue for your address. More than one pending transaction means you are in the nonce situation, and the oldest one is the only one that matters.
3. Compare your fee against the current rate. Every explorer shows what is confirming now. If yours is well below it, you have your answer.

Doing this before acting matters, because the remedy for a low fee and the remedy for a nonce gap look similar and are applied to different transactions — the wrong one wastes a fee and changes nothing.

The three ways out

Waiting is genuinely underrated. Network fees vary substantially through the day and across the week, and a transaction with no deadline frequently confirms on its own within hours when the rate falls.

Speeding up resubmits the same transaction with the same nonce and a higher fee. Most wallets have a button for this, and the important detail is that it must use the same nonce — that is what replaces the pending transaction rather than adding a second one.

Cancelling is the same mechanism with different contents: a transaction to yourself, for zero value, using the stuck nonce and a higher fee. If it confirms first, the original is replaced and never executes. It is not guaranteed — the original can still win — but it usually works.

The critical rule underneath all three: never send the transaction again as a new one. A second transaction gets the next nonce, joins the queue behind the stuck one, and if both eventually confirm you have paid twice.

The nonce case, in more detail

This is the one that confuses people most, and the mental model is simple once stated.

Every transaction from an address carries a sequence number, and the network executes them strictly in order. Transaction 43 cannot be included before 42, regardless of its fee. So a single cheap transaction blocks everything behind it, and adding more transactions adds to the queue rather than clearing it.

Two consequences follow:

Fix the oldest one. Speeding up transaction 44 does nothing while 42 is stuck. Find the lowest pending nonce and act on that.

Everything behind it resolves automatically. Once the blocking transaction confirms or is replaced, the queue moves. You do not need to touch the others.

If a wallet does not show nonces, an explorer will. And if you are managing this manually, be careful: submitting a transaction with a nonce far ahead of the current one creates a gap that nothing can fill except a transaction with the missing number.

What to check before it happens again

Four habits that prevent most of it.

Do not accept the default fee during a spike. Wallets estimate, and estimates lag. Checking the current rate on an explorer takes ten seconds when something matters.

Match urgency to fee deliberately. A transfer that can wait until tomorrow does not need a priority fee, and treating everything as urgent is expensive over a year.

Keep enough of the native token for fees. A wallet holding tokens and nothing to pay fees with cannot move or rescue anything, which is a specific and frustrating kind of stuck.

Know where your wallet's speed-up and cancel controls are before you need them. Finding them during a spike, under pressure, is worse.

The things that are not fixes

Three actions people take that make it worse, and one non-action worth knowing.

Sending again from the same wallet. Covered above, and the most common mistake: it creates a queue rather than clearing one.

Sending from a different wallet to fix the first. The original is still pending and will still execute when the queue clears, so you have simply made two transfers.

Reaching out to "support". Nobody can cancel a broadcast transaction on your behalf, and anyone offering to is running a scam that specifically targets people in this situation. This is a well-known pattern — a public complaint about a stuck transaction attracts replies within minutes, all of them fraudulent.

And the non-action: if the explorer has never seen the transaction, there is nothing to cancel. The safe response is to wait for the wallet to clear its local record or to reset the account in wallet settings, and only then resend.

Before signing anything to fix this, it is worth being aware of what you are approving — the same reading discipline that applies to any transaction, and a scanner such as Riskira is useful for checking an address and its outstanding approvals while you are already in the settings.

More on the signing side in transaction safety, fee mechanics and permissions in web3 security, and the recovery-service pattern in crypto scams. The replacement rules are set out in EIP-1559.

The short version

A stuck transaction is queued rather than failed, and nothing has been deducted. Identify why first: a low fee, a nonce gap, congestion, or a broadcast that never happened — the last of which needs no fix at all.

Then wait, speed up, or cancel, always using the same nonce so the original is replaced rather than joined. Never simply send it again, always fix the oldest pending transaction rather than the one you care about, and ignore anyone who appears offering to help — that offer is the follow-on scam, not a solution.