Ethereum Pending Transactions Explained: Nonces, Replacements, and Cancellation

After you sign an Ethereum transaction, your wallet can send it to an execution client or transaction service. Nodes that accept it may relay it to peers, and a block proposer may later include it in a block. Until inclusion, the transaction has not changed the canonical chain state. The word “pending” on a wallet or explorer usually means that the service knows about the transaction but has not observed it in a block; it does not identify one universal network queue. Ethereum.org's transaction guide describes the path from signing and broadcasting through block inclusion.

A transaction can wait for several different reasons. Its fee caps might not meet the conditions for a block, an earlier transaction from the same account might still be unresolved, a node might not have received it, or the wallet may be showing stale or provider-specific information. These causes require different checks. Raising a fee does not fix an incorrect network selection, and submitting another payment without checking the first can create a second payment.

“Pending” is also different from “confirmed,” “finalized,” or “failed.” A transaction hash can be visible before any receipt exists; a receipt becomes available after a transaction is included. Ethereum blocks then progress through consensus states. Wallets and explorers may use these labels differently, so inspect the transaction hash, block, receipt, and current chain state instead of relying on one short status label.

An ordinary Ethereum externally owned account (EOA) has a nonce that orders its transactions. The nonce is a counter, not a fee, timestamp, or unique transaction hash. For each account, the chain accepts a transaction only when it uses the next nonce expected by that account's state. The same account cannot execute two transactions with the same nonce on the canonical chain. Ethereum.org's account documentation describes the nonce as the account's transaction counter and replay-protection mechanism.

Suppose the next unused nonce for an account is 41. Its next valid transaction uses nonce 41; after that transaction is included and applied, the next one uses nonce 42. The nonce is associated with the sending account, not with a destination address. Two different accounts can each have a transaction numbered 41 at the same time because each account has its own sequence.

A transaction can be signed with a nonce that is ahead of the account's current on-chain nonce, but it cannot jump the sequence when executed. The missing earlier nonce must be consumed first. A transaction with a nonce already consumed by the account is stale and cannot execute as a new transaction. This ordering lets the network process each account's transactions in sequence, even when transactions are broadcast at different times or arrive through different nodes.

The nonce rule applies to ordinary EOA transactions on the Ethereum execution layer. It is not a universal description of every wallet abstraction, rollup sequencer, or chain. Smart-account systems can add their own operation and nonce rules, discussed later in this guide.

Ethereum has no single synchronized waiting room that every wallet, node, block explorer, and proposer sees in exactly the same way. Each execution client keeps a local transaction pool of transactions it has received and considers eligible under its own limits and policies. A transaction can appear in one node's pool but be absent from another's. Geth's txpool RPC documentation exposes that client's local pending and queued groups and notes that multiple transactions may be associated with the same sender and nonce.

In Geth's terminology, pending generally refers to transactions that can be processed in nonce order from the account's current state; queued can include future-nonce transactions waiting for a gap to close. Those names describe a client interface, not consensus-level states that all Ethereum software must display. A wallet may call its entire unconfirmed list “pending,” while an explorer may show only transactions its own data providers have observed.

For example, if a node knows a transaction with nonce 41 and another with nonce 43, it cannot execute 43 before 42. That node may keep 43 queued until 42 arrives or the account advances another way. A different node that never received 43 will not show it at all. This is why two explorers can disagree about whether a transaction is pending or missing without either screen proving what every validator has seen.

Some clients also permit more than one unconfirmed transaction candidate for the same sender and nonce. They are alternatives competing for the same sequence slot, not two transactions that can both be applied in order. Pool capacity, transaction lifetime, and replacement rules are implementation policies and can change between software versions. Geth's configurable transaction-pool options, for instance, include a client-specific price-bump setting; that setting must not be treated as a universal Ethereum fee rule. See the Geth command-line reference for the scope of those options.

Imagine that an account's next on-chain nonce is 41. You broadcast transaction A with nonce 41, then transaction B with nonce 42. If A remains unresolved, B cannot be applied first. B may sit in a local queue, appear only as pending in the wallet, or be absent from an explorer that has not received it. The important relationship is the nonce order, not the order in which the wallet created or displayed the two transactions.

If A is eventually included, the account advances to nonce 42 and B may then become eligible, subject to its own validity, fee conditions, and the pool's policies. If A is replaced by another valid transaction with nonce 41, the replacement occupies that same sequence position if it is the one included. If nonce 41 was consumed by a different transaction from the account, an old candidate at nonce 41 is stale; it cannot execute afterward.

This explains why sending a new transaction with a higher nonce is not a general way to clear a stuck transaction. It adds another transaction behind the gap. Nor does cancelling B resolve A if B is already the later transaction. Start with the earliest unresolved nonce from the account and verify its status before changing anything.

A gap can be temporary or persistent. The earlier transaction may not have reached the node you are checking, may have fee settings that are unattractive or insufficient for current conditions, or may have been removed from one node's pool. A wallet can also show a queued transaction that was created on a different device. The screen alone does not tell you which of these happened; compare the account's confirmed nonce, transaction hashes, and more than one reliable view.

Nonce order and fee eligibility are separate constraints. A transaction with the correct next nonce can still wait if its fee parameters do not satisfy the conditions for a block. A transaction with a higher nonce cannot jump ahead merely by offering a larger tip. Raising the fee of nonce 42 does not make nonce 41 disappear.

For a standard EIP-1559 transaction, the maximum fee must be able to cover the base fee of the block that includes it, and the priority fee can influence a block proposer's choice. Both the base fee and available block space can change while a transaction waits. The maximum fee is a cap, and a larger cap does not guarantee a particular confirmation time. The Ethereum gas-fee guide explains those fields and how the effective fee is determined.

A node or wallet may apply additional relay or replacement rules. Those policies determine what that particular service is willing to accept or forward; they are not all consensus rules. For example, Geth exposes a configurable price-bump threshold for replacing a pending transaction in its own pool. Another client, provider, wallet, or software version may behave differently. Do not rely on a remembered percentage or a fixed waiting period as a network-wide guarantee.

If your transaction is waiting because a lower nonce is unresolved, first identify the transaction that owns that nonce. If it is waiting because its fee cap cannot cover current base-fee conditions, understand the fee fields before changing them. The Ethereum fee guide is the right companion for fee arithmetic; this article focuses on the separate sequencing problem.

A wallet's “speed up” feature commonly constructs a new transaction from the same account using the same nonce and adjusted fee parameters. The two candidates conflict because the account can execute only one transaction for that nonce. If the replacement is accepted into relevant transaction pools and included, it can take the nonce slot; the original then cannot also execute on the canonical chain. MetaMask's pending-transaction guidance describes its own speed-up flow as resubmitting with the same nonce and a higher fee.

The replacement may keep the original destination and action while changing the fee fields, but inspect the signing screen rather than assuming. A wallet implementation could expose other fields or label the action differently. Confirm the sending account, nonce, destination, value, and contract data before signing a replacement. If the replacement changes what the transaction does, it is not merely a harmless fee adjustment.

A replacement is not guaranteed to be accepted everywhere or included quickly. The original may already have been included; a node may reject the replacement under its policy; the replacement may still be unattractive to a proposer; or the service may not relay it to the nodes you are monitoring. If the original is already confirmed, sending another transaction with its consumed nonce cannot reverse it and will usually be rejected as stale.

The term “replacement” here means a competing transaction from the same account and nonce. Do not import Bitcoin's RBF or CPFP procedures into Ethereum. Bitcoin uses a different transaction model and its fee-bumping mechanisms are not instructions for Ethereum accounts.

Once a signed Ethereum transaction has been broadcast, there is no protocol-level undo command that withdraws it from every node. Some wallets offer a cancel action while a transaction is still unconfirmed. That action typically attempts to publish a different transaction from the same account with the same nonce; one common wallet pattern is a zero-value transaction to the sender's own address. If the cancellation candidate is accepted and included before the original, it consumes the nonce, making the original candidate invalid for later execution. The exact construction and availability depend on the wallet.

The original and cancellation candidate can race. If the original is included first, a cancellation sent afterward cannot undo its effects. If neither candidate is accepted or included, the nonce may remain unresolved. A wallet's button click or success toast does not prove that the cancellation won. Check the resulting transaction hash and canonical chain status. MetaMask's instructions explicitly limit its cancel attempt to a transaction that is still pending and explain that a confirmed transaction cannot be cancelled.

Before signing a cancel transaction, check that it uses the same account and nonce as the transaction you intend to displace, and inspect every field shown by the wallet. It may require another network fee if included. A cancellation candidate can itself wait or fail to replace the original under the relevant transaction-pool policies. The word “cancelled” in a wallet is not proof of a protocol reversal; it should describe the outcome only after you verify which transaction consumed the nonce.

If the transaction has already executed a token approval, contract call, or transfer, cancelling a later transaction cannot reverse that completed state change. Some contract actions have separate follow-up methods, but their availability and consequences depend on the contract. Do not sign an unfamiliar transaction just because an interface calls it a cancellation.

An included transaction has a block and receipt. If it succeeds, its intended state changes may have been applied. If EVM execution reverts, the state changes from that execution are rolled back, but the transaction still consumed its account nonce and can still incur gas. Use the transaction receipt and execution status rather than inferring success from a wallet notification. See the Ethereum transaction guide and the gas guide for the distinction between inclusion and execution outcome.

A “dropped” or “not found” label is often a report about one wallet, explorer, RPC provider, or local pool. It does not by itself prove that the transaction was cancelled by the protocol or that its nonce is free. Another node may still know it; a wallet may rebroadcast the signed transaction; or a later block may reveal that the account nonce has already advanced. Conversely, an old transaction may be absent from the views you checked while the account's confirmed nonce remains unchanged.

If a transaction hash is not found, check that you selected the same chain and account that produced it. Compare the account's latest on-chain nonce with the transaction's nonce and examine recent transactions from that sender. A nonce too low response is a clue that the nonce may already have been consumed from the endpoint's perspective, not a reason to keep repeating the same request. Verify which transaction used it and whether the block remains canonical.

An included transaction can also be affected by a short-lived chain reorganization before the chain settles. Wallets and explorers may update labels as their view changes. For an important transfer, wait for the confirmation policy of the receiving service and, where relevant, stronger consensus finality; “seen in one block” and “irreversible under every circumstance” are not identical claims.

Start by confirming the chain, sending account, and transaction hash. Look up that hash on a reliable explorer for the correct network. Check whether it has a receipt, what nonce it uses, whether execution succeeded, and whether the account has made a later transaction. Do not expose or enter your seed phrase to check a transaction; a public address and transaction hash are sufficient for public chain lookups.

If the hash is not visible, compare the account's latest confirmed nonce with the nonce shown by your wallet. A developer or node operator can query eth_getTransactionCount using the latest and pending block tags. Ethereum.org's JSON-RPC reference defines those tags: latest refers to the latest block state, while pending refers to pending state. The pending result is still specific to the RPC endpoint's view; querying two providers can produce different values. Most users can get the same first clues from their wallet's account activity and a reputable explorer without running commands.

Then work from the lowest nonce that has not been consumed. If the original transaction is still visible and the wallet supports replacement, review the replacement's exact fields and fee settings before signing. If it is not visible, ask the wallet or RPC provider how it handles resubmission and replacement rather than assuming the transaction vanished from the network. If the nonce is already consumed, identify the included transaction before attempting anything else. Avoid repeatedly submitting new transactions at later nonces; that can lengthen the queue without resolving the first gap.

These steps cover standard Ethereum externally owned account transactions. Account-abstraction systems can submit UserOperations through bundlers, and their smart accounts may use nonce keys and sequences beyond one simple counter. EIP-4337 defines a nonce structure for those operations, so a wallet using account abstraction may not behave exactly like the EOA examples in this article. For destination networks, addresses, and transfer status, continue with the crypto transfer checklist.