What the mempool actually is
When you sign a transaction in a wallet, it is broadcast to a node, which checks the signature, the nonce or inputs, and the fee. If it passes, the node stores it in memory and relays it to its peers. That in-memory store is the mempool.
The Bitcoin whitepaper describes the same flow: new transactions are broadcast to all nodes, each node collects them into a block, and a transaction becomes part of the chain once a block containing it is accepted.[8]
Because each node applies its own limits and receives transactions in a different order, mempools differ from node to node. A block explorer that shows "the mempool" is really showing the view of its own nodes.
The mempool is not part of consensus. Two honest nodes can disagree about which transactions are pending and still agree completely on every confirmed block, because only blocks are checked by the protocol. That is why a wallet can show a transaction as sent while a block explorer run by a different company shows nothing: the transaction reached some nodes and not others yet.
A transaction leaves the mempool in one of four ways: it is included in a block, it is replaced by a higher-fee version with the same inputs or nonce, it is evicted when the pool is full, or it expires. Each client documents its own rules for the last three, and those rules are the numbers in the next section.
How big a mempool can get
Mempools are bounded by software defaults, not by the protocol. Bitcoin Core sets DEFAULT_MAX_MEMPOOL_SIZE_MB to 300 and DEFAULT_MEMPOOL_EXPIRY_HOURS to 336, so a node holds up to 300 MB of pending transactions and evicts any that sit unconfirmed for 14 days.[1]
When the 300 MB limit is reached, the node has to drop pending transactions to stay under the cap. A low-fee transaction can therefore disappear from many mempools during a busy week, even though it was valid.
Geth, a widely used Ethereum execution client, calls its mempool the transaction pool. Its defaults are 5,120 global executable slots (txpool.globalslots), 1,024 queued slots for non-executable transactions (txpool.globalqueue), 16 executable slots guaranteed per account, and a 3-hour lifetime for queued non-executable transactions.[2]
The limits are local settings that an operator can change. A node started with a larger maxmempool value keeps more pending transactions around, while Bitcoin Core's default for blocks-only mode is just 5 MB. So when a low-fee transaction vanishes from one explorer, it may still sit in a larger pool elsewhere.[1]
Geth also separates pending transactions into two groups. Executable transactions have the next expected nonce and can be mined right away. Queued transactions have a nonce gap and cannot run until earlier ones confirm. The 3-hour txpool.lifetime applies to that queued group, which is why a transaction stuck behind a missing nonce eventually disappears from a Geth node.[2]
| Setting | Bitcoin Core | Geth (Ethereum) |
|---|---|---|
| Size cap | 300 MB | 5,120 executable + 1,024 queued slots |
| Expiry | 336 hours (14 days) | 3 hours for queued transactions |
| Replacement rule | Higher absolute fee and fee rate (BIP 125) | At least 10% higher price (txpool.pricebump) |
How transactions get picked
Block producers generally pick the transactions that pay them the most per unit of block space. On Bitcoin that is the fee rate in satoshis per virtual byte; on Ethereum it is the priority fee (tip) per unit of gas.
Under EIP-1559, an Ethereum transaction sets a maxFeePerGas and a maxPriorityFeePerGas. The base fee part is burned, and only the priority fee goes to the block proposer, so the tip is what moves a transaction up the queue.[5]
An Ethereum transaction also carries a nonce, a counter per account. If you send nonce 7 before nonce 6 is confirmed, nonce 7 waits in the queued section of the pool until the gap is filled.[4]
Priority is not strictly first come, first served. A block producer sorts by what it earns, so a transaction broadcast later with a higher tip can be included before one that has waited an hour. Time in the pool matters only as a tiebreaker in some implementations, and it stops mattering at all once the pool is full and low-fee entries are evicted.
Ethereum's base fee adjusts every block by at most one eighth, or 12.5%, depending on how full the previous block was: EIP-1559 sets BASE_FEE_MAX_CHANGE_DENOMINATOR to 8. A transaction whose maxFeePerGas falls below the current base fee cannot be included at all, even with a generous tip, and it waits until the base fee drops back under its cap.[5]
See also: Gas fee in the glossary · Gwei in the glossary
Worked example: unsticking an Ethereum transaction
Say you sent a swap with nonce 42 and a max priority fee of 1 gwei, and the network base fee jumped. The transaction sits pending. To replace it, you send a new transaction with the same nonce 42.
With Geth's default txpool.pricebump of 10, the replacement must pay at least 10% more. A 1 gwei tip therefore needs to become at least 1.1 gwei, and the max fee must rise by the same 10%. Anything lower is rejected as "replacement transaction underpriced".[2]
To cancel instead, a common method is to send 0 ETH to your own address with nonce 42 and the higher fee. Only one transaction per nonce can be included, so whichever version lands first wins and the other can no longer be mined.
Bitcoin has a similar tool. Under BIP 125, a transaction that signals replaceability can be replaced by one paying a higher absolute fee and a fee high enough to cover its own relay bandwidth.[3]
Many wallets expose this as Speed up and Cancel buttons, which build a new transaction with the old nonce and a higher fee. Knowing that helps when the buttons are unavailable, for example with a hardware wallet or a script, because you can build the replacement yourself with any wallet that lets you set a custom nonce.
Why a public mempool is a security issue
Anyone running a node can read pending transactions before they are confirmed. Searchers scan the Ethereum mempool for large DEX trades and place their own orders before and after them, a pattern ethereum.org documents as sandwich trading.[6]
Private transaction services exist for this reason. Flashbots Protect sends transactions to a private Flashbots mempool where they are hidden from frontrunning and sandwich bots, and it can return an MEV refund when a transaction creates MEV.[7]
The exposure is not limited to swaps. Any transaction whose outcome depends on order, such as claiming a limited mint, liquidating a loan, or buying the first units of a new token, is visible in the public pool and can be copied or outbid by a bot that pays a higher tip. The mempool broadcasts your intent before the chain commits to it.
See also: Ethereum RPC endpoints · CoW Swap
Reading mempool data yourself
Fee estimators in wallets are built on mempool data. They look at what fee rates or tips recent blocks accepted and how much is waiting, then suggest a value, so the suggestion falls when the pool is quiet and rises quickly when demand spikes.
If you run your own node, you can query your pool directly instead of relying on an explorer's view. Geth's pool settings, such as txpool.pricelimit (a minimum tip of 1 by default), also decide which transactions your node accepts in the first place, so a node's own configuration shapes what it sees.[2]
For Bitcoin, the fee rate a transaction needs is not fixed. Once a node's 300 MB pool is full, low-fee transactions are the ones that get squeezed out, so a fee that relayed fine on a quiet day may not be enough on a busy one. Checking current fee conditions before broadcasting avoids that.[1]
The bottom line
A pending transaction is not lost, it is waiting in a node's memory under limits you can look up: 300 MB and 14 days on Bitcoin Core, a 10% fee bump to replace on Geth. If a transaction is stuck, replace it with the same nonce and a higher fee instead of sending a new one, and route large trades through a private endpoint so the mempool cannot be used against you.[2]
Educational content, not financial advice. Crypto assets are volatile; do your own research.