What Is the Bitcoin Mempool? Congestion Explained Simply

The Bitcoin mempool is the holding area each node keeps for valid but unconfirmed transactions waiting to be mined. It is not one global queue: every node maintains its own mempool with its own size limit (Bitcoin Core default 300 MB), its own minimum relay fee (default 1 sat/vB), and its own eviction policy (source: GitHub). When aggregate demand exceeds the 4-million-weight-unit block supply, nodes drop the lowest-fee-rate transactions first and wallets raise their suggested sat/vB.

As of May 8, 2026, mempool.space reports the combined mempool at about 179 MB out of the default 300 MB ceiling, with roughly 49,300 unconfirmed transactions queued and the recommended fee rate at 1 sat/vB across all priority bands (source: Mempool.space). Difficulty is projected to adjust by about 1.33% in the next 221 blocks, so average block time is running at 10 minutes.

This guide is written for retail users sending BTC from a self-custody wallet or withdrawing from an exchange who want a concrete mental picture of what happens between "broadcast" and "confirmed," and why the same transaction can confirm in ten minutes one day and sit for six hours the next. It does not cover mining pool operations, Lightning channel gossip, or altchain mempool behavior. Every protocol constant here is cited to the source; every volatile number carries a May 8, 2026 date-stamp.

What you will learn:

• What the mempool is, where it lives on a node, and what separates "valid" from "confirmed"

• Why there is no single global mempool and how node-level variation actually looks in practice

• How congestion builds, and how Bitcoin Core's 300 MB cap plus dynamic minimum relay fee clear backlog

• How the sat/vB auction translates mempool pressure into a fee rate

• What happens when a transaction gets stuck, and the RBF, CPFP, or wait decision

• How to read mempool.space without overreacting to short-term noise

Protocol properties (block weight, mempool limits, relay fees, RBF signaling) are stable and cited to BIPs and Bitcoin Core documentation. Mempool size, fee bands, and backlog figures are live data with a May 8, 2026 snapshot.

What the Bitcoin mempool actually is

The Bitcoin mempool, short for memory pool, is the in-memory set of valid unconfirmed transactions each node holds before a miner includes them in a block. It is storage on a running node's RAM, not on disk, and not on the blockchain. When a wallet broadcasts a transaction, the receiving node checks the transaction against consensus rules and node-level policy, and if both pass, the node adds it to its mempool and relays it to connected peers (source: Bitcoin Dev Docs).

A transaction in the mempool has two properties beginners often conflate. It is valid (signatures check, no double-spend, inputs exist, fee meets the relay minimum), which is why nodes keep it. It is unconfirmed (no miner has yet included it in a block that the network accepts), which is why the sender's wallet still says "pending." Validity is a node-level decision; confirmation requires a miner and a block. A broadcast transaction can sit valid-but-unconfirmed for hours, be replaced by a higher-fee version, or be dropped from parts of the network, without ever becoming fraudulent.

Where the mempool lives on a node

A running Bitcoin Core node keeps its mempool in volatile memory, capped by the -maxmempool setting. The default cap is 300 MB, configurable down to a 5 MB floor (source: GitHub). When the node restarts cleanly, Bitcoin Core persists and reloads the mempool so users do not rebroadcast their pending transactions from scratch. When the node hits the cap, it starts evicting the lowest-fee-rate transactions first and raises its dynamic minimum relay fee to slow incoming low-fee traffic. The eviction threshold "continuously goes down, very slowly, halving every 3 to 12 hours" once congestion eases (source: Learn Me a Bitcoin).

What nodes check before accepting a transaction

Three layers of checks happen between broadcast and acceptance. Consensus rules are mandatory: valid signatures, inputs exist in the UTXO set, no double-spending, output sum not greater than input sum. Standardness rules are looser: Bitcoin Core defaults about what to relay: standard script types, no oversized transactions, fee above the minimum relay rate. Local mempool policy is what each operator configures: a custom -maxmempool, a custom minrelaytxfee, full-RBF acceptance on or off. A consensus-valid transaction can still be rejected by a specific node because it fails that node's local policy, which is one reason two explorers can disagree about a transaction's status.

Valid does not mean safe for the recipient yet. A zero-confirmation transaction can still be replaced under full-RBF or evicted from some nodes during a surge. That is why exchanges, Lightning node operators, and merchants wait for confirmations before crediting a deposit. Blofin's deposit flow treats a transaction as observed-but-provisional until it sits in a mined block and the required confirmation depth accumulates; the mempool visibility is an early signal, not a settlement event.

Why there is no single global mempool

Bitcoin is a peer-to-peer network of independent nodes, not a central server with one authoritative queue. Each node operator runs its own software build, configures its own memory limit, sets its own minimum relay fee, chooses which peers to connect to, and applies its own policy about replacement and eviction. Nodes share transactions via gossip, but the gossip is opportunistic: propagation is typically 10 to 30 seconds for well-connected nodes and slower for nodes at the edge of the topology (source: Learn Me a Bitcoin).

Two well-connected nodes on different continents can have noticeably different mempool contents at the same moment. A node in Singapore may have already seen and accepted a transaction that a node in São Paulo is still waiting to receive, and a node with a 5 GB mempool (-maxmempool=5000) may still hold a transaction that a default 300 MB node has already evicted. When a mempool.space big-node view shows 156.68 MB of data, that's one infrastructure operator's snapshot, not a global authoritative number; mempool.space explicitly runs both "Small Nodes" at the default limit and "Big Nodes" with larger limits so the dashboard captures traffic that would get rejected by stricter relay thresholds (source: Mempool.space).

How different node views usually look in practice

Propagation is efficient enough that mempool content across healthy nodes overlaps heavily, often well above 90% of visible transactions. But the last 5 to 20% of any given node's mempool is where node-level differences hide: dust-sweep transactions near the minimum relay fee, replaceable transactions, transactions that just hit the wire, and transactions that one operator's policy discarded. If your wallet says a transaction is pending but a specific explorer says it does not exist, the most common explanation is that the explorer's node has not yet received it or has already dropped it under local policy, not that the transaction is invalid.

What "no global mempool" means for fee decisions

Mempool charts are useful visibility tools, not oracles. They show strong signals about aggregate backlog, fee bands, and clearing pressure from a specific infrastructure operator's node set. For a retail user setting a fee, that's still more than enough signal to choose an appropriate rate. But when a dashboard shows "economy fee = 2 sat/vB" and your transaction is sitting unconfirmed at 1 sat/vB for six hours, the honest read is that your fee is below the current clearing price across most miners' mempools, not that one explorer is lying. For the chain-level distinction the mempool sits underneath, see bitcoin blockchain.

How a transaction moves from wallet to block

A Bitcoin payment passes through a specific sequence, not a single send action. Understanding the sequence explains almost every confirmation-timing question.

1. The wallet constructs the transaction: it picks UTXOs to spend as inputs, builds outputs for the recipient and change, signs each input, and derives the transaction size in virtual bytes.

2. The wallet broadcasts the signed transaction to one or more Bitcoin nodes (often the wallet provider's nodes, a user-run full node, or a public RPC endpoint).

3. The receiving node validates against consensus rules and its local policy. If anything fails, the node rejects and returns an error; if it passes, the node adds the transaction to its mempool.

4. The node relays the transaction to its peers via gossip. Peers apply the same checks, accept into their mempools, and relay onward.

5. Miners build candidate blocks from the transactions they see in their own mempools. Bitcoin Core's default block construction selects "by satoshis per adjusted vsize" Mempool.space, so higher-fee-rate transactions get included first.

6. When a miner finds a valid proof-of-work solution, they broadcast the block. Nodes validate it and, if accepted, remove its transactions from the mempool and add the block to their chain. The sender's transaction now shows 1 confirmation.

7. Additional blocks built on top add more confirmations. Most exchanges credit deposits at 3 to 6 confirmations depending on value and policy.

The mempool is the intermediate state between steps 3 and 6. Block explorers show the transition clearly: first "unconfirmed" with a fee rate and size, then "confirmed" with a block height and confirmation count. For a step-through of how to read that transition in an explorer, see how to use a bitcoin block explorer.

Why a transaction does not leave the mempool just because time passed

Transactions are not removed on a timer. They leave a node's mempool for exactly three reasons:

• Confirmation: a miner included them in a valid block that the node accepted

• Eviction: the node's mempool filled up and the transaction's fee rate was below the new dynamic minimum relay fee

• Expiry: the transaction sat unconfirmed for longer than -mempoolexpiry hours (Bitcoin Core default 336 hours, or 14 days, per DEFAULT_MEMPOOL_EXPIRY_HOURS in (source: Bitcoin Core)) and the node dropped it

An expired or evicted transaction is not invalid; it simply fell out of that node's memory. If another node still holds it, or if the sender rebroadcasts it, it can re-enter the mempool and still confirm. Proof of work determines when a transaction actually leaves the unconfirmed state and enters Bitcoin's permanent history; for how that mechanism secures the chain beneath the mempool, see what is proof of work.

How congestion builds and clears

Mempool congestion happens when valid new transactions arrive faster than the next blocks can clear them. Bitcoin blocks are capped at 4 million weight units (source: GitHub), which translates to roughly 1 to 1.7 MB of transaction data depending on the mix of address types and witness data. Blocks average one every 10 minutes, but real inter-block timing follows a probability distribution: it is common for three or four blocks to arrive in fifteen minutes, and equally common for a single block to take thirty or forty minutes. Short-run timing is noisy even when network demand is steady.

Congestion becomes visible when three things happen together: new transactions pile into the mempool faster than blocks remove them, wallet estimators detect the rising backlog and raise their suggested sat/vB, and users who need fast confirmation accept the higher rates. That auction mechanic lifts the clearing price. As of May 8, 2026 the mempool shows 49,300 pending transactions at 179 MB with recommended fees at 1 sat/vB (source: Mempool.space), a quiet afternoon by Bitcoin standards. The same screen can show 200,000+ pending transactions and recommended fees above 300 sat/vB during a major inscription mint or coordinated exchange batching event.

How Bitcoin Core's mempool limit drains a surge

When a node's mempool approaches its 300 MB cap, Bitcoin Core starts two behaviors that together act as a pressure relief valve. First, it evicts the lowest-fee-rate packages to free space for higher-fee-rate incoming transactions. Second, it raises its minimum relay fee dynamically: new transactions below the current threshold are rejected at the network layer, so they don't propagate and don't consume mempool space downstream. The threshold decays slowly once the cap is no longer pressured, halving roughly every 3 to 12 hours during normal operation (source: Learn Me a Bitcoin).

From a retail user's angle, this has a concrete consequence. A transaction broadcast at 1 sat/vB during a surge may never propagate past the first few nodes it reaches, because downstream nodes have raised their minimum relay fee above 1 sat/vB. The transaction is not invalid, but it is effectively invisible to most of the network and will not confirm until either the sender rebroadcasts it at a higher rate or the surge clears and the minimum relay fee decays.

Why congestion and fee spikes appear together but are not identical

Congestion is a backlog measurement: how many bytes and how many transactions are waiting. Fee pressure is a bid measurement: what sat/vB the marginal inclusion-bound transaction is paying. They correlate because a deep backlog pulls rates upward through the auction, but they can diverge briefly. A mempool stuffed with low-fee dust during a quiet period can have a large raw size but a calm next-block fee band, because miners skip the dust and include the modest-rate transactions. Conversely, a short but intense burst of high-fee transactions can spike fee bands for an hour without ever pushing the mempool size near the 300 MB cap.

The practical read: watch both numbers together. Total mempool size tells you how deep the backlog is; the fee-rate histogram tells you what rate you need to clear the next few blocks. For the full retail fee-market deep-dive, see why are bitcoin fees so high.

How the sat/vB auction actually works

Miners select transactions by fee rate, not by total fee. A small high-rate transaction confirms faster than a large low-rate transaction, even when the second pays more total satoshis. Bitcoin Core's block-building algorithm explicitly sorts "by satoshis per adjusted vsize" Mempool.space, including a package-aware variant that groups parent and child transactions so CPFP works correctly.

Fee rate is satoshis per virtual byte (sat/vB). Virtual bytes account for the SegWit witness discount under BIP-141: witness data counts as one weight unit per byte rather than four, so a SegWit or Taproot transaction occupies less block weight per raw byte than a legacy transaction and costs less to send at any given sat/vB (source: GitHub). Total fee equals sat/vB times transaction size in vB.

A worked comparison of rate versus total fee

Consider two transactions broadcast into the same mempool snapshot:

• Transaction A: 1 input, 2 outputs, native SegWit. Size about 141 vB. Fee rate 50 sat/vB. Total fee 7,050 satoshis.

• Transaction B: 20 inputs (a UTXO sweep), 2 outputs, native SegWit. Size about 1,380 vB. Fee rate 10 sat/vB. Total fee 13,800 satoshis.

Transaction B pays almost twice as much in absolute satoshis but confirms later than Transaction A, because miners grab A's 50 sat/vB rate and defer B's 10 sat/vB until blocks are processing lower bands. The auction is priced per unit of block-weight consumed, not per transaction.

What determines transaction size

Three drivers set vB count, independent of the BTC amount:

• Number of inputs: each spent UTXO adds script data. A clean 1-input send is compact; a sweep of 20 small UTXOs is roughly ten times larger.

• Number of outputs: each recipient and each change output adds data, though outputs are cheaper than inputs.

• Address type: legacy (1...) inputs are the largest, nested SegWit (3...) are smaller, native SegWit (bc1q...) are smaller still, and Taproot (bc1p...) is comparable to native SegWit for simple spends and more efficient for complex scripts.

The same $100 payment can cost $0.40 from a single clean UTXO or $4.00 from a pile of dust, at identical sat/vB rates, because the second version occupies ten times the block weight. That is why UTXO hygiene matters more than estimator cleverness for long-run average fees. For the UTXO primer, see UTXO management; for the complete address-type comparison, see Legacy vs SegWit vs Taproot.

What happens to stuck or low-fee transactions

An unconfirmed transaction whose fee rate is below the current clearing price is colloquially "stuck." It is not lost, rejected, or cancelled. It is valid and in a mempool somewhere, waiting for either a higher-paying block to include it, a mempool surge to pass so clearing prices drop, or a user action that changes its economics. Three outcomes are possible from that state.

Outcome 1: The transaction waits and eventually confirms

If the fee rate is low but above the minimum relay fee, and the sender is not in a rush, waiting is the simplest resolution. Mempool conditions oscillate with demand. A transaction broadcast at 5 sat/vB during a busy afternoon may sit for four or six hours while next-block rates are at 15 sat/vB, then confirm overnight as exchange batching slows and the clearing rate drops back to its normal band. Historically, the large majority of "stuck" retail transactions resolve by waiting; no fee change is required.

Outcome 2: The sender bumps the fee with RBF

Replace-By-Fee lets the sender broadcast a new version of the transaction paying a higher fee rate. The rules are defined in BIP-125 (source: GitHub). Since Bitcoin Core 24.0.1 (December 2022), node operators can set the -mempoolfullrbf option to accept replacement of any unconfirmed transaction, not only those that signaled BIP-125 opt-in; the default keeps the old opt-in behavior, but a growing share of the network enables full-RBF (source: GitHub). Most modern self-custody wallets (Sparrow, Electrum, BlueWallet, Green, and the hardware-wallet companions for Ledger and Trezor) sign RBF-signaling transactions by default.

RBF works when three conditions hold: the original transaction is replaceable (either BIP-125-signaling or the sender's node accepts full-RBF), the sender still controls the keys, and the new rate is meaningfully above current clearing (typically 25 to 50% above the next-block band). RBF is the wrong tool when the recipient has already treated the zero-conf transaction as settled, because the replacement can look like a double-spend attempt to a counterparty expecting the original.

Outcome 3: The sender accelerates with CPFP

Child-Pays-For-Parent spends one of the stuck transaction's outputs in a new high-fee child transaction. Miners score the parent+child pair as a package, so the package fee rate can outbid the next-block band even when the parent alone cannot. CPFP requires the sender or recipient to control at least one output (a change output or the recipient's output). If no one controls an output, CPFP is not available and the transaction must be waited out. Edge case: if the parent is very large in vB and the child is small, a practical child fee may not lift the package rate into the next-block band. For the detailed comparison, see RBF vs CPFP; for general triage, see why is my bitcoin transaction stuck.

Decision tree

Is the transaction urgent?
├── NO  → Wait. Rates usually drop within 6–24 hours.
└── YES → Was RBF signaled, or does my node accept full-RBF?
    ├── YES → Bump with RBF to the next-block band
    └── NO  → Do I control an output of the stuck transaction?
        ├── YES → Use CPFP so the package rate hits the next-block band
        └── NO  → Wait for congestion to clear, or contact the sending service
                  (exchange batching, custodial send) for their policy

What "dropped from the mempool" means

If a low-fee transaction sits unconfirmed past Bitcoin Core's 336-hour default expiry, it falls out of the node's memory. That does not burn the funds. Because the transaction never confirmed, the original UTXOs return to the sender's spendable balance. The practical workflow: open the wallet, confirm the inputs are spendable again, construct a new transaction at a higher fee rate, sign, broadcast. For a first-time walk-through of the full send flow, see how to send bitcoins.

How to read the mempool without overreacting

The tool most retail users and operators default to is mempool.space (source: Mempool.space). It visualizes pending transactions by fee rate, projects what fee rate is likely to clear in the next few blocks, shows current total mempool size, and displays the dynamic minimum relay fee across its small-node and big-node views.

A three-step method

• Step 1: check the combined mempool size (both bytes and transaction count). As of May 8, 2026 the dashboard reads 179 MB across 49,300 pending transactions (source: Mempool.space). That's mid-range: not empty, not stressed. A same-day read above 250 MB or 150,000 pending is meaningful congestion and a signal to slow down non-urgent sends.

• Step 2: read the fee bands. The recommended-fees widget shows next-block, 30-minute, 1-hour, and economy bands. On May 8, 2026, all four bands show 1 sat/vB (source: Mempool.space), historically unusual for Bitcoin but consistent with the current quiet period. During a surge, these bands separate sharply: next-block might be 80 sat/vB while economy hangs at 6 sat/vB, signaling that patience is worth four or five hours of waiting.

• Step 3: compare your wallet's suggested rate against the live bands. If your wallet is quoting 10 sat/vB for next-block when the live economy band is 1 sat/vB, your wallet is overestimating: safe but expensive. If your wallet is quoting 2 sat/vB for next-block when the live next-block band is 12 sat/vB, your wallet is behind a regime shift and your transaction will likely get stuck.

Why estimators lag during regime shifts

Wallet fee estimators calibrate on recent block data, recent mempool trends, or both. When network demand changes quickly (an inscription launch ramping up, an exchange starting its hourly batch, a coordinated sell-off), the wallet's model is calibrated to pre-surge conditions for 10 to 30 minutes while new data washes through. Users sending at the wallet's quoted rate during that window will underpay relative to the live clearing price and end up in the stuck bucket. The defense is checking live mempool data during known-busy windows rather than trusting a wallet estimator to be right in real time.

When BloFin's internal fee heuristics drive deposit-movement decisions, we read the live next-block band from multiple sources rather than a single estimator, precisely because the lag window bites hardest during the moments that matter most. Retail users with a single wallet estimator can replicate the discipline by keeping mempool.space open in a tab whenever they're sending during a known-busy hour.

A quick reference for what you see vs what to do

The two numbers that matter on the dashboard are total mempool size (how deep the backlog is) and the next-block to economy band spread (what rate you need). Everything else (per-pool inclusion patterns, accelerator auctions, UTXO age histograms) is useful for researchers but does not change the retail decision.

The mempool is a traffic map, not an emergency siren. Its job is to show pressure before a transaction becomes final, so users can decide whether to pay to cut the line or wait for the line to move. For the companion view of how a confirmation actually builds once a transaction clears the mempool, see bitcoin confirmations; for the broader send-safety checklist, see bitcoin security checklist.

Common mempool misconceptions

“Paying a higher total fee guarantees faster confirmation. 

Miners sort by fee rate (sat/vB), not total fee, so a small high-rate transaction beats a large low-rate one.

“High fees mean Bitcoin is broken.”

High fees mean scarce block space is under demand; the auction is the protocol working as designed.

“RBF lets you cancel a transaction.”

RBF replaces the transaction, it does not un-broadcast the original; the replacement is a new commitment to the network.

“Bitcoin Core expires mempool transactions to punish users.” 

The 336-hour expiry is a memory-management policy; the transaction stays valid and can be rebroadcast.

“A transaction "disappears" from mempool = lost funds.”

The UTXOs were never spent because no block confirmed the transaction, so they return to spendable state in the sender's wallet.

Future outlook for mempool conditions

There are currently three trends shaping the next few years of mempool behavior.

1. The block subsidy keeps tapering at each halving. After the April 2024 halving the subsidy dropped from 6.25 to 3.125 BTC per block (source: Blockchain.com), and at the 2028 halving it will drop to 1.5625 BTC. Miners increasingly depend on fee revenue for the long-run security budget, which means the fee market's role as Bitcoin's equilibrium mechanism grows structurally, not cyclically.

2. Off-chain payment rails continue to move volume away from the base layer. Lightning absorbs small and frequent payments between channel-connected users, and the routing-fee market for those transactions is measured in millisatoshis rather than sat/vB. Exchange-side batching has matured as well: most major regulated exchanges consolidate customer withdrawals into hourly or daily batch transactions, compressing on-chain demand without compressing user-visible throughput. For the Lightning primer, see what is lightning network.

3. Mempool visibility tools continue to improve. Multi-node dashboards, mempool-state APIs, and wallet integrations with live fee data have narrowed the estimator-lag window from 20-30 minutes a few years ago to 10-15 minutes today. The retail user who reads mempool.space during known-busy windows now has better signal than the average exchange backend had in 2020.

A reasonable expectation for 2026-2027 is continued alternation between quiet periods (next-block band in the 1-10 sat/vB range, similar to the May 8, 2026 snapshot) and spike events driven by inscription activity, exchange batching anomalies, and macro-driven market moves. The habits in this guide persist across both regimes: reading the live mempool before signing, preferring SegWit or Taproot, keeping UTXOs clean, and knowing the RBF and CPFP decisions.

Glossary

• Block space: the finite per-block capacity (4 million weight units under BIP-141); the supply side of the fee market

• Confirmation: inclusion of a transaction in a mined block that nodes have accepted; additional blocks built on top add confirmations

• CPFP (Child-Pays-For-Parent): accelerating a stuck parent by spending its output in a high-fee child so the miner scores the package favorably

• Dynamic minimum relay fee: a per-node threshold that rises when the node's mempool is near its cap and decays as the mempool drains

• Eviction: removal of the lowest-fee-rate transactions from a full mempool to make room for higher-rate new ones

• Fee rate: satoshis per virtual byte (sat/vB); the number miners compare when building blocks

• Gossip protocol: the peer-to-peer relay mechanism nodes use to propagate transactions to each other

• maxmempool: the Bitcoin Core configuration setting (default 300 MB) that caps the node's mempool size

• Mempool: the in-memory set of valid unconfirmed transactions each node holds before miners include them in blocks

• Mempool expiry: the node's time limit for unconfirmed transactions (Bitcoin Core default 336 hours / 14 days)

• Minimum relay fee: the lowest fee rate a node will accept and relay (Bitcoin Core default 1 sat/vB, configurable via minrelaytxfee)

• Propagation: the spread of a valid transaction across peer nodes; typically 10-30 seconds network-wide

• RBF (Replace-By-Fee): replacing an unconfirmed transaction with a higher-fee version under BIP-125

• Virtual byte (vB): size measurement accounting for the SegWit witness discount; 1 vB = 4 weight units non-witness or 1 weight unit witness data

• Weight unit (WU): the raw per-block capacity unit; 4 million WU per block under BIP-141

Frequently asked questions

Is there one global Bitcoin mempool?

No. Every Bitcoin node maintains its own mempool with its own size limit (Bitcoin Core default 300 MB), its own minimum relay fee (default 1 sat/vB), and its own eviction policy. Well-propagated transactions typically appear across most nodes within 10-30 seconds, so major mempool dashboards agree on the bulk of traffic. But the last 5-20% can differ, and a transaction visible to one explorer may not yet be visible to another. There is no single authoritative queue; there is a network-wide pattern emerging from many local pools.

Is the mempool part of the blockchain?

No. The mempool is an in-memory state on each running node, separate from the blockchain itself. A transaction in the mempool has been validated by at least one node and is waiting to be included in a block. Only after a miner includes it in a valid block that the network accepts does it move from mempool state to permanent blockchain state. That distinction matters because a mempool transaction can still wait, be replaced under RBF, or be evicted if its fee rate falls below the clearing price, without ever corrupting the chain.

Why does a crowded mempool usually mean higher fees?

A crowded mempool means many transactions are competing for the next few blocks of limited space. Wallet estimators detect the backlog and raise suggested sat/vB rates; users who need fast confirmation accept the higher rates; miners select highest-rate transactions first because they maximize revenue per byte of block weight used. Those three reactions together lift the clearing price. The mempool does not set fees by itself, but it makes the auction visible: congestion and rising fee pressure almost always appear together.

Can a transaction leave the mempool without being confirmed?

Yes. A transaction can leave a node's mempool three ways other than confirmation: the sender replaced it with a higher-fee version under RBF, the node's mempool filled up and evicted it as the lowest fee rate, or it sat unconfirmed longer than the node's expiry setting (Bitcoin Core default 336 hours / 14 days). Eviction and expiry do not invalidate the transaction; the inputs return to spendable UTXOs and the sender can rebroadcast at a higher fee rate. Verify current status through a block explorer or the wallet before treating a transaction as "gone."

Does the mempool tell me exactly when my transaction will confirm?

No. Block arrival follows a probability distribution around a 10-minute average, so short-run timing is noisy even with a fee rate well above the next-block band. New transactions can enter the mempool at any moment, shifting the clearing price mid-wait. Different nodes see slightly different backlogs. Mempool dashboards give good ranges ("next block with high probability," "within an hour," "economy") but not fixed arrival times. If the payment is genuinely time-critical, treat confirmation as probabilistic and set the fee accordingly.

What is the 300 MB mempool limit and why does it matter?

300 MB is Bitcoin Core's default maximum mempool size, controlled by the -maxmempool configuration setting. When a node's mempool fills up, the node evicts the lowest-fee-rate transactions first and raises its dynamic minimum relay fee to reject new sub-threshold traffic. This matters for retail because a transaction below the current dynamic minimum may not propagate past the first node that receives it. It is valid, but effectively invisible to most of the network until the mempool drains and the threshold decays.

What does it mean that Bitcoin Core supports full-RBF since version 24.0.1?

BIP-125 originally required a transaction to explicitly signal RBF opt-in to be replaceable. Bitcoin Core 24.0.1 (December 2022) added the -mempoolfullrbf configuration option, off by default, which lets node operators accept replacement of any unconfirmed transaction regardless of the BIP-125 signal GitHub. A growing share of the network has enabled full-RBF, so a retail user can often replace a stuck transaction even when the original did not signal opt-in. The practical effect: do not assume zero-confirmation transactions are safe to credit on the spot.

Why do different explorers sometimes disagree about my transaction?

Each explorer reflects one infrastructure operator's node view. Nodes differ in mempool size (a "big node" keeps transactions a default-sized node has evicted), in minimum relay fee (a node under congestion may reject what a lightly-loaded peer accepts), in peer connectivity (propagation can take 10-30 seconds to reach every corner of the topology), and in configured policy (full-RBF on or off, custom filtering). If your wallet shows pending and an explorer doesn't, the explorer's node has probably not received the transaction yet or has dropped it under its local policy, not that the transaction is invalid.

Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Factual claims independently verified against BIP-141, BIP-125, Bitcoin Core documentation at github.com/bitcoin/bitcoin (including reduce-memory.md and the 24.0 release notes), the Bitcoin Developer Guide at developer.bitcoin.org, live mempool.space data (snapshot 2026-04-16), learnmeabitcoin.com's memory-pool reference, and Blockchain.com subsidy data.

Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.