Your wallet says pending. The explorer disagrees. The Send button is still there, looking unusually helpful.
Before pressing it again, establish what happened to the first transaction. This guide covers ordinary Ethereum account transactions. Other networks, smart-account operations and exchange withdrawal queues can use different rules; a similar-looking progress spinner does not make them the same system.
1. Find the transaction on the correct network
Start with the wallet's transaction details. Record the network, full transaction hash, sender address and nonce (the sender's transaction sequence number). A hash identifies a particular transaction; it does not prove that its intended transfer succeeded. Open the relevant explorer through a route you checked independently, not through an unsolicited recovery message.
Use the hash from the sending service if somebody else sent the funds. An exchange's internal withdrawal reference may not yet be an onchain transaction hash. You can inspect public transaction details without giving a support agent your recovery phrase or signing a new wallet request.
For the account/interface distinction, read crypto wallets explained. For this diagnosis, stick with the specific network and transaction rather than a balance screenshot.
2. Separate the states before choosing a response
The wallet, its connected node and an explorer may have different observations. An Ethereum node is a computer following the network's rules; its transaction pool is its own view of transactions waiting for inclusion, not one universal queue.
| What you see | What it tells you | What to check next |
|---|---|---|
| Pending, with no block assigned | The observer knows the transaction but has not shown inclusion | Sender nonce, any earlier unresolved transaction, and fee conditions |
| Not found or dropped | That observer cannot currently show the transaction | Network, full hash, sender history and another current observation; do not assume it can never appear |
| Replaced | A different transaction has taken that sender's nonce in the reported chain | Replacement hash, its recipient/action and receipt |
| Included, receipt status 0 | Top-level execution failed | Receipt and failure details; this is not simply a transaction still waiting |
| Included, receipt status 1 | Top-level execution succeeded | Actual asset/action, finality and the receiving service's credit rules |
The Ethereum JSON-RPC reference distinguishes a pending transaction's missing block fields from an included transaction's receipt. A null lookup or receipt is not a universal verdict: it describes what that node can return for the query.
Geth's transaction-pool documentation separately describes executable pending transactions and queued ones waiting for a future condition. Wallet labels do not always expose that distinction. You do not need to run a developer RPC command to start with the wallet's details and explorer.
Etherscan's dropped/replaced explanation notes that a dropped transaction can reappear if rebroadcast. Its replaced label concerns another transaction from the same sender with the same nonce. Treat those as explorer observations, not promises that money has automatically returned or that every node has forgotten the original.
3. Check whether an earlier nonce is holding up the line
For an ordinary outgoing Ethereum transaction, the nonce is the sender account's sequence number. Ethereum's transaction documentation lists it alongside destination, value and fee fields. Transactions from different sender accounts do not share this sequence.
Fictional example: account A has an unresolved transaction at nonce 41, then another at 42. Making the later transaction more attractive does not remove the need to resolve the earlier sequence position. MetaMask's replacement troubleshooting tells users to deal with the oldest pending nonce first.
Do not count only successful transfers to guess the current nonce. An included transaction whose execution fails still consumes its transaction nonce. Delegated accounts add another boundary: EIP-7702 can increment an authorizing account's nonce while processing an authorization, and delegated code introduces additional behavior. Smart-account requests may also have their own operation counters. Use the wallet's relevant account details rather than inventing a nonce from a list of payments.
4. Distinguish fee price from gas limit
For Ethereum's EIP-1559 fee model, the transaction has a maximum fee per unit of gas and a maximum priority fee. The block's base fee matters too. A fee cap below the applicable base fee cannot satisfy that block's fee requirement; inclusion still depends on other validity and selection conditions.
The gas limit is a ceiling on execution work, not a bid for priority. Raising it does not, by itself, make a transaction more competitive. The actual execution fee depends on gas used and the effective price, within the transaction's fee constraints.
Replacement policies can require a fee increase. Their thresholds depend on the relevant client or wallet; there is no universal percentage that guarantees every pending Ethereum transaction will be included. Do not copy a stale gas price from a screenshot. Network fees explained and the gas fee definition separate work, price and an exchange's own withdrawal charges.
5. A replacement is not another press of Send
For an ordinary transaction replacement, the sender and nonce stay the same while the replacement transaction gets its own hash. Only one transaction can occupy that sender's sequence position in the canonical chain. A fresh transaction using a different nonce is not the same replacement; it may execute after the first and repeat the intended payment.
MetaMask's current speed-up/cancel guide describes wallet controls for replacing a pending transaction. Availability and presentation vary by interface and transaction. Its newer transaction-status interface is an Extension feature, not a promise about every mobile or Portfolio screen.
Use the official instructions for the interface you actually have. A cancellation is itself a competing transaction, not an undo button. It can lose the race to the original. Once the original is included, a pending-transaction cancellation cannot reverse it.
This article does not ask you to disable wallet protections, manually forge a nonce, connect a rescue site or send a test payment. If the interface and current chain evidence disagree, gather the public details first and consult the wallet's official support route. Never share a seed phrase or private key to “unstick” a transaction.
Failed, finalized and credited are different questions
An included transaction with receipt status 0 has failed at top-level execution under EIP-658. Work already performed can still cost gas. A status 1 receipt is not proof that every intended business outcome occurred: check the relevant asset transfer or contract action rather than assuming the visible ETH value tells the whole story.
Inclusion is also not finality. Ethereum's Gasper explanation describes justified and finalized checkpoints; reversing finalized history would require a critical consensus failure. Avoid treating a fixed waiting time as a guarantee of that state.
Finally, a receiving service can require additional confirmations or other deposit conditions. Coinbase's pending-transaction help distinguishes blockchain confirmation from account credit and supported-network/asset issues. That is Coinbase's provider context, not one confirmation policy for every exchange. A confirmed transfer to an unsupported destination is not automatically recoverable.
Your next check should be specific
Keep the network, hash, sender, nonce, current state and observation time together. If a replacement exists, keep its hash and result too. These public details give the wallet or receiving service something to investigate; your secrets do not belong in that support request.
Check the oldest unresolved nonce before fee troubleshooting. Check the replacement's actual receipt before declaring it complete. If the chain shows inclusion but an exchange has not credited the deposit, investigate the receiving service's rules rather than submitting a second transfer to clear a spinner.
There is no universal timer after which a pending transaction becomes safe to repeat. Establish the first transaction's state before deciding whether another action is needed.
Sources
Primary documentation read 5 October 2026. This is a read-first diagnosis guide, not a live wallet test, recovery service or guarantee of inclusion. Explorer and wallet labels remain provider-specific observations.
- Ethereum.org: Transactions — ordinary transaction fields and sequence.
- Ethereum.org: JSON-RPC API — transaction lookups, missing block fields and receipts.
- Geth: txpool namespace — one node's pending/queued pool.
- Etherscan: Transaction dropped and replaced — explorer terminology and rebroadcast boundary; original article dated 5 December 2019, reopened for this guide.
- MetaMask: Why can't I replace a pending transaction? — earliest pending nonce.
- MetaMask: Speed up or cancel — interface scope and replacement/cancellation limits.
- EIP-1559: Fee market change — base fee, fee caps, priority and gas constraints.
- EIP-658: Receipt status — top-level success/failure.
- EIP-7702: Set code for EOAs — authorization nonce and delegated-account boundary.
- Ethereum.org: Gasper — finality versus inclusion.
- Coinbase: Pending transactions — receiving-service context.
See something wrong? Brokzi logs material changes. Prepare a correction note.
