Mempool Policy

What Is Mempool Policy?

Mempool policy is the set of rules that a Bitcoin Core node applies when deciding whether to accept an unconfirmed transaction into its local mempool and relay it to peers. These rules go beyond consensus validity: a transaction can be perfectly valid according to Bitcoin's consensus rules yet still be rejected by a node's policy filters.

The distinction matters because consensus rules are enforced network-wide and determine what can appear in a block, while policy rules are local preferences that each node operator can configure independently. A miner can include a non-standard transaction directly in a block, and every node on the network will accept that block as valid. Policy provides a defense-in-depth layer that protects individual nodes and the broader relay network without requiring protocol-level changes.

Policy is sometimes called "standardness rules" because transactions that pass all policy checks are considered "standard" and eligible for relay. Transactions that fail policy checks are labeled "non-standard" and silently dropped.

How It Works

When a node receives a new transaction from a peer or via RPC, it runs the transaction through two layers of validation:

1. Consensus validation: is the transaction structurally valid? Are signatures correct? Are inputs unspent? If it fails here, the transaction is invalid and will never be mined.
2. Policy validation: does the transaction meet this node's relay criteria? Is the fee high enough? Is the transaction a standard type? Is the mempool full? If it fails here, the transaction is valid but this node won't relay it.

Only transactions that pass both layers enter the mempool and get forwarded to connected peers. This two-layer design lets the network protect itself from abuse without making the consensus rules more restrictive.

Key Policy Parameters

Bitcoin Core enforces several default policy limits. These are the most important as of Bitcoin Core 30.x:

Node operators can adjust many of these via command-line flags. For example, -minrelaytxfee sets the minimum relay feerate, and -maxmempool controls the mempool size cap.

Standard Transaction Types

Policy restricts which output script types a node will relay. The standard types include P2PKH, P2SH, P2WPKH, P2WSH, P2TR (Taproot), OP_RETURN data outputs, bare multisig, and Pay-to-Anchor (P2A). Transactions using unrecognized script types are rejected by policy even though they may be consensus-valid.

Future SegWit witness versions (beyond v0 and v1) are an exception: nodes relay them to maintain forward compatibility with potential soft forks.

Mempool Eviction

When the mempool reaches its size limit (300 MB by default), the node must decide which transactions to drop. Bitcoin Core evicts transactions with the lowest feerate first, since these are least likely to be mined soon. This creates a dynamic minimum feerate that rises during periods of high demand.

The fee market emerges from this eviction mechanism: when block space is scarce, users compete by offering higher fees, and nodes prioritize accordingly.

Policy vs. Consensus: Why the Distinction Matters

Changing consensus rules requires a soft fork or hard fork, which demands broad network agreement and carries significant coordination risk. Policy changes, by contrast, can be deployed in a regular software update and take effect as individual nodes upgrade.

This flexibility makes policy the preferred tool for addressing new classes of abuse. When transaction pinning became a problem for Lightning channels, the solution was a policy change (TRUC transactions) rather than a consensus change.

Recent Policy Evolution

Several major policy changes have reshaped how Bitcoin handles unconfirmed transactions in recent releases:

Full-RBF

Full replace-by-fee allows any unconfirmed transaction to be replaced by a conflicting transaction paying a higher fee, regardless of whether the original signaled RBF via BIP 125. Bitcoin Core 24.0 introduced it as an opt-in setting. Version 28.0 enabled it by default. Version 29.0 removed the option entirely, making full-RBF mandatory behavior for all Bitcoin Core nodes.

For a detailed walkthrough of fee-bumping mechanics, see the RBF and CPFP guide.

TRUC Transactions (v3 Policy)

Topologically Restricted Until Confirmation (TRUC), specified in BIP 431, introduced version 3 transactions with strict topology constraints: only one unconfirmed parent, only one unconfirmed child, and a child size cap of 10,000 vB. These restrictions eliminate transaction pinning attacks that previously made it difficult to fee-bump Lightning commitment transactions.

TRUC became standard in Bitcoin Core 28.0. Combined with Pay-to-Anchor outputs (BIP 433), it provides reliable fee bumping for Layer 2 protocols. For more context, see the v3 transactions and package relay analysis.

Package Relay

Package relay lets nodes evaluate groups of related transactions together rather than individually. A parent transaction below the minimum relay fee can enter the mempool if paired with a high-fee child, because the package feerate exceeds the threshold. Bitcoin Core 28.0 introduced one-parent-one-child (1p1c) package relay, and subsequent releases have expanded its scope.

This is critical for Lightning: when a commitment transaction is broadcast with a fee set days or weeks ago, its feerate may be too low for current mempool conditions. Package relay enables CPFP fee bumping to work even when the parent alone would be rejected.

Cluster Mempool

Cluster mempool replaces the legacy ancestor and descendant tracking with cluster-based grouping, where transactions are organized into connected components based on parent-child relationships. Merged into Bitcoin Core for the v31.0 release, it replaces the old limits of 25 ancestors and 25 descendants with new limits of 64 transactions and 101 kvB per cluster.

Cluster mempool improves block template construction, makes eviction decisions more accurate, and enables feerate-diagram-based RBF validation that ensures replacements genuinely improve the mempool for miners.

OP_RETURN Relaxation

Bitcoin Core 30.0 raised the default OP_RETURN data limit from 83 bytes to 100,000 bytes and allowed multiple OP_RETURN outputs per transaction. In practice, the max transaction weight (400,000 WU) is the binding constraint. This change acknowledged that users were already embedding data via other methods and that restricting OP_RETURN pushed data into less efficient formats.

Why Policy Exists

Mempool policy serves several practical functions that protect both individual nodes and the network as a whole:

• DoS prevention: fee requirements and size limits make it expensive to flood the network with junk transactions. Without the minimum relay fee, an attacker could broadcast millions of tiny transactions for free.
• Resource management: the mempool size cap (300 MB) and transaction weight limit prevent memory and CPU exhaustion. Sigops limits cap the computational cost of script validation.
• UTXO set hygiene: dust limits prevent the creation of outputs so small they cost more to spend than they are worth, which would permanently bloat the UTXO set that every full node must store.
• Anti-pinning: TRUC topology constraints and package relay rules prevent attackers from making it prohibitively expensive to replace or bump stuck transactions, which is essential for the security of Lightning channels.
• Forward compatibility: relaying unknown future witness versions ensures that soft forks adding new script types can deploy smoothly.

Configuration Examples

Node operators can customize policy through bitcoin.conf or command-line flags:

# Lower the mempool size to 100 MB (useful for resource-constrained nodes)
maxmempool=100

# Raise the minimum relay fee to 0.5 sat/vB
minrelaytxfee=0.0000050

# Disable bare multisig relay
permitbaremultisig=0

These settings only affect the local node. Other nodes on the network may have different policies, which means a transaction rejected by one node might be accepted by another.

Risks and Considerations

Policy Divergence

Because each node sets its own policy, the network can have inconsistent relay behavior. A transaction that propagates successfully through most of the network might be dropped by nodes running stricter policies. In extreme cases, this can create relay gaps where certain transactions struggle to reach miners despite being consensus-valid.

Miner-Policy Mismatch

Miners sometimes include non-standard transactions submitted directly to them, bypassing relay policy entirely. This creates a gap between what the relay network accepts and what actually appears in blocks. Users who rely on policy assumptions (for example, assuming a transaction without RBF signaling cannot be replaced) may be surprised when miners apply different rules.

Ongoing Debates

Policy changes are often contentious because they affect different stakeholders differently. The OP_RETURN size increase in Bitcoin Core 30.0 generated significant community debate, with some arguing it enabled undesirable data embedding while others pointed out that users were already working around the restrictions. Similarly, the transition to mandatory full-RBF affected merchants who had relied on unconfirmed transaction acceptance.

These debates reflect a fundamental tension: policy must balance protecting node resources, supporting Layer 2 protocols, preserving user flexibility, and maintaining practical relay behavior that matches what miners actually include in blocks.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.