Skip to content
Financial Context Wiki

How to fix 'replacement transaction underpriced'

This RPC error means a same-sender, same-nonce transaction did not satisfy the node's fee-bump policy. Learn how to inspect, speed up, or cancel it safely.

Updated

For educational purposes only; not financial or security advice. A replacement or cancellation can execute an unintended transaction and network fees are irreversible.

Direct answer

replacement transaction underpriced is an RPC or transaction-pool rejection, not an EVM contract revert. It usually means the node already knows a transaction from the same sender with the same nonce, but the newly submitted transaction does not raise the relevant fee fields enough to satisfy that node’s replacement policy.

First verify the chain, sender, nonce, and status of every known transaction hash. If the original is still pending and you intend to replace it, use the exact same nonce and raise the fee fields according to the wallet or node policy. Increasing only gasLimit, changing slippage, or repeatedly broadcasting the identical signed transaction does not satisfy a fee-bump rule.

How it works

  1. The nonce identifies the position. Transactions from an externally owned account use sequential nonces. A node that already has one transaction for a sender and nonce treats another transaction at that position as a replacement candidate. A later nonce may remain queued until earlier nonces are included or otherwise resolved.
  2. Replacement is a local pool policy. Ethereum consensus does not prescribe a universal percentage bump. Clients, RPC providers, and private relays may use different policies or may know different pending transactions. Geth’s legacy pool currently defaults to a 10% bump, but operators can configure it and other clients need not match it.
  3. EIP-1559 has two execution-fee caps. maxPriorityFeePerGas caps the validator tip and maxFeePerGas caps the total per-gas charge, including the block base fee. In Geth’s legacy pool, both the new fee cap and tip cap must exceed the old values and meet its configured percentage threshold. A wallet should calculate both rather than changing only one.
  4. Pool acceptance is not confirmation. A node can accept the replacement while other nodes still retain the original. Only one transaction from that sender and nonce can be included in the canonical account sequence. Whichever valid candidate is included first makes the other unusable on that chain, although interfaces may take time to update.
  5. Fee capacity and fee paid are different. The EIP-1559 effective gas price is limited by the fee cap; unused gas is not charged. Raising maxFeePerGas increases the maximum exposure, not necessarily the final price, but a high cap can be paid if the base fee and tip conditions require it.

Resolution workflow and example

Suppose the pending transaction has nonce 42, maxFeePerGas = 30 gwei, and maxPriorityFeePerGas = 2 gwei. A node requiring a 10% bump can reject a candidate at 31 gwei and 2.1 gwei. A candidate at 35 gwei and 2.5 gwei clears those illustrative thresholds. It can still wait if the current base fee leaves too little effective tip under the 35 gwei fee cap. The percentage is an example, not a network-wide guarantee.

Use this sequence:

  1. Check the correct network and sender. Query the original hash and any replacement hashes through the wallet plus an independent RPC or block explorer.
  2. Compare the confirmed transaction count with the pending view. If nonce 42 is already confirmed, do not create another transaction under the assumption that it remains pending.
  3. Decode the original to, value, and data. For a speed-up, preserve the intended operation and nonce. For a cancellation, wallets commonly send 0 ETH to the sender at the same nonce; this is only a competing replacement, not a protocol-level recall.
  4. Use the wallet’s speed-up or cancel function when possible. Otherwise obtain the node’s current bump policy and a current fee estimate, then raise both EIP-1559 caps with enough integer rounding margin. Ensure the account can cover value + gasLimit x maxFeePerGas.
  5. Sign only after rechecking the full transaction. Broadcast once, retain every hash, and monitor receipts for all candidates. A pending hash has no receipt; a receipt tied to the correct chain and block is the execution checkpoint.

Risks

  • A cancellation is not guaranteed. The original may be included before the cancellation reaches a block producer, and a private or poorly propagated transaction may be invisible to the RPC you inspect.
  • Using the wrong nonce can create a new payment or contract call instead of replacing the old one. Re-signing stale calldata can also execute an operation whose price, allowance, deadline, or protocol state has changed.
  • A replacement accepted by one endpoint may be rejected by another. Repeatedly switching RPCs can leave several candidates in different pools and make the wallet display confusing.
  • Raising gasLimit does not improve transaction priority. Raising fee caps blindly can create an unnecessarily high maximum cost; changing slippage or contract calldata changes execution semantics and does not fix the pool rule.
  • Blob transactions, account-abstraction user operations, L2s, and private relays can use different pools and replacement rules. Do not assume Geth’s ordinary EVM transaction policy applies to them.

Stop and investigate rather than signing again if the sender or nonce is unfamiliar, the original calldata cannot be decoded, the transaction may already be confirmed, the wallet proposes a different recipient or value, or an RPC asks for a seed phrase or private key. Legitimate troubleshooting never requires disclosing secret recovery material.

Common misconceptions

  • “The account lacks funds.” Insufficient funds is a separate validation error. This message specifically concerns a competing transaction and the pool’s replacement pricing.
  • “A 10% increase always works.” Ten percent is a common Geth default, not a consensus rule. Provider configuration, client software, transaction type, and integer rounding can require more.
  • “The higher-fee transaction definitely replaced the original everywhere.” Transaction pools are local. Acceptance by one RPC does not erase the original from every pool or guarantee which candidate is included first.
  • “Cancel reverses a confirmed transaction.” It does not. A cancellation competes only while the nonce is unresolved; confirmed state changes require a separate application-level remedy, if one exists.

Sources

Navigation

Search the wiki...