Tools/Explorers

Bitcoin Mempool Size Tracker: Pending Transactions and Fee Pressure

Track Bitcoin mempool size, pending transaction count, fee rate distribution, and estimated confirmation times. Understand fee pressure and optimize transaction timing.

Spark TeamInvalid Date

What Is the Bitcoin Mempool?

The Bitcoin mempool (short for memory pool) is the holding area where every unconfirmed transaction waits before a miner includes it in a block. Each full node maintains its own mempool, so there is no single global queue: different nodes may have slightly different views of pending transactions depending on their configuration and network connectivity.

Mempool size is the primary indicator of network congestion on Bitcoin. When the mempool is small (under 1 vMB), every pending transaction fits in the next block and minimum fees are sufficient. When the mempool grows to tens or hundreds of vMB, a fee market emerges: users compete for limited block space by offering higher fee rates, and low-fee transactions can wait hours or even days.

Key Mempool Metrics

Understanding the mempool requires tracking several metrics simultaneously. No single number tells the full story.

MetricUnitWhat It Tells You
Mempool sizevMBTotal virtual size of all pending transactions. Directly comparable to the 1 vMB block weight limit.
Transaction countNumberHow many individual transactions are waiting. A high count with low vMB means many small transactions.
Fee rate distributionsat/vBBreakdown of pending transactions by fee rate bucket. Shows where congestion concentrates.
Minimum relay feesat/vBThe floor below which nodes reject transactions. Bitcoin Core v29.1 reduced this default from 1.0 to 0.1 sat/vB.
Dynamic minimum feesat/vBWhen the mempool exceeds 300 MB, nodes evict the cheapest transactions and raise this floor above the static minimum.
Blocks to clearNumberEstimated number of blocks needed to clear the entire mempool at the current inflow rate. One block clears roughly 1 vMB.

Mempool Size by Congestion Level

The mempool fluctuates dramatically based on user activity, protocol events, and market conditions. The following ranges reflect observed patterns from 2023 through mid-2026.

Congestion LevelMempool SizeTransaction CountNext-Block Fee RateLow-Priority Fee Rate
Empty<1 vMB2,000 - 10,0001 - 2 sat/vB1 sat/vB
Light1 - 10 vMB10,000 - 50,0002 - 10 sat/vB1 - 3 sat/vB
Moderate10 - 50 vMB50,000 - 150,0005 - 20 sat/vB2 - 5 sat/vB
Heavy50 - 200 vMB150,000 - 300,00020 - 50 sat/vB10 - 20 sat/vB
Extreme200+ vMB300,000 - 470,000+100 - 500+ sat/vB50+ sat/vB

Since mid-2025, the mempool has been frequently near-empty despite Bitcoin trading at or near all-time highs. Reduced metaprotocol activity (Ordinals, BRC-20, and Runes all declined from their peaks) is the primary factor. During these quiet periods, 1 - 6 sat/vB is sufficient for next-block confirmation.

Notable Congestion Events

Several events have pushed the mempool to extremes, each revealing how fee market dynamics play out under pressure.

May 2023 (BRC-20 minting frenzy): the mempool swelled past 500 MB with over 440,000 pending transactions. Fee rates hit 654 sat/vB for next-block confirmation. Bitcoin processed 682,281 transactions on May 8 alone, a single-day record. Weekly on-chain fees exceeded $100 million.

December 2023 (Ordinals inscription wave): approximately 383,000 unconfirmed transactions piled up, with average fees peaking at $38.43 on December 17. Fee rates reached roughly 385 sat/vB.

April 2024 (Runes protocol launch at the halving): block 840,000 earned 37.6 BTC in fees (approximately $2.4 million), the highest-fee block in Bitcoin history. Over 753,000 Runes transactions landed on April 23. Fees returned to normal within roughly 48 hours.

March 2025 (market correction panic): average fees spiked to $82.53 during an 18-hour panic selling period, then dropped to $3.27 within 30 hours as the wave subsided.

How Mempool Eviction Works

Bitcoin Core defaults to a 300 MB mempool limit. When the mempool exceeds this threshold, the eviction process begins:

  1. The transaction with the lowest fee rate, along with all its in-mempool descendants, is removed as a package.
  2. The node raises a dynamic minimum fee rate above minrelaytxfee, set to the evicted transaction's fee rate plus the incremental relay fee.
  3. New transactions below this dynamic floor are rejected outright.
  4. The dynamic floor decays slowly (halving over hours) once congestion subsides, preventing the mempool from immediately refilling with cheap transactions.

This package-based eviction prevents gaming: an attacker cannot protect a low-fee transaction by splitting it into many dependent pieces, because entire chains of unconfirmed transactions are evaluated together. For more on how mempool policy shapes the fee market, see our mempool policy reference.

Transaction Size by Address Type

The virtual size of a transaction directly determines its cost. Newer address formats produce smaller transactions because witness data is discounted at 0.25 weight units per byte compared to 1.0 for non-witness data. The following table shows a standard 1-input, 2-output transaction.

Address TypePrefixSize (vBytes)Fee at 10 sat/vBSavings vs P2PKH
P2PKH (Legacy)1...~226 vB2,260 satsBaseline
P2SH-P2WPKH (Nested SegWit)3...~165 vB1,650 sats~27%
P2WPKH (Native SegWit)bc1q...~141 vB1,410 sats~38%
P2TR (Taproot)bc1p...~154 vB1,540 sats~32%

For single-input transactions, P2WPKH is slightly smaller than P2TR because Taproot outputs are 12 bytes larger. However, P2TR inputs are the smallest of any type at 57.5 vB for single-sig key-path spends (vs ~68 vB for P2WPKH), so multi-input transactions like UTXO consolidations are cheaper with Taproot. For a deeper comparison of address formats and fee implications, see our address type fee savings tool.

Fee Estimation Strategies

Two fundamentally different approaches to fee estimation exist, and understanding when each excels is critical for optimal transaction timing.

History-Based Estimation (Bitcoin Core)

Bitcoin Core's estimatesmartfee RPC tracks confirmed transactions across exponentially-spaced fee rate buckets, measuring how many confirmed within a given block target. It uses three time horizons: short-term (18-block half-life), medium-term (144-block / ~1 day half-life), and long-term. This approach is robust against short-lived spikes but slow to react to sudden mempool changes, because it relies on historical confirmation data rather than the current mempool state.

Mempool-Based Estimation (mempool.space)

Mempool-based estimators analyze the current set of pending transactions in real time and project which ones miners will include in upcoming blocks. This approach updates every few seconds and is far more responsive to sudden fee spikes or drops. The mempool.space API returns five tiers: fastestFee (next block), halfHourFee (~3 blocks), hourFee (~6 blocks), economyFee, and minimumFee.

For most users, mempool-based estimation is more practical. For automated systems processing many transactions, blending both approaches can prevent overpaying during transient spikes while avoiding underpaying during sustained congestion. See our fee estimator tool for current recommended fee rates, and our research on fee estimation algorithm comparison for a technical deep dive.

Mempool Monitoring Tools

Several tools provide real-time and historical mempool data. The best choice depends on whether you need a quick fee check or long-term trend analysis.

ToolBest ForData ProvidedOpen Source
mempool.spaceReal-time fee estimation and transaction trackingFee tiers, projected block contents, transaction status, mining stats, block auditYes (AGPL)
Johoe's Mempool StatsHistorical fee pattern analysisStacked area charts by fee rate band, adjustable timespan, minute-level updatesYes
Bitcoin Core RPCProgrammatic access from your own nodegetmempoolinfo, getrawmempool, estimatesmartfeeYes (MIT)

mempool.space is self-hostable and available as a one-click install on node platforms like Umbrel and Start9. Running your own instance provides privacy (no third-party API calls) and ensures you see the same mempool view as your own node.

Optimizing Transaction Timing

Timing transactions around mempool conditions can save significant fees. Here are practical strategies:

  • Monitor the mempool before broadcasting. If the mempool is above 50 vMB and your transaction is not time-sensitive, wait for a quieter period.
  • Weekends and early UTC mornings tend to have lower fee pressure, as fewer businesses are broadcasting transactions.
  • Use Replace-By-Fee (RBF) to start with a low fee and bump it later if needed. This is the safest way to avoid overpaying during uncertain conditions.
  • Use CPFP to accelerate a stuck parent transaction by attaching a high-fee child that spends one of its outputs.
  • Consolidate UTXOs during quiet mempool periods (under 1 vMB) when fees are at their lowest. This reduces future transaction sizes and costs.
  • Use native SegWit or Taproot addresses to minimize transaction weight and reduce fees by 27-38% compared to legacy addresses.
  • Batch multiple payments into a single transaction using transaction batching. A batched transaction with 10 outputs is far cheaper than 10 separate transactions.

For users who want to avoid on-chain fee variability entirely, layer 2 protocols offer a way out. The Lightning Network enables near-instant payments with sub-satoshi fees for opened channels, and Spark enables off-chain Bitcoin and stablecoin transfers without requiring channel management, channel liquidity, or on-chain fee exposure for every payment.

Cluster Mempool: The Next Upgrade

Bitcoin Core merged the cluster mempool upgrade in November 2025, with the first release expected in Bitcoin Core 31.0. This upgrade replaces the existing ancestor-based transaction ordering with a cluster-based model that groups related unconfirmed transactions into clusters (capped at 64 transactions or 101 kvB per cluster).

The cluster mempool uses a spanning forest linearization (SFL) algorithm for optimal ordering within each cluster. The practical benefits include more accurate fee estimation, better eviction decisions when the mempool is full, and more efficient block template construction for miners. For users, this means fee estimators will become more reliable, and RBF fee bumps will be evaluated more accurately. See our research on cluster mempool mechanics for a full technical breakdown.

Frequently Asked Questions

How large is the Bitcoin mempool right now?

Mempool size changes continuously. Check mempool.space for real-time data. As of mid-2026, the mempool is frequently near-empty (under 1 vMB), meaning 1 - 6 sat/vB is typically sufficient for next-block confirmation. During congestion events, the mempool has historically exceeded 500 vMB with 400,000+ pending transactions.

What happens when the Bitcoin mempool is full?

Bitcoin Core nodes default to a 300 MB mempool limit. When this threshold is exceeded, the node evicts the lowest-fee-rate transaction (along with its descendants) and raises a dynamic minimum relay fee. New transactions below this raised floor are rejected. The dynamic floor decays slowly over hours once congestion subsides. Transactions that are evicted are not lost permanently: if the sender rebroadcasts them after fees drop, they can re-enter the mempool.

How do I check Bitcoin transaction fees before sending?

Use a mempool explorer like mempool.space to see current recommended fee rates across five priority tiers. Most wallets also provide built-in fee estimation. For programmatic access, use the mempool.space API or Bitcoin Core's estimatesmartfee RPC. Our fee estimator provides a quick overview of current rates.

Why is my Bitcoin transaction stuck in the mempool?

A transaction gets stuck when its fee rate is too low relative to other pending transactions. Miners prioritize transactions by fee rate (sat/vB), not total fee. If the mempool grew after you broadcast, your transaction may have been pushed down the queue. You can unstick it using RBF (if your wallet signaled it) to replace the transaction with a higher-fee version, or CPFP by spending one of the stuck transaction's outputs with a high fee.

How long do Bitcoin transactions stay in the mempool?

By default, Bitcoin Core drops transactions from the mempool after 336 hours (14 days) if they remain unconfirmed. However, transactions can be evicted earlier if the mempool exceeds its size limit and the transaction's fee rate is among the lowest. A dropped transaction can be rebroadcast at any time, potentially with a higher fee via RBF.

Does a larger mempool mean higher Bitcoin transaction fees?

Generally, yes. A larger mempool means more transactions competing for limited block space (roughly 1 vMB per block every ~10 minutes). This competition drives up the fee rate required for timely confirmation. However, the relationship is not perfectly linear: what matters is not just total mempool size but the distribution of fee rates among pending transactions. A 50 vMB mempool dominated by 1 sat/vB transactions creates less fee pressure than a 20 vMB mempool where most transactions are already at 10+ sat/vB.

What is the difference between sat/vB and sat/byte?

Before SegWit, fees were measured in sat/byte (satoshis per raw byte). After SegWit introduced the witness discount, fees are measured in sat/vB (satoshis per virtual byte). Virtual bytes account for the witness discount: witness data counts at 0.25 weight units per byte vs 1.0 for non-witness data. For legacy (pre-SegWit) transactions, sat/vB and sat/byte are identical. For SegWit and Taproot transactions, sat/vB is lower than sat/byte for the same raw transaction, reflecting the discount.

This tool is for informational purposes only and does not constitute financial advice. Mempool data is dynamic and varies between nodes. Fee rates, transaction counts, and congestion levels change continuously. Always check real-time mempool data before making transaction timing or fee decisions.

Build with Spark

Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.

Read the docs →