How do I fix "nonce too low" and "replacement transaction underpriced" errors?

Why "replacement transaction underpriced" happens

You're sending with a nonce that already has a pending transaction and your fees aren't high enough to replace it. Usually one of these:

• a stuck transaction is still in the mempool and your code reused its nonce (often after fixing "nonce too low" by fetching the count with "pending" in one place and "latest" in another);
• you tried to speed up or cancel a transaction but only raised one of the two fee fields, or raised them by less than the bump;
• you bumped the fees but the original had a higher maxFeePerGas than your new estimate.

Diagnose first

Compare the mined count with the pending count:

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const address = "0xYourAddress";

const latest = await provider.getTransactionCount(address, "latest");
const pending = await provider.getTransactionCount(address, "pending");

console.log({ latest, pending });
// latest === pending -> nothing pending, next nonce is `latest`
// pending > latest   -> nonces latest..pending-1 are waiting in the mempool

Keep in mind that "pending" reflects only the mempool of the node you're talking to. Load-balanced RPC endpoints can give different answers on consecutive calls.

Fix: replace a pending transaction properly

To replace a pending transaction, send a new one with the same nonce and fees at least ~10% higher on both fields. Take the higher of the bumped old fees and the current market fees, so the replacement is also good enough to be mined:

import { ethers, isError } from "ethers";

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const wallet = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);

const stuck = await provider.getTransaction("0xStuckTxHash");
if (!stuck || stuck.blockNumber !== null) throw new Error("not pending");
// Assumes an EIP-1559 (type 2) transaction; legacy ones use gasPrice instead.

const bump = (x: bigint) => (x * 115n) / 100n; // +15%, above the 10% minimum
const max = (a: bigint, b: bigint) => (a > b ? a : b);

const fee = await provider.getFeeData();
const maxPriorityFeePerGas = max(bump(stuck.maxPriorityFeePerGas!), fee.maxPriorityFeePerGas!);
const maxFeePerGas = max(bump(stuck.maxFeePerGas!), fee.maxFeePerGas!);

try {
  const tx = await wallet.sendTransaction({
    to: stuck.to,
    data: stuck.data,
    value: stuck.value,
    nonce: stuck.nonce,
    maxPriorityFeePerGas,
    maxFeePerGas: max(maxFeePerGas, maxPriorityFeePerGas),
  });
  console.log("replacement sent:", tx.hash);
} catch (e) {
  if (isError(e, "REPLACEMENT_UNDERPRICED")) console.log("bump the fees further");
  else if (isError(e, "NONCE_EXPIRED")) console.log("original was already mined");
  else throw e;
}

The NONCE_EXPIRED branch matters: a replacement is a race, and if the original gets mined first your replacement fails with "nonce too low". Check the receipt of the original before assuming anything.

Fix: stop producing duplicate nonces

For a single process sending many transactions, let ethers track nonces locally with NonceManager:

import { ethers, NonceManager } from "ethers";

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const signer = new NonceManager(new ethers.Wallet(process.env.PRIVATE_KEY!, provider));
const recipients = ["0xRecipientA", "0xRecipientB", "0xRecipientC"];

// These can run concurrently; each gets the next nonce.
const txs = await Promise.all(
  recipients.map((to) => signer.sendTransaction({ to, value: ethers.parseEther("0.01") }))
);

NonceManager fetches the count once and increments in memory. If a send fails before broadcast, call signer.reset() so it re-reads the count from the node, otherwise you'll leave a gap that blocks every later transaction.

NonceManager only helps inside one process. If several workers or servers send from the same address, you need one of:

• a single sender service that owns the key and serializes sends through a queue;
• a shared nonce allocator (for example an atomic counter in Redis or a database row lock) that hands out nonces and reconciles against the chain on startup;
• separate keys per worker, which avoids coordination entirely.

Checklist

1. Compare getTransactionCount(addr, "latest") with "pending" to see whether anything is stuck.
2. Pick new nonces from "pending", not "latest".
3. To replace, reuse the nonce and raise both maxFeePerGas and maxPriorityFeePerGas by more than 10%.
4. Handle NONCE_EXPIRED after a replacement: the original may have been mined.
5. Serialize sends per key with NonceManager, a queue or separate keys. Never let two processes guess the same nonce.
6. After resetting a local chain, reset the wallet's cached nonce too.

Is ERC-20 approve dangerous? Allowances, permit and infinite approvals

Approve is safe; unlimited, forgotten allowances and unread permit signatures are not. Approve exact amounts, use permit with short deadlines, read every typed-data signature, and revoke old approvals.

#security#tokens#wallets