Mempool Eviction

Mempool eviction is what a Bitcoin node does when its memory pool fills up: to stay within its configured size cap it discards the lowest-feerate transactions to make room for higher-paying ones. The default cap is set by -maxmempool (300 MB in Bitcoin Core), and once the pool reaches it, the node trims from the bottom of the fee market rather than refusing all new transactions outright. Eviction is the pressure-relief valve that keeps every node's memory bounded no matter how much transaction demand the network throws at it.

How eviction works

Transactions are ranked by their feerate including descendants, so a low-fee parent kept alive by a high-fee child is scored on the package rather than punished for its own stinginess. When space is needed, the node evicts the lowest-scoring transaction (and its descendants, since a child cannot remain without its parent). Crucially, eviction also raises the node's effective minimum relay feerate to just above the feerate of the last transaction evicted, so during congestion a node will reject anything cheaper than what it just dropped — which is why low-fee transactions can vanish from the network during a fee spike and need re-broadcasting later, once the floor decays back toward normal as demand subsides.

Every mempool is local

A detail that surprises many users: there is no single, canonical mempool. Each node maintains its own, and eviction is applied locally against local settings, so during congestion different nodes hold different pictures of pending transactions. A transaction evicted by most of the network may survive on nodes configured with larger pools, and can propagate again when conditions ease. This is also a practical argument for running your own node: fee-estimation and "is my transaction still pending?" answers come from your mempool, not a third-party explorer whose eviction state may differ.

Why it matters

Eviction is the mechanism that makes the mempool a true fee market under load: block space is scarce, and when demand exceeds it, the cheapest transactions are simply forgotten until fees fall. For anyone sending Bitcoin, the practical lesson is to either pay a competitive feerate, use Replace-by-Fee to bump a stuck payment, or be prepared to rebroadcast a transaction that gets evicted — the sender's wallet still holds it even after the network forgets. It is also a denial-of-service safeguard, bounding how much memory an adversary can force a node to consume: flooding the network with junk transactions just raises the floor and evicts the flood.

The miner's view

For miners, the mempool is the shelf of paying work from which block templates are built, and eviction keeps that shelf stocked with the best-paying candidates rather than an unbounded backlog. A transaction that survives eviction on well-connected nodes is a transaction that remains candidate revenue; one that gets dropped effectively exits the auction until resubmitted at a better bid.

Eviction is one of two ways a transaction leaves the mempool without confirming; the other is expiry. Bitcoin Core also drops transactions that have lingered unconfirmed beyond -mempoolexpiry (336 hours — two weeks — by default), regardless of fee pressure. And because the mempool lives in memory, Core persists it to mempool.dat on shutdown and reloads it on start, so a restart is not an amnesia event. Together these mechanics explain most "my transaction disappeared" mysteries: it was evicted under load, it expired quietly, or a briefly offline node never saw it — and in every case the sender's wallet can simply rebroadcast.

Eviction is governed by mempool policy and the ancestor/descendant limits that bound transaction chains; avoiding it is a matter of accurate fee estimation against a live view of the mempool.