You broadcast a blockchain transaction—and then… nothing. The status says “pending,” confirmations don’t move, and you start wondering if something broke. Most of the time, nothing is wrong. Your transaction is simply waiting in a mempool: the “memory pool” each node keeps for unconfirmed transactions.
Once you understand how the mempool works, delays feel a lot less mysterious. You’ll know why fees matter, what “congestion” really means, and how to speed things up when timing is critical. Below is a practical, beginner-friendly explanation of what a mempool is, why it exists, why transactions get stuck, and what you can do about it.
Table of contents
- What a mempool is
- What a mempool is used for
- How a transaction travels to a block
- Why transactions stay in the mempool
- How long transactions can remain in the mempool
- How to “release” a stuck transaction
- How fees affect the mempool (and you)
- How to track transactions in the mempool
- Safety tips, common mistakes, and best practices
- Step-by-step: check status and speed up a transaction
- Final thoughts and what to do next
- FAQ
What a mempool is
A mempool (short for memory pool) is where a blockchain node stores unconfirmed transactions that are waiting to be included in a block. When you send crypto—on Bitcoin, Ethereum, or another chain—the transaction usually isn’t finalized instantly. Instead, it’s received by nodes, validated, and placed into their mempools as “pending.”
One key detail: there isn’t one single, global mempool for the entire network. Every node maintains its own mempool. Most mempools look similar because transactions propagate widely, but they’re not guaranteed to match perfectly. Nodes can also apply different mempool policies: how much memory they allocate, how long they keep unconfirmed transactions, and which transactions they evict first when space is tight.
That waiting period is not wasted. It gives nodes time to verify signatures, check that inputs are spendable, and reject conflicts before anything becomes part of an immutable block. In other words, the mempool is a normal (and important) stage in a transaction’s lifecycle.
What a mempool is used for
The mempool is often described as a waiting room, but it plays multiple roles that keep blockchains stable and secure.
1) A buffer between users and blocks
Blocks are limited in size and produced at set intervals. When transaction volume spikes beyond what the next block can hold, the mempool absorbs the overflow. Without this buffer, networks would struggle every time demand surged.
2) A filter and first line of defense
Before a transaction enters a node’s mempool, it’s checked against protocol rules: valid signatures, sufficient funds, and no conflicting spends. Invalid transactions are typically rejected immediately. This helps reduce double-spend attempts and keeps obvious “junk” from clogging the systеm.
3) A fee market
Inside the mempool, transactions compete for limited block space. Miners/validators typically prioritize transactions that pay more per unit of size or computation. That’s why two transactions sent minutes apart can confirm at very different speeds: the mempool behaves like a real-time auction for inclusion.
4) Decentralization and resilience
Because each node has its own mempool, there’s no single party controlling what stays or goes. Different nodes may evict low-fee transactions sooner or keep them longer. That independence improves resilience during congestion and reduces single points of failure.
How a transaction travels to a block
To understand where the mempool fits, it helps to follow a transaction’s path from “Send” to “Confirmed.”
1) Your wallet builds the transaction
Your wallet specifies the recipient, amount, and fee settings. On Bitcoin, fees are closely tied to transaction size (in bytes) and fee rate. On Ethereum, fees are based on gas: how much work the transaction requires and what price you’ll pay per unit of gas.
2) The transaction is broadcast to the network
Once signed, the transaction is shared across the peer-to-peer network. Nodes spread it using a gossip-like mechanism, passing new transactions to peers until the transaction is widely known.
3) Nodes validate it and add it to their mempools
Each node checks the transaction against the chain’s rules. If it’s valid, the node stores it in its mempool as “unconfirmed.” If it’s invalid, the node rejects it and does not relay it further.
4) A block producer selects transactions from the mempool
Miners (Proof-of-Work) or validators (Proof-of-Stake) build the next block by choosing transactions—often prioritizing the ones that pay better fees. In busy periods, lower-fee transactions may remain in the mempool longer.
5) The transaction is included in a block and confirmed
After the block is produced and accepted by the network, your transaction is confirmed. Nodes remove it from their mempools, and the queue advances for everyone else.
Why transactions stay in the mempool
If a transaction doesn’t confirm quickly, it’s usually because of congestion, fee settings, or dependencies.
Network congestion
Block space is limited. When more transactions arrive than the next blocks can fit, a backlog forms and the mempool grows. Confirmation times stretch, and recommended fees often rise accordingly.
Fees below the current market level
During congestion, block producers choose transactions that pay more. If your transaction’s fee is far below the current market range, it can sit in the “back of the line.” If a node’s mempool hits its memory limit, it may evict the lowest-fee transactions first.
Dependencies on other pending transactions
Sometimes a transaction depends on another unconfirmed transaction (for example, spending an output that hasn’t been confirmed yet). In that case, the child transaction can’t be confirmed until the parent is included. Some nodes keep these in special queues until the missing parent arrives.
Rare cases: chain reorganizations
Occasionally, a network can briefly reorganize recent blocks. A transaction that looked confirmed might temporarily return to the mempool until the chain settles. For users, it feels like confirmations “rolled back,” but it typically resolves quickly.
How long transactions can remain in the mempool
A transaction can stay in the mempool for seconds—or for days. In quiet periods, confirmation can happen in the very next block. On Bitcoin, a new block arrives roughly every 10 minutes on average, so “1 confirmation” is often quick when fees are reasonable.
During heavy traffic, the queue gets longer. Low-fee transactions may wait hours or longer. Also, nodes don’t keep unconfirmed transactions forever. Many node implementations have default expiration windows (Bitcoin Core is commonly referenced as keeping unconfirmed transactions on the order of about two weeks), and nodes also enforce mempool size limits. When space runs out, eviction policies usually drop the cheapest transactions first.
If your transaction gets evicted, it doesn’t mean funds were stolen or lost. It means the network never finalized that spend in a block—so you can resend the transaction with updated fee settings.
How to “release” a stuck transaction
If you don’t want to wait, there are practical ways to increase the odds your transaction gets included sooner. The exact method depends on the chain and your wallet features.
rеplace-By-Fee (RBF): resend with a higher fee
If your transaction was created as replaceable, you can broadcast a new version with the same intent but a higher fee. Nodes prefer the higher-fee replacement, and miners/validators are more likely to inсlude it quickly. In Bitcoin, a widely used standard for this behavior is described in BIP125 (reference: github.com/bitcoin/bips/blob/master/bip-0125.mediawiki).
Child-Pays-for-Parent (CPFP): use a high-fee child transaction
CPFP is useful when you control an output from the stuck transaction. You create a new “child” transaction that spends that output and attaches a high fee. Block producers may inсlude both parent and child together because the combined fees become attractive.
Ethereum: rеplace a pending transaction by nonce
Ethereum transactions from the same sender use a sequential nonce. If you send a new transaction with the same nonce but more competitive fee parameters (gas/priority), the network typically treats it as a replacement. Depending on what you send, it can cancel or supersede the previous pending attempt.
Do nothing and wait
Sometimes waiting is perfectly fine. If congestion eases, your transaction may confirm without changes. And if it’s evicted due to low fees, you can simply resend with updated parameters.
How fees affect the mempool (and you)
Fees are the main lever that determines how quickly your transaction moves through the mempool. When demand is high, the mempool behaves like a competitive market for limited block space.
Bitcoin: fee rate matters
On Bitcoin, miners often prioritize by fee rate (fee relative to transaction size), not just total fee. Two transactions can pay the same total fee, but the smaller one may confirm faster if its fee rate is higher. That’s why wallets often provide “economy / standard / fast” fee options based on current mempool conditions.
Ethereum: gas, base fee, and priority fee
Ethereum fees are paid in gas. After EIP-1559, the fee typically includes a base fee (burned by the protocol) and a priority fee (a tip to validators). In busy periods, the base fee rises, and you’ll need competitive total parameters to get included soon. Many wallets allow a max fee to cap how high you’re willing to pay.
A practical rule of thumb
If the transaction is urgent, align with current fee recommendations from your wallet and explorers. If it’s not urgent, you can choose a calmer fee setting—but be prepared for longer waits during traffic spikes.
How to track transactions in the mempool
To see what’s happening, you typically need the transaction hash (TXID) and a block explorer for the correct network.
Explorers and mempool monitors
For Bitcoin, tools like mempool.space and blockstream.info show mempool size, fee bands, and where your transaction likely sits in the queue. For Ethereum, etherscan.io is a common choice to view pending status, nonce ordering, and fee suggestions. For multi-chain tracking, people often use blockchair.com.
Your wallet UI
Many wallets surface these insights directly: “pending,” confirmation count, and sometimes a “speed up” button that increases fees using built-in mechanisms (often RBF or a similar approach).
Advanced topic: private mempools and MEV
Some ecosystems—especially around Ethereum—use private transaction delivery and bundled submissions. These can be relevant for advanced trading and MEV considerations, but most beginners only need the basics of the public mempool and fee dynamics.
Safety tips, common mistakes, and best practices
The mempool isn’t only about speed—it’s also about avoiding panic, overpaying, and scams.
1) Don’t panic when you see “pending.” Confirm the TXID in an explorer and compare your fee settings to current recommendations.
2) Use a wallet that supports fee management. RBF and built-in “speed up” features are extremely helpful when timing matters.
3) Avoid random fee guesses. In congested periods, being “slightly low” vs “way too low” can be the difference between minutes and hours.
4) Be careful with “transaction accelerator” offers. If a service asks for your seed phrase or wallet access, it’s almost certainly a scam. Legit acceleration typically happens via RBF/CPFP or nonce-based replacement on Ethereum.
5) Remember that popular standards still depend on network conditions. For example, USDT on TRC-20 is widely used, but confirmation speed and fees still depend on that network’s load and the transaction parameters you choose.
Step-by-step: check status and speed up a transaction
Here’s a simple, reliable checklist that works for most beginners—no guesswork required.
Step 1: find the TXID and the network
Open your wallet history and copy the TXID (transaction hash). Double-check which network you used: Bitcoin, Ethereum, Tron, etc.
Step 2: check the status in an explorer
Paste the TXID into a trusted explorer for that chain (for example, mempool.space for Bitcoin or etherscan.io for Ethereum). Confirm whether it’s visible and whether it’s pending or already in a block.
Step 3: compare your fee to current conditions
See how your fee settings compare to current recommendations. If you’re far below the market, confirmation may take much longer.
Step 4: look for a built-in “Speed up” option
Many wallets offer a one-click acceleration option. This is often the simplest route—your wallet handles the mechanics under the hood.
Step 5: use RBF if available
If your transaction was sent as replaceable, broadcast a replacement with a higher fee. The goal is to make your transaction more attractive to inсlude in the next blocks.
Step 6: use CPFP for chained situations
If you control an output from the stuck transaction, CPFP can help: a high-fee child transaction can pull the parent into a block as part of a package.
Step 7: if it’s not urgent, wait—or resend later
When congestion falls, pending transactions often confirm naturally. If the network evicts a very low-fee transaction, you can resend with updated parameters.
Final thoughts and what to do next
A mempool doesn’t mean your transaction is broken or lost—it’s a normal part of blockchain operation. The mempool holds pending transactions, gives nodes time to validate them, and creates a fair queue where speed depends on congestion and fees.
If a transfer is taking too long, follow a calm process: verify the TXID, compare fees to current conditions, and use RBF/CPFP (or nonce replacement on Ethereum) if you need faster confirmation. Once you understand the mempool, you can predict delays and respond confidently.
Swap BTC to USDT in minutes
Useful references (type in your browser):
- mempool.space
- blockstream.info
- etherscan.io
- blockchair.com
- github.com/bitcoin/bips/blob/master/bip-0125.mediawiki (BIP125 / RBF)
FAQ
Usually, no. A transaction can be evicted from some nodes’ mempools due to low fees or retention policy (time limits, memory limits). But if it never makes it into a block, the spend is not finalized on-chain, and you can resend the transaction.
Mempools are not global—each node has its own view. Explorers may connect to different nodes and refresh at different speeds, so their pending views can temporarily differ.
With a reasonable fee, many transactions confirm in the next block—about 10 minutes on average. During heavy congestion, confirmation can take longer, especially if your fee is below current recommendations.
Fee rate often matters more: fee relative to transaction size. Two transactions can pay the same total fee, but the smaller one can be prioritized if its fee rate is higher.
If your wallet supports RBF, you can broadcast a replacement with a higher fee. If RBF isn’t available, CPFP may help by creating a high-fee child transaction that encourages inclusion of both parent and child together.
Often, you can send a new transaction with the same nonce and more competitive fee parameters (gas/priority). This typically replaces the pending transaction and can speed up inclusion.
No. Eviction means a node stopped storing the unconfirmed transaction. If it wasn’t included in a block, the spend wasn’t finalized, so you can resend with updated fees.
Use your wallet’s fee suggestions and compare them with explorer fee levels. If it’s urgent, pay a competitive fee or use RBF. If it’s not urgent, choose a lower setting and accept that confirmation may take longer during spikes.
