What Is a Mempool? Meaning, Fees and Pending Transactions
A mempool is a node’s temporary collection of valid, unconfirmed transactions that have been accepted for possible inclusion in a future block.
The name comes from memory pool. When you send crypto, the transaction usually does not move directly from your wallet into the blockchain. It is first broadcast to the network, checked by nodes, and held temporarily while miners, validators, or block builders decide which transactions to include.
One important detail is often missed: there is no single global mempool shared by the entire network. Each node maintains its own view based on the transactions it has received and the policies it follows. Two nodes can therefore have slightly different mempools at the same moment.
A transaction appearing in a mempool also does not mean it is confirmed. It may later be:
- Included in a block
- Replaced by another transaction
- Dropped or evicted from a node’s mempool
- Rebroadcast to the network
- Delayed while other transactions compete for limited block space
The blockchain records transactions that have actually been included in blocks. The mempool shows a temporary view of transactions that may be included next.
How Does a Mempool Work?
A mempool sits between transaction broadcast and block inclusion: nodes check incoming transactions, temporarily store accepted ones, and relay them while block producers choose what to include.
A typical transaction moves through the network like this:
- Your wallet creates the transaction — It specifies the recipient, amount, network fee parameters, and other required data
- You sign it — Your wallet uses your signing authority to authorize the transaction
- The transaction is broadcast — It is sent to a node and typically propagated to other network peers
- Nodes check it — Each receiving node verifies relevant conditions such as signatures, available funds or spendable inputs, conflicts, and local transaction policies
- Accepted transactions enter local mempools — Nodes temporarily store transactions they are willing to keep and relay
- The transaction spreads across the network — Other nodes may independently accept it into their own mempools
- A block producer selects transactions — Selection depends on the network. Fees matter, but the exact rules differ between Bitcoin, Ethereum, and other blockchains
- The transaction enters a block — Once included, it is no longer merely pending
- Nodes remove the confirmed transaction — Their mempool state updates to reflect the new block
This process is more flexible than a normal queue. Transactions do not simply wait in first-in, first-out order. A transaction broadcast later may be confirmed earlier if it is more attractive to include or if network-specific rules give it higher priority.
Mempool acceptance is also different from blockchain consensus. A transaction can satisfy the network’s consensus rules while still not being stored or relayed by a particular node because of that node’s mempool policy, fee thresholds, resource limits, or conflicts with another pending transaction.
And although public mempools are the normal route for many transactions, they are not mandatory in every case. On Ethereum, for example, private transaction submission can send order flow directly to specialized builders or relays rather than exposing it to the ordinary public mempool.
So a transaction being “in the mempool” means at least one node has accepted it as a candidate for future inclusion. It does not guarantee confirmation, establish a fixed place in line, or mean every node on the network can currently see it.
There Is No Single Global Mempool
A blockchain network does not have one universal mempool; each node maintains its own local set of pending transactions.
When a transaction is broadcast, it propagates from node to node. Most nodes may eventually see it, but not necessarily at the same time — or at all.
Their mempools can differ because of:
- Propagation delays — A transaction may reach one part of the network before another
- Local fee policies — Nodes can reject transactions that fall below their relay or mempool thresholds
- Conflicting transactions — Different nodes may temporarily receive competing versions in a different order
- Resource limits — A full mempool can evict lower-priority transactions
- Node policy — A transaction can satisfy blockchain consensus rules but still fail a particular node’s relay or mempool requirements
This also means a mempool explorer does not provide an absolute list of every pending transaction on the network. It shows the view available to the nodes and infrastructure behind that service.
A transaction disappearing from one node’s mempool therefore does not necessarily mean it has disappeared everywhere. Other nodes may still store and relay it, and a wallet or node may broadcast it again later.
The useful mental model is not one giant waiting room, but thousands of overlapping waiting rooms that continuously exchange transactions with one another.
Bitcoin transactions do not wait in a node’s mempool forever. Bitcoin Core’s default configuration limits the mempool to about 300 MB and expires transactions after 336 hours, or 14 days. Both are node-policy settings, not blockchain consensus rules.
Why Do Transactions Get Stuck in the Mempool?
A transaction usually remains pending because block space is limited, its fee is not competitive enough, or another transaction or account dependency prevents it from being included.
The exact reason depends on the blockchain.
Low Fee or Fee Rate
When demand for block space rises, block producers generally favor transactions that are economically more attractive.
On Bitcoin, the important metric is usually the fee rate, measured in satoshis per virtual byte (sat/vB), rather than the absolute fee alone. A smaller transaction paying 3,000 sats can therefore be more attractive than a much larger transaction paying 10,000 sats if its fee rate is higher.
Network Congestion
A mempool can accumulate more transactions than upcoming blocks can hold. Lower-priority transactions then remain pending while higher-fee transactions are selected first.
Congestion does not mean the transaction is lost. It means demand for limited block space currently exceeds available capacity.
Nonce Gaps on Ethereum
Ethereum accounts send transactions in nonce order. If transaction nonce 15 is still pending, a later transaction with nonce 16 generally cannot execute first.
This can create a queue behind one stuck transaction even when the later transactions offer sufficient fees. Ethereum clients such as Geth distinguish between transactions that are immediately executable and those that remain queued because an earlier nonce is missing or pending.
Conflicting or Replacement Transactions
A wallet may broadcast another transaction that conflicts with or replaces the original one. Until nodes determine which version satisfies their replacement policies and one is eventually confirmed, explorers can show confusing pending or replaced states.
Mempool Policy and Resource Limits
Nodes do not have unlimited memory. During heavy congestion, a node can raise its effective minimum fee threshold and evict transactions that are less attractive to retain.
This creates an important distinction: pending does not necessarily mean “next in line,” and dropped does not necessarily mean “failed forever.”
A stuck transaction can eventually confirm when congestion falls, be replaced with a higher-fee version, be accelerated through another network-specific mechanism, or disappear from some mempools and later be rebroadcast.
How Mempool Fees Work: Bitcoin vs. Ethereum
Mempool congestion can affect how much users choose to pay for faster confirmation, but Bitcoin and Ethereum use different fee mechanisms and do not simply process the transaction with the highest absolute fee first.
Bitcoin: Fee Rate Matters More Than Total Fee
Bitcoin transactions compete for limited block space primarily through their fee rate, usually expressed in satoshis per virtual byte (sat/vB).
For example:
- Transaction A pays 10,000 sats but is 2,000 vB → 5 sat/vB
- Transaction B pays 3,000 sats but is 200 vB → 15 sat/vB
Even though Transaction A pays more bitcoin in total, Transaction B offers three times more fees for each unit of block space it consumes.
There is another layer: related Bitcoin transactions can be evaluated together. Bitcoin Core 31.0 introduced its new cluster mempool, which considers groups of connected parent and child transactions and orders them according to the fee rate at which the relevant group is expected to be mined.
For a normal user, the practical lesson is simple: Bitcoin confirmation speed depends on fee rate and block-space competition, not just the number of sats attached to a transaction.
Ethereum: Base Fee + Priority Fee
Ethereum uses a different model under EIP-1559. A typical transaction specifies:
- Base fee — Set automatically by the protocol and burned
- Priority fee — A tip that incentivizes validators to include the transaction
- Max fee — The maximum price per unit of gas the sender is willing to pay
The base fee rises when previous blocks use more gas than the network’s target and falls when usage is below the target. The priority fee helps a transaction compete for inclusion when block space is in demand.
This means the mempool does not directly set Ethereum’s base fee. It provides information about pending demand, while the protocol calculates the base fee from recent block utilization.
So “pay a higher fee to go first” is only a useful shortcut. The real mechanism depends on the network:
In both systems, paying more can improve the chance of faster inclusion, but no fee creates an absolute guarantee that a transaction will be confirmed in the next block.
What Can Happen to a Transaction in the Mempool?
An unconfirmed transaction can be included in a block, replaced, evicted, dropped, rebroadcast, or temporarily return to pending status after a blockchain reorganization.
The main outcomes are:
A replaced transaction is not the same as a failed transaction. On Bitcoin, current Bitcoin Core policy supports full Replace-by-Fee: a conflicting transaction can replace an unconfirmed one when it satisfies the required fee and mempool-policy conditions. Since Bitcoin Core 28, explicit opt-in RBF signaling is no longer required by the default Core policy.
Eviction is different. Nodes have finite resources, so during heavy congestion they may remove less competitive transactions from their local mempools. Bitcoin Core 31.0’s cluster mempool specifically redesigned transaction ordering, eviction, relay, and replacement decisions.
Most importantly, being dropped from one mempool does not mean a transaction was deleted from the blockchain. An unconfirmed transaction was never part of the blockchain in the first place, and other nodes may still have a copy.
That is why explorers can sometimes show statuses such as pending, replaced, dropped, or not found without any funds having permanently disappeared. The next step depends on whether the original transaction is still propagating, has been replaced, or can safely be rebroadcast or accelerated.
How to Speed Up or Replace a Stuck Transaction
A stuck transaction can sometimes be accelerated by replacing it with a more competitive version or by creating another transaction that gives block producers an incentive to confirm both.
The available method depends on the network and wallet.
Bitcoin: Replace-by-Fee
With Replace-by-Fee (RBF), an unconfirmed Bitcoin transaction is replaced by a conflicting version that pays a sufficiently higher fee.
Current Bitcoin Core policy supports full RBF, meaning replacement no longer depends on the original transaction explicitly signaling that it was replaceable. The replacement still has to satisfy Bitcoin Core’s fee and mempool-policy requirements.
Bitcoin: Child Pays for Parent
Child Pays for Parent (CPFP) takes a different approach. Instead of replacing the original transaction, someone spends one of its unconfirmed outputs in a new transaction with a high fee.
A miner may then include both because the combined fee rate makes the package worthwhile. Modern Bitcoin transaction selection increasingly evaluates these related transactions together rather than treating every pending transaction in isolation.
Ethereum: Replace the Same Nonce
Ethereum transactions from an account must execute in nonce order. A pending transaction can generally be replaced by broadcasting another transaction with the same nonce and sufficiently higher fee parameters.
A user can also attempt to cancel a pending Ethereum transaction by sending a new transaction with the same nonce, typically sending zero ETH back to their own address with more competitive fees. This does not erase the first transaction; it creates a competing transaction that must confirm first.
No acceleration method guarantees success. The original transaction may confirm before the replacement propagates, wallet support varies, and network policies determine which version nodes and block producers accept.
Bitcoin vs. Ethereum Mempools
Bitcoin and Ethereum both maintain pools of unconfirmed transactions, but their transaction models, fee systems, replacement mechanics, and ordering constraints differ substantially.
Ethereum’s account model creates a particularly visible difference. If an account has a pending transaction with nonce 15, a transaction with nonce 16 cannot simply skip ahead and execute first. Clients such as Geth therefore distinguish between pending transactions that can currently execute and queued transactions waiting for missing or unresolved nonce dependencies.
Bitcoin does not use account nonces. Instead, transactions spend previous transaction outputs, so dependencies arise when one unconfirmed transaction spends an output created by another.
The result is that “the mempool” is a useful general concept, but the behavior of a pending transaction depends heavily on the blockchain underneath it. A Bitcoin fee-rate problem and an Ethereum nonce problem can both appear to the user as the same simple status: Pending.
Mempools, MEV, and Front-Running
A public mempool can reveal a transaction’s intent before execution, giving bots and block-building participants an opportunity to react to it.
This matters most on smart-contract networks such as Ethereum. A pending DEX swap can reveal the assets, amount, slippage settings, and contract interaction before the transaction enters a block.
Specialized searchers monitor pending transactions for profitable opportunities. Ethereum.org notes that generalized front-running bots can watch the mempool, detect profitable transactions, and submit competing transactions with more attractive fees in an attempt to execute first.
The result can be worse execution and higher slippage for the original trader. Ethereum.org specifically identifies sandwich trading as a form of MEV that can worsen user execution.
Public visibility is also one reason private transaction routes exist. Services such as Flashbots Protect can keep transactions out of the ordinary public mempool and submit them through private block-building infrastructure, reducing exposure to some forms of front-running.
This creates an important exception to the basic mempool lifecycle: not every Ethereum transaction has to appear in the public mempool before being included in a block.
MEV is broader than malicious front-running. Arbitrage and liquidations can help keep DeFi markets functioning efficiently, while sandwich attacks and some ordering strategies can directly harm users. The key mempool lesson is that a pending transaction can be information — and that information may have economic value before the transaction confirms.
Private routing is already standard for some major wallet flows. Flashbots researchers reported in 2026 that MetaMask Swaps normally routes more than 99% of its user transactions through private mempools rather than exposing them to the public mempool.
How to Check the Bitcoin Mempool
A Bitcoin mempool explorer lets you inspect current congestion, fee rates, pending transactions, and estimates of which transactions may fit into upcoming blocks.
One of the most widely used tools is mempool.space. It visualizes its Bitcoin node’s mempool as a series of projected blocks: estimated future blocks appear before already confirmed blocks.
You can use it to check:
- Current congestion — How much unconfirmed transaction activity is waiting
- Fee-rate ranges — What fee levels are currently competing for block space
- Projected blocks — Which transactions the service estimates could fit into upcoming blocks
- Individual transactions — Search by transaction ID to inspect fee rate, size, status, and dependencies
- CPFP relationships — See effective fee rates for related parent and child transactions
- Recent confirmed blocks — Compare what was projected with what miners actually included
Projected blocks are estimates, not reservations. Mempool.space monitors its own mempool view and repeatedly runs a reimplementation of Bitcoin Core’s transaction-selection logic to estimate upcoming blocks; its projections can change as new transactions arrive.
You may also notice that fee-rate ranges overlap between projected blocks. A higher-fee transaction is not guaranteed to fit earlier if its size, dependencies, or other block constraints prevent it from fitting efficiently. Mempool.space specifically notes that lower-fee transactions can sometimes appear ahead of higher-fee ones for these reasons.
Most importantly, a mempool explorer shows one infrastructure provider’s view of the network, not a universal global mempool. Another node may have received a slightly different set of transactions at the same moment.
Mempool vs. Blockchain
The mempool contains transactions that may be confirmed in the future, while the blockchain records transactions that have already been included in blocks.
The distinction is simple:
A transaction therefore does not move “from the wallet into the mempool and then into the blockchain” as if these were physical storage locations. The wallet creates and signs the transaction, nodes temporarily keep copies while it is pending, and block inclusion records its effects as part of the blockchain.
The mempool itself also does not store coins or balances. If a Bitcoin transaction is pending, for example, the relevant UTXOs still exist according to the currently confirmed blockchain state even though wallets may display them as pending or reserved.
A useful way to think about the difference is:
The blockchain tells you what has happened. The mempool gives you a temporary, node-specific view of what may happen next.
Need a simple way to manage transactions across multiple networks? Atomic Wallet gives you self-custody control over your assets, with transaction details and status available directly in the wallet.
