Research/Bitcoin

Bitcoin Mempool Economics: What Happens When Blocks Are Full and Fees Spike

How Bitcoin's mempool works during congestion events, fee estimation strategies, and the economic incentives that shape block space markets.

bcMaoJun 9, 2026

Every ten minutes, Bitcoin produces a block with roughly 4 million weight units of capacity. When demand for that space exceeds supply, unconfirmed transactions accumulate in the mempool, and users compete for inclusion by bidding higher fees. This is the Bitcoin fee market in action: a real-time auction for block space that has produced average transaction fees ranging from under $1 to over $127 depending on network conditions.

Understanding mempool economics is essential for anyone building on Bitcoin or transacting during congestion. This article covers how the mempool works, what drives fee spikes, how miners select transactions, and what strategies exist for managing costs when blocks are full.

How the Bitcoin Mempool Works

There is no single global mempool. Each Bitcoin full node maintains its own local pool of unconfirmed transactions. When a node receives a new transaction, it validates the transaction against consensus rules and local policy rules, then relays it to connected peers. The transaction propagates across the network within seconds, landing in thousands of independent mempools simultaneously.

Transactions in the mempool are ordered by fee rate, measured in satoshis per virtual byte (sat/vB). A transaction paying 50 sat/vB will generally confirm before one paying 10 sat/vB, because miners prioritize higher-paying transactions when constructing blocks. During quiet periods, even 1 sat/vB transactions confirm within a few blocks. During congestion, the minimum fee rate for next-block inclusion can exceed 500 sat/vB.

Size Limits and Eviction

Bitcoin Core's default mempool size limit is 300 MB. When the mempool exceeds this threshold, the node evicts the lowest-fee-rate transaction packages first, using a metric called the descendant score. Transactions that fall below the eviction threshold are dropped entirely and must be rebroadcast. By default, transactions also expire after 336 hours (14 days) if they remain unconfirmed.

The minimum relay fee determines the floor for transaction acceptance. Historically set at 1 sat/vB, Bitcoin Core v29.1 (released September 2025) reduced this by 90% to 0.1 sat/vB, reflecting Bitcoin's increased exchange rate over the past decade. This change allows lower-value transactions to enter the mempool during quiet periods without compromising denial-of-service protection.

Each node is different: Because every node applies its own policy rules, your transaction might exist in one node's mempool but not another's. A transaction rejected by one node for being below its minimum fee rate may still be accepted by nodes running different configurations. This is why "the mempool" is a simplification: in practice, it is thousands of slightly different transaction pools across the network.

How Miners Select Transactions

When a miner (or mining pool) constructs a block template, Bitcoin Core's getblocktemplate RPC uses a greedy algorithm that ranks transactions by fee rate and fills the block starting from the highest-paying transactions until the 4 million weight unit limit is reached. The algorithm also considers transaction dependencies: if transaction B spends an output from unconfirmed transaction A, both must be included together, and the miner evaluates the combined (ancestor) fee rate of the package.

This incentive structure is straightforward: miners maximize revenue by including the highest-fee-rate transactions available. But it creates nuanced dynamics. A transaction paying a high absolute fee but with a large size (low fee rate) may be passed over in favor of several smaller transactions that collectively pay more per unit of block weight.

Fee Sniping and nLockTime

Fee sniping is a theoretical attack where a miner deliberately re-mines a previous block to capture its transaction fees instead of building on the chain tip. This becomes rational when a previous block's fees significantly exceed the fees available in the current mempool. If the previous block contained 5 BTC in fees and the current mempool offers only 0.5 BTC, a miner with sufficient hashrate has incentive to fork the chain and claim those fees.

Bitcoin Core mitigates fee sniping by setting nLockTime on wallet-created transactions to the current block height, making them invalid for inclusion in re-mined earlier blocks. This is a soft defense: it reduces the fee-sniping reward but does not eliminate the incentive entirely.

Out-of-Band Payments

Not all transactions enter the mempool through standard relay. Users can submit transactions directly to miners via private channels, paying for inclusion through Lightning, Liquid, or other off-chain mechanisms. These out-of-band payments bypass the public fee market entirely. The practice became more visible during the Ordinals and Runes waves, when collectors paid premium fees for inclusion in specific blocks. The halving block (block 840,000) carried a record 37.6 BTC in fees, with much of that driven by users seeking inclusion in a historically significant block.

Historical Congestion Events

Bitcoin's fee market has experienced several dramatic congestion episodes. Each one reveals how quickly fees can escalate when block space demand outpaces supply, and how different user populations respond to sudden cost increases.

EventDatePeak Avg. FeeMempool BacklogPrimary Cause
Bull run congestionDecember 2017$56+200,000+ transactionsPrice surge to $20,000, 1 MB block limit
Bull run + China mining banApril 2021$62.80350,000+ daily transactionsATH price run, hashrate disruption
BRC-20 / Ordinals waveMay 2023$31400,000 transactionsInscription activity, 534K daily txns
Ordinals resurgenceDecember 2023$38.43199 sat/vB median fee rate53M+ cumulative inscriptions
Halving + Runes launchApril 2024$127.97Priority fees exceeded $200Runes accounted for 70% of fees on launch day
Market panic sell-offMarch 2025$82.53Fees dropped to $3.27 within 30 hours18-hour panic selling period

The Ordinals and BRC-20 Wave

The Ordinals protocol, launched by Casey Rodarmor in January 2023, introduced a method for inscribing arbitrary data into Bitcoin transactions. The subsequent BRC-20 token standard (published March 2023) triggered an inscription frenzy that pushed daily inscriptions to 223,000 on April 29, 2023. By May 8, total fees per block briefly exceeded the 6.25 BTC block subsidy for the first time since 2017. The seven-day moving average of daily transactions hit an all-time high of 534,000 on May 9, and the mempool swelled to over 400,000 unconfirmed transactions. Average block size jumped from 1.2 MB to over 2 MB as inscription data filled the witness discount space.

Total Bitcoin transaction fees in 2023 reached 23,445 BTC, more than four times the 5,375 BTC paid in 2022. Roughly 5,000 BTC of that came directly from inscription activity.

The April 2024 Halving and Runes

Bitcoin's fourth halving occurred at block 840,000 on April 20, 2024, cutting the block subsidy from 6.25 to 3.125 BTC. Simultaneously, Rodarmor launched the Runes protocol, a more efficient fungible token standard. The combination created the most extreme fee spike in Bitcoin's history: average transaction fees hit $127.97, with priority transactions exceeding $200. The halving block itself carried 37.6 BTC in fees (worth over $2.4 million). On that single day, miner revenue surged to a record $107.8 million, with transaction fees representing over 75% of total revenue.

Fee Revenue and the Security Budget

For most of Bitcoin's history, transaction fees have contributed a small fraction of total miner revenue: typically 1% to 5% during normal conditions. The block subsidy dominates. But the subsidy halves approximately every four years, and the long-term question of whether fees alone can sustain network security is one of the most debated topics in Bitcoin mining economics.

Congestion events demonstrate that fee revenue can surge dramatically when demand exists. On April 20, 2024, fees exceeded 75% of miner revenue. But these spikes are temporary. By September 2024, fees had fallen back to just 1.6% of daily miner revenue ($398,860 out of $25.35 million). By March 2026, weekly fee revenue dropped to 11.4 BTC, a ratio of just 0.6%.

The security budget question: As the block subsidy approaches zero over the coming decades, Bitcoin's security will increasingly depend on transaction fee revenue. The volatility of fee income (from 0.6% to 75% of revenue depending on conditions) makes long-term security budgeting an open research problem. Some argue that persistent demand for block space through L2 settlement, token protocols, and financial applications will fill the gap. Others point to the current data showing fee revenue consistently below 5% during normal periods.

Fee Estimation: How Wallets Predict Costs

Bitcoin Core's fee estimation algorithm takes a target number of blocks as input and returns a recommended fee rate. It tracks confirmed transactions, groups them into fee-rate buckets, and uses an exponentially decaying moving average to determine the lowest fee rate at which a high fraction of transactions confirmed within the target window. Critically, it does not attempt to predict future mempool conditions: it extrapolates from recent history.

Conservative vs. Economical Mode

Bitcoin Core offers two estimation modes. Conservative mode uses a longer transaction history and produces higher fee recommendations, suitable for time-sensitive payments. Economical mode is more responsive to recent fee drops, optimizing for lower costs when some confirmation delay is acceptable.

A "next-block" target (1 block) recommends the highest fee rate, aiming for inclusion in the very next block. Economy targets (6, 12, or 25+ blocks) produce progressively lower recommendations. The difference can be substantial: during moderate congestion, a next-block estimate might suggest 80 sat/vB while a 25-block target recommends 15 sat/vB.

Common Fee Estimation Pitfalls

Wallet fee estimation is imperfect, and users encounter two common failure modes:

  • Overpaying: wallets using conservative estimates during rapidly declining fee periods recommend rates far above what is needed for timely confirmation, wasting user funds
  • Stuck transactions: wallets using stale estimates during rapidly rising fee periods recommend rates that are too low, leaving transactions unconfirmed for hours or days

Third-party APIs from services like mempool.space analyze the current mempool state directly rather than relying on historical confirmation data, often producing more accurate short-term estimates. Many modern wallets combine multiple estimation sources to improve accuracy.

Strategies for Managing Congestion Costs

Several techniques exist for reducing transaction costs, particularly during high-fee periods. The effectiveness of each depends on the use case and whether the user is sending or receiving.

StrategyFee SavingsWhen to UseTradeoff
SegWit (native bech32)30-40% vs. legacyAlways: use P2WPKH or P2TR addressesRequires wallet support (near-universal now)
Transaction batchingUp to 80% for high-volume sendersExchanges, payment processors, payrollAdds latency; recipients wait for batch window
RBF (Replace-by-Fee)Avoids overpaying upfrontWhen fee conditions are uncertainRecipient sees unconfirmed replacement
CPFPUnsticks low-fee transactionsWhen you receive a stuck paymentRequires spending the unconfirmed output
UTXO consolidationReduces future input costsDuring low-fee periods (below 5 sat/vB)Privacy reduction from merging UTXOs
Layer 2 protocolsNear-zero marginal costFrequent or small-value transfersDifferent trust and liquidity models

SegWit and the Witness Discount

Segregated Witness (activated August 2017) introduced a weight-based fee calculation where witness data receives a 75% discount: 1 byte of witness data counts as 1 weight unit versus 4 weight units for non-witness data. A typical native SegWit (P2WPKH) transaction is 30% to 40% cheaper than an equivalent legacy transaction. A Bitcoin Optech analysis estimated that approximately 37,000 BTC ($340 million at the time) could have been saved between 2017 and 2020 if all users had adopted native SegWit addresses, representing roughly 38% savings on the 97,000 BTC actually paid in fees during that period.

Replace-by-Fee and CPFP

Replace-by-Fee (BIP 125) allows senders to replace an unconfirmed transaction with a higher-fee version. Originally opt-in (introduced in Bitcoin Core 0.12.0 in February 2016), full RBF became the default in Bitcoin Core v28.0, released October 2024. With full RBF, any unconfirmed transaction can be replaced regardless of whether it signaled replaceability, eliminating the need for upfront fee guessing.

Child-Pays-for-Parent (CPFP) works from the receiving side. If you receive a payment stuck at a low fee rate, you can spend that unconfirmed output in a new "child" transaction with a fee high enough to incentivize miners to confirm both the parent and child together. Miners evaluate the combined fee rate of the parent-child package, effectively allowing recipients to bump transactions they did not create.

Recent Bitcoin Core Mempool Improvements

Bitcoin Core's mempool implementation has seen significant changes in recent versions, each addressing different aspects of congestion management and transaction relay efficiency.

Full RBF by Default (v28.0)

Bitcoin Core v28.0 (October 2024) enabled full RBF by default, changing the -mempoolfullrbf setting from 0 to 1. This was a long-debated change: it means any unconfirmed transaction can be replaced with a higher-fee version, regardless of BIP 125 signaling. For users, this simplifies fee management during congestion because they can always bump a stuck transaction.

Package Relay and TRUC Transactions (v28.0)

The same release introduced package relay for low-fee parent transactions. Transactions below the mempool minimum fee rate can now be opportunistically paired with child transactions and submitted as packages. Additionally, version 3 (TRUC: Topologically Restricted Until Confirmation) transactions received special treatment under BIP 431, allowing TRUC parents to be accepted even below the minimum relay fee rate. These changes make CPFP more reliable during severe congestion.

Cluster Mempool (v31.0)

The most significant architectural change to Bitcoin Core's mempool in years, cluster mempool was merged in November 2025 for inclusion in v31.0. It replaces the ancestor/descendant-based mempool architecture with a cluster-based approach. The old system imposed separate ancestor and descendant size and count limits. The new system groups related transactions into clusters, each capped at 64 transactions and 101 kB in virtual size. This enables better block template construction, more accurate eviction decisions, and improved RBF validation. For users, it means more predictable fee estimation and fairer transaction prioritization during congestion.

Minimum Relay Fee Reduction (v29.1)

Bitcoin Core v29.1 (September 2025) reduced the default minimum relay fee from 1 sat/vB to 0.1 sat/vB (from 1,000 sat/kvB to 100 sat/kvB). This 90% reduction reflected Bitcoin's price appreciation over the past decade: at higher BTC prices, the previous minimum was unnecessarily expensive for denial-of-service protection purposes. The change allows sub-sat/vB transactions to propagate during quiet mempool periods, reducing costs for UTXO consolidation and other low-priority operations.

Why Mempool Congestion Drives Layer 2 Adoption

The fundamental constraint is arithmetic: Bitcoin produces roughly 144 blocks per day, each holding approximately 4,000 transactions. That is a hard ceiling of about 576,000 transactions daily. When inscription waves, market panics, or protocol launches push demand above this limit, fees spike and smaller transactions become uneconomical. The May 2023 BRC-20 wave saw the seven-day average hit 534,000 daily transactions, pushing the network to its practical limit.

Layer 2 protocols address this by moving the majority of transactions off-chain, only settling to Bitcoin L1 when necessary. The Lightning Network uses payment channels that require on-chain transactions only for opening and closing. Spark goes further by eliminating channels entirely: transfers happen by rotating key shares between participants, with no on-chain footprint for individual payments.

During the April 2024 fee spike, when priority on-chain transactions cost over $200, a Lightning or Spark transfer cost fractions of a cent. This price disparity makes the case for Layer 2 scaling more compelling with each congestion event. Users who transact frequently or in smaller amounts have a strong economic incentive to move activity off-chain, reserving the base layer for high-value settlement.

Predictable costs regardless of congestion: Spark transactions bypass the mempool entirely. Because transfers involve rotating cryptographic key shares rather than broadcasting on-chain transactions, the cost of a Spark transfer does not change when Bitcoin L1 fees spike. During the next congestion event, users with funds on Spark can continue transacting at near-zero cost while the base layer fee market sorts itself out.

The Economics of Block Space Going Forward

Bitcoin's mempool dynamics will continue to evolve as new protocol features and usage patterns emerge. The interaction between the declining block subsidy, growing demand from token protocols, and improving fee estimation tools will shape the user experience for years to come. Several trends are worth watching:

  • Cluster mempool in Bitcoin Core v31.0 will improve transaction selection efficiency, potentially reducing fee estimation errors and making congestion events more predictable
  • The reduced minimum relay fee enables a wider range of low-fee transactions during quiet periods, improving UTXO management opportunities
  • Token protocols like Runes and BRC-20 have established persistent demand for block space beyond simple value transfers, creating a new floor for fee revenue
  • Layer 2 adoption continues to reduce the number of transactions competing for base layer block space, easing congestion for those who need on-chain settlement

For developers building on Bitcoin, the practical takeaway is to design for fee variability. Use native SegWit or Taproot addresses, implement RBF signaling, support fee bumping via CPFP, and batch transactions where possible. For high-frequency or low-value use cases, integrate Layer 2 protocols like Spark to decouple your application from on-chain fee volatility. The Spark SDK documentation provides integration guides for wallets and payment applications. For a broader perspective on Bitcoin's scaling approaches, see our comparison of Layer 2 solutions.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.