Mempool Minimum Fee

The mempool minimum fee is the feerate floor a transaction must meet to be accepted into a particular node's memory pool. Reported as mempoolminfee by the getmempoolinfo RPC, it is defined as the maximum of two values: the static minimum relay feerate and the mempool's own dynamic minimum, which rises under load. On a quiet network the floor sits at the relay minimum — historically 1 sat/vByte by default. During congestion it climbs, which is why the very same transaction that sails into an idle node's pool can be rejected outright by a busy one. The floor is a per-node defense, and understanding it explains a whole family of "my transaction disappeared" mysteries.

How the dynamic floor works

Every node bounds its mempool's memory with -maxmempool (default 300 MB of in-memory usage, which corresponds to far less serialized transaction data). When an incoming transaction would push the pool past that cap, the node performs mempool eviction: it discards the lowest-feerate package — a transaction together with its dependents — and then raises its effective minimum to the evicted package's feerate plus a small increment. The floor therefore ratchets upward as cheap transactions are squeezed out, ensuring the node does not immediately re-accept the same class of traffic it just evicted. When pressure subsides, the floor decays gradually back toward the relay minimum over roughly half a day rather than snapping down instantly. The full policy context lives in mempool policy.

Why transactions "vanish" during fee spikes

The floor's most confusing consequence: a low-fee transaction broadcast during calm conditions can be silently dropped later as pools tighten — evicted from nodes that had already accepted it, and refused by nodes it tries to reach afterward. Nothing about the transaction is invalid; it simply no longer clears the network's prevailing floors, so it stops propagating and eventually exists nowhere but in the sending wallet. Because each node computes its own floor from its own maxmempool and its own traffic history, the value differs across the network at any moment — there is no single global mempool, only thousands of individual ones enforcing their own admission prices. Your own node's floor, not an explorer's, is the one that governs what you relay; nodes with mempools persisted across restarts (see mempool persistence) can even carry old cheap transactions their neighbors have long forgotten.

What it means for wallets and users

The static half of the floor has its own policy history: the 1 sat/vByte default stood for years as an anti-spam dust threshold, and recent Bitcoin Core versions made the relay minimum configurable downward for operators who want to admit sub-1 sat/vByte traffic when block space is genuinely slack. The dynamic mechanism rides on top of whatever static base the node's operator chooses — policy, as always, is set node by node.

Competent wallets read mempoolminfee before broadcasting so they never create a transaction that peers will simply ignore, and they treat it as a floor beneath whatever fee estimation suggests for timely confirmation. When a payment does get stranded below a rising floor, the remedies are the standard fee-bumping tools: Replace-by-Fee to rebroadcast at a higher feerate, or Child-Pays-for-Parent to attach a well-paying dependent. For miners the floor matters differently — transactions below it never reach the pool, so they can never be selected into a block template, no matter what they might have paid. The mempool minimum fee is, in short, the market's admission ticket enforced node by node: a small, local rule from which the network's global fee dynamics emerge — no coordinator required, in proper Bitcoin fashion.