Bitcoin Mempool Eviction: Why Your Transaction Vanished During a Fee Spike
You open a mempool explorer the morning after sending bitcoin. The transaction was pending when you went to bed. Now it isn't there. No confirmation, no error message, no trace. You check your wallet. Still shows outgoing. You refresh the explorer. Nothing. That silence is not a bug. It is the protocol doing precisely what it was designed to do, and the mechanism behind it is worth understanding in some detail.
The mempool has a weight limit, not just a queue
Bitcoin nodes don't hold transactions forever. By default, Bitcoin Core caps the mempool at 300 megabytes of transaction data. When that limit fills, the node doesn't freeze. It runs an eviction pass: sorting every unconfirmed transaction by fee rate (satoshis per virtual byte, or sat/vB), finding the ones at the bottom, and dropping them until the mempool shrinks back below the cap.
The eviction threshold is a live number. It rises as demand rises.
When the mempool is calm, a 1 sat/vB transaction will sit peacefully for up to two weeks before the node eventually times it out. But when a fee spike hits and the mempool fills, that same transaction can be evicted within minutes. Not timed out. Actively removed, like a nightclub bouncer walking back through the crowd to eject the guests who tipped the least, fire-code limit be damned.
The scenario that makes this concrete
Two people, Priya and Marcus, both send bitcoin on the same afternoon. Priya sets her fee at 8 sat/vB. Marcus, trying to save a few dollars, sets his at 3 sat/vB. Both transactions enter the mempool without issue. The mempool sits at 240 MB.
Three hours later, an exchange withdrawal wave hits. Thousands of transactions flood in at 15 to 25 sat/vB. The mempool crosses 300 MB, and Bitcoin Core on each node calculates the minimum fee rate needed to stay in the pool. That floor climbs to 5 sat/vB. Marcus's transaction is now below the threshold. It gets evicted. Priya's survives.
Marcus's wallet may still show the transaction as pending. His own node may not yet know the network has dropped it. He waits. Nothing happens. Under normal timeout conditions, funds can take up to 14 days to return. During an active eviction event, it happens considerably faster.
This is not an edge case. It is the ordinary arithmetic of a full mempool.
What people consistently get wrong
The most common misconception is that a low-fee transaction will simply confirm slowly. Sometimes that's true. During a genuine fee event, it won't confirm at all. It vanishes.
Replace-By-Fee (RBF) is the obvious remedy, and it works, but only under one condition: the original transaction must still be in the mempool when you attempt the replacement. If it has already been evicted, there is nothing to replace. The higher-fee rebroadcast propagates into a void, and propagation itself becomes unreliable. Timing, here, is not a minor consideration. It is the whole game.
Child-Pays-For-Parent (CPFP) carries the same vulnerability. If a parent transaction is evicted before the child can pull it forward, the entire chain collapses. You cannot bump a ghost.
So ask yourself: if your fee rate is currently sitting below the minimum floor shown on mempool.space, what exactly are you waiting for?
Eviction and expiry are not the same mechanism
This distinction matters and is routinely collapsed in casual explanations. Expiry is the 336-hour (14-day) timeout applied to any unconfirmed transaction. Eviction is the fee-floor purge that can execute within minutes during a fee spike. A transaction can be evicted long before it expires. The user-facing result looks identical in both cases, which is part of why the confusion persists, but the underlying mechanics are separate code paths with separate triggers.
The practical consequence is this: setting a fee rate that merely clears the mempool as it exists at the moment of broadcast is insufficient during volatile periods. The relevant question is what the mempool will look like an hour from now. That is a harder estimate, but the tools exist. Mempool.space displays the live fee distribution in real time. Wallets with defensible fee estimation, Bitcoin Core and Sparrow being the clearest examples, draw on recent block history rather than a single snapshot. Wallets that don't are, in this analyst's view, quietly transferring risk onto users who don't know to ask.
The mempool is not a waiting room. It is a competitive market with a bouncer whose standards change by the minute, and the price of underestimating that is paid entirely by the sender.