Mempool 101: How Pending Transactions Work

You hit send on a transaction, your wallet says "pending," and then… nothing, for a while. Where did it go? It's sitting in the mempool — the waiting room between "broadcast" and "included in a block." Understanding what happens in that room explains why your transaction is fast or stuck, why it can get front-run, and how to rescue one that's gone quiet.

The mempool is a waiting room, not a queue

When you submit a transaction, it does not go straight into a block. It gets broadcast to a node, which validates it (signature, nonce, enough balance for the fee) and drops it into its mempool (memory pool) — a pool of unconfirmed transactions. The node gossips it to its peers, who add it to their mempools, and so on across the network. Validators then pick transactions out of the mempool to build the next block.

Two things surprise people here:

• There is no single global mempool. Every node keeps its own. Your transaction propagates to most nodes quickly, but at any instant different nodes have slightly different views. "Is my tx in the mempool?" doesn't have one universal answer.
• It's not first-come-first-served. Validators build the most profitable block they can, so they order transactions mostly by fee, not arrival time. A later transaction with a higher tip jumps ahead of yours.

What decides whether your transaction moves: fee and nonce

Two levers govern a pending transaction's fate.

Fee (how much you're willing to pay). Post-EIP-1559, each transaction has a base fee (burned, set by the protocol per block) plus a priority fee / tip (goes to the validator). Validators sort by the tip, so a higher maxPriorityFeePerGas = faster inclusion. Set the tip too low and your transaction sits until the base fee drops or the network quiets down.

Nonce (the transaction's sequence number). Every account's transactions must be included in strict nonce order — nonce 5 can't be mined before nonce 4. This creates the single most common "stuck" scenario:

• You send nonce 4 with a low fee. It stalls.
• You send nonce 5, 6, 7 — they're all "queued," unable to execute because nonce 4 is blocking them.

That's the difference between the two mempool buckets:

So a single underpriced transaction can freeze everything behind it. The fix is replacement.

Replacing, speeding up, and canceling

You can't delete a pending transaction, but you can replace it by submitting a new transaction with the same nonce and a higher fee. Ethereum requires roughly a 10%+ bump on the fees for a node to accept the replacement. Two common uses:

• Speed up: rebroadcast the same transaction (same nonce, same call) with a higher tip. Whichever the validator picks, only one can land — they share a nonce.
• Cancel: send a 0-value transaction to yourself with the same nonce and a higher fee. If it lands first, it "uses up" that nonce and your original is discarded.

// ethers v6 — cancel a stuck tx by replacing its nonce with a 0-value self-send
const stuckNonce = 4;
await wallet.sendTransaction({
  to: await wallet.getAddress(),
  value: 0n,
  nonce: stuckNonce,
  maxPriorityFeePerGas: bumpedTip,   // must clear the ~10% replacement threshold
  maxFeePerGas: bumpedMax,
});

Watching the mempool over RPC

A few methods let you observe pending transactions:

Is my transaction still pending? If eth_getTransactionByHash returns the tx but blockNumber is null, it's in a mempool but not yet mined:

curl -s -X POST https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x…"],"id":1}'
# result.blockNumber == null  -> still pending

What's my next usable nonce? Compare the pending vs latest transaction count. If pending is higher than latest, you have transactions in flight:

# nonce to use for a NEW tx (accounts for in-flight ones)
eth_getTransactionCount(address, "pending")
# vs already-mined
eth_getTransactionCount(address, "latest")

Stream new pending transactions over WebSocket — useful for watching for a specific hash or building a monitor (see Subscribing with eth_subscribe):

const ws = new WebSocket("wss://rpc.swiftnodes.io/ws/eth?key=YOUR_API_KEY");
ws.onopen = () => ws.send(JSON.stringify({
  jsonrpc: "2.0", id: 1, method: "eth_subscribe",
  params: ["newPendingTransactions"],
}));

Mempool size / contents: Geth exposes txpool_status (pending + queued counts) and txpool_content, but these are heavy and many providers don't expose them publicly — treat them as node-operator/debug tools, not something to poll hard.

The mempool is public — and that has consequences

Because the public mempool is, well, public, anyone can watch it — including MEV searchers. They see your pending swap before it's mined and can front-run or sandwich it (place their own transactions around yours to profit from the price impact). This is why large or price-sensitive transactions often go through a private mempool or protected RPC (e.g. a Flashbots-style endpoint) that submits directly to block builders, bypassing the public pool entirely. If you've ever wondered why a DEX aggregator offers "MEV protection," this is what it's doing.

Pending transactions can also just… vanish

A transaction won't sit pending forever. Nodes drop it when:

• The fee is too low and the mempool fills up (it's evicted to make room).
• It's been pending too long (many nodes time out old transactions).
• Its nonce is too far ahead of the account's current nonce.
• A different transaction with the same nonce got mined (your replacement — or someone else's).

If a transaction disappears from the mempool without being mined, it was dropped — you'll need to resubmit it (usually with a higher fee). And note: even mined isn't final instantly — a transaction can be reorged back out of a block and land in a slightly different position, which matters if you're indexing (see Handling Chain Reorgs).

One note on L2s

On most L2 rollups, transactions go to a single sequencer that orders them, so there isn't a public, gossiped mempool the way there is on Ethereum L1. That generally means no public front-running mempool for third parties — though you're trusting the sequencer's ordering instead. The mechanics of why differ per chain; see What Is a Sequencer?.

The short version

The mempool is where your transaction waits to be chosen. Validators pick by fee, transactions execute in nonce order, a stuck low-nonce transaction blocks everything behind it, and you rescue one by replacing its nonce with a higher fee. It's public, so big transactions risk MEV, and it's per-node, so "pending" is always a little fuzzy.

Watching and managing pending transactions well needs an RPC endpoint that reliably reports pending state and streams newPendingTransactions. A flat-rate Ethereum RPC endpoint gives you that plus WebSocket subscriptions across dozens of chains under one key. Grab a free key and point your app at:

https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY