Mempool Policy

Mempool policy is the body of local, node-configurable rules that govern which unconfirmed transactions a Bitcoin Core node will accept into its memory pool, retain, and relay to peers. Unlike consensus rules — which every node must enforce identically to agree on the blockchain — policy is advisory and adjustable per node. It exists to manage finite resources (bandwidth, CPU, memory) and to deter abuse, while still converging in practice because most nodes ship the same defaults. A transaction that violates policy is not invalid; it is merely unwelcome at that node's door, and it can still reach a miner by another route and confirm perfectly well.

What policy governs

Policy encompasses standardness checks on script types and transaction shape, the minimum relay feerate, the dust limit that refuses uneconomically small outputs, replace-by-fee handling, package acceptance rules, ancestor/descendant limits on chains of unconfirmed transactions, and eviction behavior when the pool fills. Operators tune it through configuration flags such as -maxmempool, -minrelaytxfee, -limitancestorcount, and -datacarriersize. Each knob is a local statement about what traffic your node is willing to store and forward — your mempool, your rules.

Policy versus consensus

The separation is a deliberate safety boundary. Because policy is not consensus-critical, a node can change it unilaterally without risking a fork: the worst outcome of an eccentric policy is that you see a slightly different set of pending transactions than your peers. That low-stakes property makes the mempool a proving ground — behavior can be trialed as policy for years before anyone contemplates hardening it into consensus. It also means "nonstandard" never means "invalid": a transaction most nodes refuse to relay will still be accepted in a block if a miner includes it, because blocks are judged by consensus rules alone. Bitcoin Core 31.0 introduced a notable structural shift on the limits side: it replaced the older ancestor/descendant size and count enforcement with cluster-based limits, capping connected transaction clusters at 64 transactions and 101 kvB, which makes eviction and fee-based ranking more coherent.

Policy divergence has visible consequences. A transaction standard under one node's rules but not another's propagates patchily, confirming eventually but confusing anyone watching a single mempool; services that accept direct submissions can carry transactions the public relay network never saw; and a wallet's fee estimate is only as good as the mempool view it was computed from. This is why "the mempool" is really "a mempool" — there are as many as there are nodes, converging but never identical.

Why it matters to node runners and miners

For a home node runner, policy is the practical face of sovereignty: your node decides what it stores and relays, and running with defaults is itself a choice — the network's emergent relay behavior is just the sum of everyone's policy. For miners the stakes are more direct: your mempool is your shelf of candidate revenue, and policy determines what lands on the shelf. A solo miner or anyone building their own block templates should understand that overly strict local policy can leave fee-paying transactions out of view, while the divergence between one node's policy and the wider network's explains most "why isn't my transaction propagating?" mysteries. Wallet developers live with policy too — pre-signed transactions in Lightning and vault protocols must be built to satisfy not just consensus but the relay rules standing between them and a miner.

Mempool policy is the umbrella over most relay-layer entries in this glossary. For specific mechanisms see Fee Estimation, which reads the mempool's recent history to price your next transaction, and Transaction Pinning Attacks, which exploit policy limits as a weapon against time-sensitive contracts.