Skip to content
Financial Context Wiki

Ethereum mempool transaction replacement

A client-scoped guide to same-sender, same-nonce Ethereum transaction replacement, fee-cap bumps, cancellation races, blob transactions, private routes, receipts and finality.

Updated

For educational purposes only; not transaction or security advice. Replacement and cancellation are race-dependent, client- and route-specific operations; verify the chain, sender, nonce, signed payloads, fee fields, receipts and finality before assuming the original transaction was displaced.

Direct answer

Ethereum transaction replacement is a local transaction-pool policy under which a node may prefer a newly signed transaction over another candidate from the same sender with the same nonce. It is not a consensus-level global Replace-by-Fee switch. A node accepting the new hash does not erase the old signed transaction from other nodes, private relays or builders, and only canonical inclusion determines which candidate consumes the account nonce.

A wallet’s Speed Up action usually preserves the original destination, value and calldata while raising fee fields. A public-pool Cancel action usually creates a zero-value self-transfer with the same sender and nonce. That is a competing transaction, not an undo operation: if the original is included first, its transfer or contract call is not reversed. Product-specific private routes can define different cancellation APIs; for example, Flashbots Protect documents an authentication cancellation that is not placed onchain, which must not be generalized to public Ethereum transaction replacement.

How it works

  1. Pin the exact lineage: chain ID, client and version, head block and base fee, submission route, sender, canonical account nonce, original raw signed bytes, transaction hash and type. Query multiple relevant public or private views; a wallet label or one RPC response is not global state.
  2. Classify the original accurately as rejected, locally pending, queued behind a nonce gap, dropped or evicted, privately submitted, included successfully, included with status = 0, removed by a reorganization, or finalized. Stop treating replacement as available once the nonce is canonically consumed, although a reorganization can reopen the race.
  3. Define the new intent. A speed-up should reproduce every intended semantic field; a public cancellation attempt normally uses the same sender and nonce with to = sender, value = 0 and empty calldata. Compare chain ID, type, destination, value, calldata, access list, gas limit, blob hashes and authorization before signing.
  4. Read the target node’s actual replacement policy. Legacy and type-1 transactions use gasPrice; type-2 transactions expose maxFeePerGas and maxPriorityFeePerGas; type-3 transactions also expose maxFeePerBlobGas and require the sidecar. Geth’s current ordinary txpool.pricebump = 10 and blobpool.pricebump = 100 defaults are Geth configuration examples, not Ethereum-wide constants.
  5. Calculate eligibility and funding separately from the bump. For type 2, effective price is min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas). The candidate still needs valid encoding, sufficient intrinsic gas and a balance covering value plus maximum fee exposure; a higher cap does not repair invalid calldata or guarantee successful EVM execution.
  6. Submit deliberately and preserve every response. Publicly rebroadcasting can reveal intent and MEV; private relays have their own visibility, cancellation, builder coverage and liveness. Track old and new hashes across each route without assuming local acceptance deleted the competitor or without blindly sending a third value-bearing candidate.
  7. Reconcile the winner on the canonical chain. Verify receipt block and hash, transaction index, status, gas used, effective gas price, logs, sender nonce, balances and contract state at the required finality level. Record the losing hashes as replaced, dropped or still observed according to evidence, and restart the analysis after a reorganization.

Worked examples

  • Ordinary type-2 teaching bump. An old candidate has maxFeePerGas = 40 gwei and maxPriorityFeePerGas = 2 gwei. Under a teaching Geth configuration with a 10% bump, the arithmetic thresholds are 44 gwei and 2.2 gwei. A candidate at 44/2.1 gwei misses the tip threshold; 44/2.2 gwei reaches both teaching thresholds. At a 32 gwei base fee and 21,000 gas used, its effective price is 34.2 gwei, total fee is 718,200 gwei = 0.0007182 ETH, base burn is 0.000672 ETH, and tip is 0.0000462 ETH. Actual acceptance depends on implementation, version and integer-wei rounding.
  • Base-fee sensitivity. A replacement has caps 66/4.4 gwei. At a 60 gwei base fee, effective price is min(66, 60 + 4.4) = 64.4 gwei. At a 65 gwei base fee, effective price is 66 gwei and effective tip is only 1 gwei. At a 67 gwei base fee, 66 < 67, so the candidate is ineligible under that fee cap even if it satisfied a local bump test.
  • Cancellation race. The original nonce-20 transaction sends 5 ETH to a merchant. If it wins at 21,000 * 42 gwei = 0.000882 ETH, the merchant receives 5 ETH and the cancellation becomes nonce-too-low. If the zero-value self-transfer wins at 21,000 * 45 gwei = 0.000945 ETH, it consumes nonce 20 and prevents the original from later entering the same canonical history. Neither outcome can be known merely from a Cancel button click.
  • Blob-pool boundary. An old type-3 candidate has execution fee cap 100 gwei, tip cap 3 gwei and blob fee cap 20 gwei. Under a teaching Geth blob-pool configuration with a 100% bump, the arithmetic thresholds are 200/6/40 gwei. A candidate at 200/6/39 gwei misses the blob cap; 200/6/40 gwei reaches all three teaching thresholds but still needs a valid sidecar, nonce, balance and pool admission. These values are not rules for ordinary transactions or other clients.

Risks

  • Selecting the wrong chain ID or network.
  • Selecting the wrong sender or account nonce.
  • Using a stale head, base fee or canonical nonce.
  • Attempting replacement after the original is included or finalized.
  • Applying ordinary txpool rules to an ERC-4337 UserOperation.
  • Assuming another client, provider, version or configuration uses the same policy.
  • Missing a bump threshold because of integer-wei rounding.
  • Raising only one required EIP-1559 fee field.
  • Setting maxFeePerGas below the candidate block’s base fee.
  • Ignoring a blob fee cap, sidecar or special blob-pool rule.
  • Lacking balance for value plus maximum authorized fees.
  • Invalid signature, type, encoding, intrinsic gas or chain domain.
  • Accidentally changing destination, value, calldata, access list or blob hashes.
  • A public cancellation transaction losing the inclusion race.
  • The old transaction remaining in other nodes or builder inputs.
  • A private relay leaking, censoring, dropping or failing to cancel the submission.
  • Public rebroadcast exposing intent to frontrunning, sandwiching or other MEV.
  • A nonce gap blocking later transactions or prompting a duplicate transfer.
  • The replacement being included but reverting or running out of gas while consuming nonce and fees.
  • Reorganization, finality or receipt-lineage errors reviving or misclassifying candidates.

Common misconceptions

  • A higher-fee candidate globally deletes the old transaction.
  • Any two transactions with the same numeric nonce replace each other, even from different senders.
  • A wallet Cancel button reverses a transaction that was already included.
  • One node accepting the replacement proves that builders will include it.
  • A universal 10% bump rule covers every client, blob transaction, private relay and UserOperation.

Sources

Navigation

Search the wiki...