Ether scan

Ether scan shows when confirmation closes the transaction cancellation window

Ether scan transaction tracking helps distinguish a pending Ethereum transfer from one already included in a block. While the transfer remains pending, its sender can attempt a replacement using the same nonce and higher fees. Once the original enters the canonical chain, the sender cannot cancel it through replacement. Submitting a cancellation does not establish success: the replacement must win inclusion before the original, and its transaction record must show that outcome.

Last updated:

The short version: A cancellation competes with the original pending transaction, and block inclusion determines which instruction consumes the sender’s nonce.

The sender address and nonce connect an original transaction with its replacement, while each transaction has its own hash. The nonce identifies a position in the sending account’s transaction sequence. Etherscan exposes transaction details; the wallet signs and submits the competing instruction. Matching the sender, network, and nonce establishes whether another submission actually competes with it. These rules concern ordinary Ethereum account transactions; contract wallet requests can use additional authorization mechanisms.

Cancellation changes the instruction competing for inclusion

A speed-up retains the intended operation and raises its fee offer. Cancellation substitutes an instruction intended to prevent that operation. Both use the original sender and nonce. A sender can attempt transaction cancellation only while the original transaction remains pending. A wallet’s cancellation control submits a competing transaction; pressing it does not withdraw the original from every network node.

A conventional cancellation sends zero ETH back to the sending address without the original contract call. Manual construction requires care: the destination, value, and input data determine what the replacement executes. An account with executable code can require different handling, so a self-transfer is not a universal cancellation recipe. Use cancellation behavior appropriate to the account rather than assuming every wallet request follows the same transaction format.

Changing the nonce creates a separate transaction. It does not replace the unwanted instruction and may leave both eligible for execution.

Replacement fees determine acceptance, not a promised result

A replacement needs acceptable fee settings before a node will admit it in place of the transaction it already holds. For transactions with separate maximum and priority fees, raising only one field may not satisfy the node’s replacement policy. An underpriced-replacement error describes that admission failure. It does not mean the original transaction has stopped or that a cancellation has executed.

Replacement thresholds belong to client policy and configuration. A fixed percentage cannot promise acceptance across every submission path. Network demand also affects the fee needed for inclusion. Even an accepted replacement can lose the race if the original reaches a block first.

The maximum fee caps the permitted price per gas unit. The priority fee caps the validator tip, while the block’s base fee sets the required base charge. The gas limit controls the execution allowance. Increasing that allowance alone does not increase the price offered for each unit of gas.

The execution gas charge equals gas used multiplied by the effective price per gas unit. A zero-value cancellation still requires gas. Its cost follows the transaction it executes and the applicable fee inputs, rather than a fixed cancellation tariff. An included transaction also incurs a charge when execution fails.

Competing ordinary transactions with the same sender and nonce cannot both execute in the same canonical history. The losing, unincluded submission has no onchain execution charge. A later transaction with a different nonce creates a separate opportunity for execution and another fee. That distinction matters when a wallet offers to resend after an uncertain result.

Dropped status leaves a different uncertainty

A dropped transaction can return if someone rebroadcasts it while its nonce remains available. Removal from a node’s transaction pool does not permanently invalidate a signed transaction. A missing hash or dropped label therefore provides weaker cancellation evidence than an included replacement. Lower unresolved nonces also hold up later transactions from the same account. A replacement for a later nonce cannot bypass that ordering dependency.

Dropped status leaves a different uncertainty: A dropped transaction can return if someone rebroadcasts it while its nonce remains available. Removal from a node’s transaction pool does not permanently invalidate a signed transaction.; A missing hash or dropped label therefore provides weaker cancellation evidence than an included replacement.; Lower unresolved nonces also hold up later transactions from the same account. A replacement for a later nonce cannot bypass that ordering dependency.

Open full-size image

A rejected cancellation needs a fresh status check

Consider a pending transfer whose cancellation attempt returns an underpriced-replacement error. The rejection leaves the original capable of executing. Before attempting another replacement, establish whether the same nonce remains available and whether an earlier transaction blocks it.

  • If the original now has a receipt in the canonical chain, stop trying to replace its nonce.
  • If the original remains pending, confirm the sending account, network, and nonce match the cancellation request.
  • If an earlier nonce remains unresolved, address that transaction before expecting the later replacement to execute.
  • If the node rejected the fee offer, revise the relevant fee fields and check the account can cover the replacement’s maximum cost.
  • After submission, inspect the replacement hash and its execution details. A submitted or pending label does not establish cancellation.

If the replacement confirms with the intended cancellation behavior, its record establishes which instruction used the nonce. Keep both hashes and the included transaction’s receipt. If the original confirms first, the replacement attempt has failed to prevent it, and further fee increases cannot reverse that inclusion.

An unresolved result is a reason to pause additional payments. Sending the intended transfer again with a fresh nonce can duplicate the payment if the original later executes. The revised fee offer changes the replacement’s acceptance prospects and possible cost; it cannot purchase a guaranteed outcome.

Block inclusion ends replacement before finality

Block inclusion closes the ordinary replacement window while the transaction remains in the canonical chain. Finality provides stronger assurance that the containing block will remain there. The interval between inclusion and finality is not an extra cancellation period. A chain reorganization can change inclusion history, but the sender cannot request one as a wallet operation.

A confirmed failure also requires a different response from a pending transaction. The failed execution has consumed its transaction nonce and incurred gas costs. Correcting the operation requires a new transaction after resolving the cause of failure, rather than another attempt to cancel the included one.

For a successful transfer, recovery requires a separate action, such as the recipient returning the funds. Any contract-specific recovery function depends on that contract’s actual permissions and behavior. A return transfer creates a new record; it does not erase the original. Before inclusion, replacement competes to prevent execution. After inclusion, a refund or corrective transaction acts on the resulting balances or contract state.

Ether scan FAQs

Does clearing wallet activity cancel a pending Ethereum transfer?

Clearing local wallet activity does not revoke a transaction already broadcast to the network. It changes the wallet’s stored history or tracking information. A transaction can remain eligible for inclusion even after the wallet stops displaying it. Preserve the hash before troubleshooting local records, and distinguish a display reset from an included cancellation transaction.

Can the recipient cancel an incoming transaction?

The recipient cannot replace an incoming transaction merely by knowing its hash or nonce. Replacement requires authorization from the sending account. A transaction the recipient signs from a different account uses that account’s own nonce sequence and does not compete with the incoming transfer.

Who can replace a withdrawal sent by a custodial service?

The party controlling the sending account must authorize an onchain replacement. If a custodial service signs the withdrawal, the receiving wallet cannot replace that transaction. A service’s internal withdrawal-cancellation option is a separate process, and its availability does not establish whether a broadcast Ethereum transaction remains replaceable.

Is a cancellation still possible when the sending account cannot cover gas?

An ordinary replacement must satisfy the sending account’s balance requirements before it can execute. Setting its transfer value to zero removes the transferred amount, but gas still requires funding. Insufficient funds can prevent a cancellation from being accepted; the rejection does not disable the original signed transaction.