Market Cap: $3.9288T 1.020%
Volume(24h): $156.854B -9.450%
Fear & Greed Index:

58 - Neutral

  • Market Cap: $3.9288T 1.020%
  • Volume(24h): $156.854B -9.450%
  • Fear & Greed Index:
  • Market Cap: $3.9288T 1.020%
Cryptos
Topics
Cryptospedia
News
CryptosTopics
Videos
Top Cryptospedia

Select Language

Select Language

Select Currency

Cryptos
Topics
Cryptospedia
News
CryptosTopics
Videos

What is a "mempool"?

The mempool holds unconfirmed cryptocurrency transactions until miners include them in a block, with fees and network demand influencing confirmation speed.

Aug 11, 2025 at 02:49 am

Understanding the Mempool in Cryptocurrency Networks

The mempool, short for memory pool, is a critical component of blockchain networks like Bitcoin and Ethereum. It acts as a temporary holding area for unconfirmed transactions that have been broadcast to the network but have not yet been included in a block. Every full node in the network maintains its own version of the mempool, storing transactions it has received and validated according to consensus rules. These transactions remain in the mempool until a miner or validator selects them for inclusion in the next block.

Each node independently decides which transactions to keep in its mempool based on criteria such as transaction fees, size, and validity. If a transaction fails validation—due to incorrect signatures, double-spending attempts, or insufficient funds—it will be rejected and not enter the mempool. The mempool is dynamic, constantly changing as new transactions arrive, old ones get confirmed, or some are dropped due to timeouts or fee thresholds.

How Transactions Enter the Mempool

When a user initiates a cryptocurrency transaction, it is digitally signed and broadcast across the peer-to-peer network. Nodes that receive this transaction perform several checks before accepting it into their local mempool:

  • Verify the digital signature to ensure the sender owns the funds
  • Confirm the inputs reference unspent transaction outputs (UTXOs) in Bitcoin or valid account balances in Ethereum
  • Ensure the transaction does not attempt to double-spend
  • Check that the transaction fee meets the node’s minimum relay fee requirement

Only after passing these validations will a node store the transaction in its mempool and propagate it to its peers. This decentralized validation ensures that only legitimate transactions spread across the network. The transaction hash (TXID) becomes the unique identifier used to track it during its time in the mempool.

Role of Miners and Block Inclusion

Miners or validators are responsible for selecting transactions from the mempool to include in the next block they mine. Their primary incentive is to maximize fees, so they typically prioritize transactions with higher fee per byte (Bitcoin) or gas price (Ethereum). This creates a competitive environment where users can increase their transaction fees to gain faster confirmation.

The selection process varies slightly between networks:

  • In Bitcoin, miners often use a fee-based priority system, sorting transactions by fee rate and including as many high-paying ones as possible within the block size limit (currently 4MB with SegWit).
  • In Ethereum, transactions are ordered by gas price, with higher-paying transactions processed first, especially during periods of high network congestion.

If a block becomes full, lower-fee transactions remain in the mempool, waiting for the next available block space. This leads to fluctuating confirmation times, particularly during peak usage.

Monitoring Mempool Status and Congestion

Users and developers can monitor the state of the mempool using various blockchain explorers and analytics tools. Websites like mempool.space (for Bitcoin) or Etherscan (for Ethereum) provide real-time data on:

  • Number of pending transactions
  • Average and minimum transaction fees
  • Estimated confirmation times
  • Mempool size in megabytes

High mempool congestion indicates that demand for block space exceeds supply, often causing delays. During such times, users may need to set higher fees to ensure timely processing. Some wallets automatically suggest optimal fees based on current mempool conditions, helping users avoid overpaying or underpaying.

Network upgrades like Bitcoin’s SegWit and Ethereum’s EIP-1559 have improved fee predictability and mempool efficiency. EIP-1559 introduced a base fee that is burned and a priority fee (tip) for miners, making fee estimation more transparent and reducing mempool bloat during volatile periods.

Transaction Expiry and Mempool Management

Transactions do not stay in the mempool indefinitely. Nodes apply eviction policies to prevent the mempool from growing too large and consuming excessive memory. Common rules include:

  • Dropping transactions with fees below a certain threshold
  • Removing transactions that have been in the mempool longer than a set time (e.g., 14 days in Bitcoin Core)
  • Evicting low-priority transactions when the mempool reaches its size limit (configurable, default is 300 MB in Bitcoin)

Some wallets support Replace-By-Fee (RBF), allowing users to replace a stuck transaction with a new one that pays a higher fee. Alternatively, Child-Pays-For-Parent (CPFP) lets a dependent transaction pay a high fee to incentivize miners to confirm its parent.

Nodes may also drop transactions if the referenced UTXOs are spent in another confirmed transaction, preventing double-spending attempts from lingering.

Impact of Mempool Dynamics on Users

Understanding the mempool helps users make informed decisions about transaction timing and fees. Sending a transaction during low network activity typically results in fast confirmations at lower costs. Conversely, during events like NFT drops or market volatility, the mempool can become saturated, leading to delays and higher fees.

Wallets that allow manual fee selection require users to assess current mempool conditions. Tools like fee estimators analyze the mempool to recommend fees that balance cost and speed. For time-sensitive transactions, paying a premium fee ensures rapid inclusion.

Developers building decentralized applications (dApps) must account for mempool behavior, especially when designing user interfaces that display pending transactions or estimate confirmation times.

Frequently Asked Questions

Can two different nodes have different mempools?

Yes. While most valid transactions propagate quickly, network latency and node policies can cause variations. Some nodes may reject low-fee transactions, while others retain them. This leads to slightly different mempool compositions across the network.

What happens to a transaction if it never gets confirmed?

If a transaction remains unconfirmed for too long, nodes will eventually remove it from their mempool due to expiration. The sender can then rebroadcast it with a higher fee or create a new transaction. The original funds become available again once the transaction is dropped.

Does the mempool store transaction data permanently?

No. The mempool is volatile storage. It only holds unconfirmed transactions temporarily. Once a transaction is included in a block, it is removed from the mempool. After a node restarts, its mempool is empty until it receives new transactions from peers.

Can a transaction be altered while in the mempool?

Not directly. A transaction’s data is immutable once broadcast. However, if the sender used Replace-By-Fee (RBF), they can broadcast a new version with a higher fee, which replaces the original in the mempool. Without RBF, the transaction cannot be modified.

Disclaimer:info@kdj.com

The information provided is not trading advice. kdj.com does not assume any responsibility for any investments made based on the information provided in this article. Cryptocurrencies are highly volatile and it is highly recommended that you invest with caution after thorough research!

If you believe that the content used on this website infringes your copyright, please contact us immediately (info@kdj.com) and we will delete it promptly.

Related knowledge

See all articles

User not found or password invalid

Your input is correct