Bitcoin Mempool Policy Reference: Rules and Limits

Mempool Policy Overview

The Bitcoin Core mempool enforces a set of policy rules that determine which unconfirmed transactions a node will accept, relay, and retain. These rules are stricter than consensus: a transaction can be valid under consensus yet rejected by mempool policy. Policy exists to prevent denial-of-service attacks, limit resource usage, and ensure transactions are economically rational for miners to include in blocks.

The following table summarizes the core policy parameters as of Bitcoin Core v30.0 (October 2025), with notes on the upcoming v31.0 cluster mempool changes. All values are defaults configurable via bitcoin.conf unless noted otherwise.

Minimum Relay Fee and Dynamic Fee Floor

The minrelaytxfee sets the absolute floor for transaction fees: any transaction paying less than this rate is rejected outright. Bitcoin Core v29.1 and v30.0 lowered this default from 1,000 sat/kvB (1 sat/vB) to 100 sat/kvB (0.1 sat/vB), a tenfold reduction that allows lower-fee transactions during periods of low demand.

When the mempool fills beyond maxmempool, the node raises a dynamic minimum feerate above minrelaytxfee. This dynamic floor equals the feerate of the lowest-fee transaction that was evicted, plus the incremental relay fee. The dynamic floor decays slowly (halving over hours) once congestion subsides, preventing the mempool from immediately refilling with low-fee transactions.

For practical fee estimation strategies, see the fee estimator tool and our research on Bitcoin fee market dynamics.

Mempool Size and Eviction

The default maximum mempool size is 300 MB, measured by transaction virtual bytes. When running in -blocksonly mode, the limit drops to 5 MB. The minimum configurable value is 5 MB regardless of mode.

When the mempool exceeds its size limit, the node evicts transactions by lowest descendant feerate: the transaction whose package (itself plus all in-mempool descendants) has the lowest combined feerate is removed first. This ensures that the remaining mempool represents the most fee-profitable set of transactions for miners.

Transactions also expire after mempoolexpiry hours (default 336 hours, or 14 days) regardless of feerate. This prevents transactions with timelocks or unusually low fees from consuming mempool space indefinitely. On shutdown, the mempool is persisted to mempool.dat (controlled by -persistmempool) and reloaded on startup.

Replace-by-Fee (RBF) Rules

Replace-by-Fee allows an unconfirmed transaction to be replaced by a higher-fee version. Bitcoin Core's RBF policy has evolved significantly:

• v0.12.0 (February 2016): opt-in RBF introduced per BIP 125, requiring nSequence < 0xFFFFFFFE to signal replaceability
• v24.0 (November 2022): -mempoolfullrbf option added, default off
• v28.0 (October 2024): -mempoolfullrbf default changed to 1 (full RBF on by default)
• v29.0 (April 2025): -mempoolfullrbf removed entirely; full RBF is now unconditional

Under current rules, any unconfirmed transaction can be replaced regardless of signaling. The replacement must satisfy these conditions:

• The replacement must pay an absolute fee at least equal to the sum of fees paid by all original (replaced) transactions
• The replacement must pay additional fees to cover its own bandwidth at the incremental relay feerate: replacement_fee >= sum_of_original_fees + (replacement_vsize × incrementalrelayfee)
• The number of distinct clusters affected by conflicting transactions must not exceed 100

Starting with v31.0 and cluster mempool, a new Rule 6 requires that the replacement strictly improves the mempool's feerate diagram: a mathematical test of incentive-compatibility that replaces the older simple "higher feerate" check. For a practical guide to using RBF, see the RBF detector tool.

CPFP, Carve-Out, and Package Relay

Child-Pays-for-Parent (CPFP) lets a high-fee child transaction pull a low-fee parent into a block. The miner evaluates the parent and child as a package, and if the combined feerate exceeds the block minimum, both are included.

Ancestor and Descendant Limits (Pre-v31)

Before cluster mempool, Bitcoin Core enforced per-transaction chain limits: a maximum of 25 ancestors and 25 descendants, each capped at 101 kvB total size. The CPFP carve-out exception allowed one additional child beyond the descendant limit if it had exactly one unconfirmed ancestor and was no larger than 10 kvB. This carve-out was designed for Lightning Network commitment transactions where both parties need the ability to bump fees.

Cluster Mempool (v31+)

Bitcoin Core v31.0 replaces ancestor/descendant limits with cluster limits. A cluster is the connected component of all related transactions in the mempool. The defaults are 64 transactions and 101 kvB per cluster. The CPFP carve-out is removed; its use cases are served by TRUC transactions and sibling eviction instead.

Package Relay

Package relay allows a group of related transactions to be evaluated together, enabling a child to pay for a parent that would otherwise be rejected for paying below the mempool minimum feerate:

• v26.0: submitpackage RPC for local package CPFP submission
• v28.0: opportunistic 1-parent-1-child (1p1c) package relay over P2P, plus limited package RBF
• v30.0: improved 1p1c relay handling multi-parent and grandparent scenarios
• v31.0: non-TRUC parents in 1p1c packages can have feerates below minrelaytxfee, including zero fees

Package submissions are capped at 25 transactions and 404,000 weight units (101,000 vB), in child-with-parents topology.

Dust Thresholds

Outputs below the dust threshold are rejected to prevent the UTXO set from bloating with economically unspendable outputs. The threshold depends on the output type because different scripts require different-sized inputs to spend. The formula is: dust = (serialized_output_size + spending_input_overhead) × dustrelayfee / 1000

The default dustrelayfee is 3,000 sat/kvB (3 sat/vB), independent of minrelaytxfee. Non-witness inputs assume 148 bytes of overhead; witness program inputs assume 67 bytes.

Bitcoin Core v29.0 introduced ephemeral dust: a transaction with a single dust output is accepted if it pays zero fees and the dust output is spent by another transaction in the same package. This enables patterns like anchor outputs in Lightning commitment transactions. For more on dust management, see the dust thresholds reference.

Standardness Rules

Standardness rules are policy checks that go beyond consensus validity. A "non-standard" transaction is valid on-chain but will not be relayed or accepted into the mempool by default Bitcoin Core nodes. Miners can still include non-standard transactions in blocks if they receive them through other means.

Transaction Size Limits

• Maximum standard transaction weight: 400,000 WU (100,000 vB)
• Minimum non-witness transaction size: 65 bytes (prevents CVE-2017-12842 Merkle tree attacks)

Transaction Versions

Standard versions are 1, 2, and 3. Version 2 is required for nSequence-based relative timelocks (BIP 68/112/113). Version 3 designates TRUC (Topologically Restricted Until Confirmation) transactions per BIP 431, standard since v28.0.

Script and Signature Limits

OP_RETURN Data

OP_RETURN outputs are provably unspendable and used for embedding data on-chain. Bitcoin Core v30.0 raised the maximum OP_RETURN data size from 83 bytes to 100,000 bytes and removed the restriction to a single OP_RETURN output per transaction. The -datacarrier and -datacarriersize options were deprecated.

TRUC (v3) Transaction Policy

TRUC transactions (BIP 431) are version 3 transactions with tighter policy constraints designed for protocols like Lightning that need reliable fee bumping. TRUC transactions are standard since Bitcoin Core v28.0 and offer guaranteed replaceability plus sibling eviction.

TRUC transactions solve a key problem for Lightning: commitment transactions can be broadcast with minimal or zero fees, then immediately bumped by a small child transaction. The tight chain limits prevent pinning attacks where a counterparty inflates the descendant chain to block fee bumping. For background on how this fits into Lightning channel management, see our research on Lightning channel management.

Version History: Recent Policy Changes

Bitcoin Core mempool policy is not static. The following summarizes significant changes across recent releases:

• v25.0 (May 2023): minimum non-witness transaction size set to 65 bytes; -blocksonly mempool capped at 5 MB
• v26.0 (December 2023): submitpackage RPC added for local package CPFP
• v28.0 (October 2024): full RBF on by default; TRUC/v3 transactions standard; 1p1c package relay over P2P; limited package RBF
• v29.0 (April 2025): full RBF unconditional (config option removed); ephemeral dust support
• v29.1 (September 2025): minrelaytxfee and incrementalrelayfee lowered to 100 sat/kvB; blockmintxfee lowered to 1 sat/kvB; legacy sigops limit added
• v30.0 (October 2025): OP_RETURN limit raised to 100,000 bytes; multiple OP_RETURN outputs allowed; improved 1p1c relay
• v31.0 (expected H2 2026): cluster mempool replacing ancestor/descendant limits; CPFP carve-out removed; feerate diagram RBF policy

Implications for Layer 2 Protocols

Mempool policy directly affects the security and reliability of off-chain protocols. Lightning Network force-close transactions must propagate through the mempool under potentially adversarial conditions: high congestion, competing replacements, or deliberate pinning attempts.

TRUC transactions and package relay were specifically designed to address these challenges. A Lightning node can broadcast a commitment transaction at zero fee, then attach a small CPFP child to set the effective feerate based on current conditions. The tight TRUC chain limits (max 2 ancestors, max 2 descendants) prevent the counterparty from creating large descendant chains that would block fee bumping.

Layer 2 protocols built on Bitcoin, including Spark, benefit from these policy improvements. Understanding mempool acceptance rules is essential for any protocol that relies on timely transaction confirmation. For a broader comparison of Bitcoin layer 2 approaches, see our Bitcoin layer 2 comparison.

Frequently Asked Questions

What is the minimum fee to get a Bitcoin transaction into the mempool?

As of Bitcoin Core v30.0, the default minimum relay fee is 100 sat/kvB (0.1 sat/vB). A typical single-input, two-output SegWit transaction of ~140 vB would need at least 14 satoshis in fees to be accepted. However, during congestion the dynamic minimum feerate rises above this floor, and you will need to pay more to enter the mempool. Use a fee estimator for current rates.

What happens when the Bitcoin mempool is full?

When the mempool exceeds its 300 MB default limit, the node evicts transactions with the lowest descendant feerate first. It also raises the dynamic minimum feerate, rejecting new transactions that pay below the evicted threshold. Once congestion subsides, the dynamic floor decays slowly, allowing lower-fee transactions back in.

Can any Bitcoin transaction be replaced with RBF?

Yes. Since Bitcoin Core v29.0, full RBF is unconditional. Any unconfirmed transaction can be replaced by a conflicting transaction that pays higher absolute fees and covers the replacement's bandwidth cost. The old opt-in signaling requirement (BIP 125, nSequence < 0xFFFFFFFE) is no longer checked. For details on how to detect and use RBF, see the RBF detector.

What is the dust limit for a Taproot output?

The dust threshold for a Taproot (P2TR) output is 330 satoshis at the default dustrelayfee of 3,000 sat/kvB. This is calculated from a 43-byte serialized output plus 67 bytes of witness input overhead. Outputs below this value are rejected by mempool policy to prevent UTXO set bloat.

What are TRUC transactions and why do they matter?

TRUC (Topologically Restricted Until Confirmation) transactions are version 3 transactions defined in BIP 431. They enforce tight chain limits (max 2 ancestors, max 2 descendants) and are always replaceable. TRUC was designed for Lightning Network commitment transactions: it prevents pinning attacks and enables reliable fee bumping via package relay, even with zero-fee parent transactions.

What is cluster mempool in Bitcoin Core v31?

Cluster mempool is a redesign of how Bitcoin Core organizes the mempool. Instead of tracking per-transaction ancestor and descendant limits (previously 25 each), v31.0 groups connected transactions into clusters limited to 64 transactions and 101 kvB. This enables more accurate feerate comparisons for RBF (using feerate diagrams) and removes the CPFP carve-out in favor of TRUC transactions and sibling eviction.

How does package relay work in Bitcoin Core?

Package relay allows a parent and child transaction to be evaluated together against mempool policy. A high-fee child can pay for a parent that would otherwise be rejected for paying below the minimum feerate. Bitcoin Core v28.0 introduced opportunistic 1-parent-1-child (1p1c) package relay over the P2P network, and v31.0 extends this to allow non-TRUC zero-fee parents. The submitpackage RPC supports local package submission with up to 25 transactions.

This reference is for informational purposes only and does not constitute financial advice. Policy values reflect Bitcoin Core defaults and may differ on nodes running custom configurations or alternative implementations. Values are based on publicly available Bitcoin Core source code and release notes. Always verify current policy against the version of Bitcoin Core you are running.