Overview
Mempool policy is the set of rules that a Bitcoin node uses to decide which unconfirmed transactions to accept, relay, and retain in its mempool. These policies are distinct from consensus rules: a transaction that violates mempool policy is not necessarily invalid, it simply will not be propagated by that node. Conversely, a transaction that passes all mempool policy checks will be stored locally and relayed to peers, making it available for inclusion in a future block by a miner.
Mempool policies serve as the network's first line of defense against spam, denial-of-service attacks, and resource exhaustion. They also shape the user experience by determining which transactions get relayed quickly and which are rejected or evicted. While consensus rules are uniform across all nodes (any deviation causes a fork), mempool policies are configurable and can differ from node to node. However, Bitcoin Core's default policies function as de facto network standards because the vast majority of nodes run Bitcoin Core with default settings.
Key Policy Parameters
Policy Bitcoin Core Default Purpose
────────────────────────────────────────────────────────────────────
Minimum relay fee rate 1 sat/vB Spam prevention
Maximum mempool size 300 MB Memory protection
Maximum transaction size 400,000 weight units DoS prevention
Maximum OP_RETURN size 80 bytes Data embedding limit
Mempool expiry time 336 hours (14 days) Stale TX cleanup
Maximum ancestor count 25 Chain length limit
Maximum descendant count 25 Chain length limit
Replace-by-fee Full RBF (v28.0+) Fee bumping
Dust limit 546 sats (P2PKH) Tiny output prevention
330 sats (P2WSH)
How Transactions Are Evaluated
When a node receives a new transaction from a peer or via RPC, it goes through a multi-stage evaluation before being accepted into the mempool:
Incoming Transaction
│
▼
┌─────────────────────────────┐
│ 1. CONSENSUS CHECKS │
│ - Valid signatures? │
│ - Inputs exist and │
│ are unspent? │
│ - No double-spend? │
│ - Script executes? │
└──────────┬──────────────────┘
│ Pass
▼
┌─────────────────────────────┐
│ 2. POLICY CHECKS │
│ - Fee rate ≥ minimum? │
│ - Size within limits? │
│ - Standard script type? │
│ - No dust outputs? │
│ - Ancestor/descendant │
│ chain within limits? │
│ - If replacing: higher │
│ fee than replaced TX? │
└──────────┬──────────────────┘
│ Pass
▼
┌─────────────────────────────┐
│ 3. MEMPOOL ADMISSION │
│ - Add to mempool │
│ - Relay to peers │
│ - If mempool full: evict │
│ lowest fee-rate TXs │
└─────────────────────────────┘
Standardness Rules
One of the most important mempool policies is the concept of "standard" transactions. Bitcoin Core will only relay transactions that use recognized script templates (P2PKH, P2SH, P2WPKH, P2TR, and a few others). Non-standard transactions are not invalid — miners can still include them in blocks — but they will not propagate through the default relay network. This standardness policy protects the network from resource-intensive scripts and provides a conservative surface area for potential vulnerabilities.
The standardness rules have evolved over time. Taproot scripts (P2TR) were added as standard when the Taproot soft fork activated in 2021. The definition of what is "standard" is a policy decision, not a consensus one, and it can be updated in new Bitcoin Core releases without requiring a fork.
Replace-by-Fee Policy
Replace-by-fee (RBF) is a mempool policy that determines whether a node will replace an existing unconfirmed transaction with a new version that pays a higher fee. Bitcoin Core 28.0 introduced full RBF as the default, meaning any unconfirmed transaction can be replaced by a conflicting transaction with a higher fee rate. This policy is essential for users who need to fee-bump stuck transactions and for the proper functioning of Lightning Network anchor outputs.
Mempool Eviction
When a node's mempool reaches its maximum size (300 MB by default), it must evict transactions to make room for new ones. The eviction algorithm removes the transactions with the lowest fee rate, following the logic that these are least likely to be mined soon. This creates a dynamic minimum fee rate: during congestion, the effective minimum fee for mempool admission rises above the static 1 sat/vB default, as transactions must pay more than the lowest-fee-rate transactions already in the pool.
Mempool at capacity (300 MB):
Lowest fee-rate tx in pool: 5 sat/vB
New tx at 3 sat/vB: REJECTED (below dynamic minimum)
New tx at 6 sat/vB: ACCEPTED (evicts 5 sat/vB tx)
Why Policy Differs from Consensus
The separation between policy and consensus is a deliberate design choice. Consensus rules define what is valid on the blockchain and must be identical across all nodes. Policy rules define what each node is willing to relay and store, and they can be adjusted without risking a chain split. This separation allows the network to evolve its spam-prevention and relay behavior more quickly and flexibly than consensus rules, which require broad agreement and typically a soft fork or hard fork to change.
Related Concepts
- Mempool — the transaction pool governed by these policies
- Fee Rate — the primary metric used for transaction prioritization and eviction
- Replace-by-Fee — a key mempool policy for transaction replacement
- Full Node — nodes that independently apply mempool policies
- Bitcoin Core — the reference implementation whose defaults define de facto policy
- Unconfirmed Transaction — transactions subject to mempool policies
- Anchor Outputs — Lightning feature that relies on specific mempool policies