What Is a Mempool? How Transaction Pools Work in Blockchain

A mempool (memory pool) is the set of valid transactions that a node has received but that no block has included yet. Every full node keeps its own mempool in memory. Block producers pick transactions from it, usually highest fee first, to build the next block. When a block includes a transaction, nodes remove it from their mempools.

You submit a transaction from your wallet. The block explorer shows "pending." That transaction is in one or more mempools, waiting for a block producer to pick it. During NFT mints, token launches or gas spikes, more transactions arrive than blocks can hold, and low-fee transactions wait. Stuck transactions, sandwich attacks and failed bids all start here.

This guide covers how mempools work on Ethereum, Bitcoin, Solana, L2s and Hyperliquid, how big a mempool gets, how long transactions stay in it, and how to view it over RPC.

What Is a Mempool?

A mempool (short for "memory pool") is a node-local, in-memory data structure that holds valid but unconfirmed transactions. Every full node on a blockchain network maintains its own mempool. When you submit a transaction to a node, it validates the transaction and stores it in this buffer until a block producer picks it up for inclusion in the next block.

The key point: there is no single global mempool. Each node has its own independent view. Your transaction might exist in 10,000 nodes' mempools or just 3, depending on how far it has propagated through the peer-to-peer network. Two nodes can have completely different sets of pending transactions at any given moment.

The term varies by implementation. Geth (Ethereum's dominant execution client) calls it the "transaction pool" or txpool. Bitcoin Core uses "memory pool" or mempool. Either way, it is a waiting room for transactions that have passed initial validation but have not yet been included in a block.

The Transaction Lifecycle - From Wallet to Block

A transaction follows a specific path from the moment you click "confirm" in your wallet to block inclusion:

1. User signs the transaction in a wallet (MetaMask, Ledger, command-line client). The wallet applies the sender's private key to produce a cryptographic signature.
2. Transaction is submitted to a node via an RPC endpoint. This could be a public endpoint, a provider like Dwellir, or the user's own self-hosted node. The eth_sendRawTransaction production guide covers the errors a node can return at this step.
3. The node validates the transaction. It checks the cryptographic signature, confirms the sender has sufficient balance, verifies the nonce is correct (Ethereum) or the UTXO inputs are unspent (Bitcoin), validates the format, and confirms the fee meets the minimum threshold.
4. Valid transactions enter the node's local mempool. Invalid transactions are rejected immediately with an error.
5. The node gossips the transaction to connected peers via the P2P network protocol. On Ethereum, this is the devp2p wire protocol. On Bitcoin, it uses the Bitcoin P2P protocol.
6. Peers receive, validate independently, and re-broadcast to their own peers. The transaction ripples outward across the network within seconds.
7. A block producer (miner or validator) scans their mempool and selects transactions for the next block, typically prioritizing by fee.
8. The transaction is included in a block and confirmed on-chain. The block propagates to all nodes.
9. Every node removes the confirmed transaction from its mempool. The lifecycle is complete.

This process takes about 12 seconds on Ethereum (one slot), roughly 10 minutes on Bitcoin (one block), and under a second on high-throughput chains. But when demand outpaces block space, transactions can sit at step 4 for hours or days.

How Transactions Get Prioritized

Block space is limited. Ethereum produces roughly 15-30 million gas worth of transactions per block. Bitcoin blocks cap at about 4 MB (with SegWit). When more transactions enter the mempool than a single block can hold, block producers prioritize by fee.

Ethereum Fee Prioritization

Since EIP-1559 (August 2021), Ethereum uses a dual-fee mechanism:

• Base fee - Set by the protocol, not the user. Adjusts up or down by a maximum of 12.5% per block, targeting 50% block utilization. This portion is burned.
• Priority fee (tip) - Set by the user. Goes directly to the validator. Higher tips mean higher priority.

Validators maximize revenue by selecting transactions with the highest priority fees. When network demand surges, the base fee ramps up automatically, pricing out lower-value transactions. Your "stuck" transaction was competitive when you submitted it, but the base fee increased faster than your max fee allowed.

Bitcoin Fee Prioritization

Bitcoin uses a simpler model: fee rate measured in satoshis per virtual byte (sat/vB). Miners sort pending transactions by fee rate and fill blocks from the top. A transaction paying 50 sat/vB gets included before one paying 10 sat/vB.

How Big Is the Mempool?

There is no single number, because each node sets its own limits. The defaults are:

• Geth (Ethereum): 5,120 slots for executable (pending) transactions and 1,024 for future-nonce (queued) transactions. One slot is 32 KB, and a single transaction can use up to 4 slots (128 KB). Each account gets at least 16 pending and up to 64 queued slots. Blob transactions (EIP-4844) go to a separate, disk-backed blob pool. These values are in Geth's legacypool default config.
• Bitcoin Core: 300 MB of memory (-maxmempool). See mempool_options.h.

When a pool is full, the node evicts the lowest-fee transactions to make room. Operators can change all of these limits, so two nodes can hold different transaction sets. To see the current size of one node's pool, call txpool_status on Ethereum or getmempoolinfo on Bitcoin (it returns the transaction count, bytes and usage).

How Long Do Transactions Stay in the Mempool?

• Geth: a queued transaction (one with a nonce gap) is dropped after 3 hours by default (--txpool.lifetime). A pending transaction has no fixed expiry. It stays until a block includes it, you replace it with the same nonce, or a higher-fee transaction evicts it from a full pool.
• Bitcoin Core: an unconfirmed transaction is dropped after 14 days (336 hours, -mempoolexpiry), or earlier if the pool fills and its fee rate is too low.
• Solana: a transaction expires after about 150 slots (roughly a minute) if no leader processes it. See the Solana section below.

A dropped transaction is not cancelled. Your wallet or another node can broadcast it again, and it can still confirm later. To make sure it never executes, replace it (see Rescuing Stuck Transactions).

Bitcoin vs Ethereum Mempool - Key Differences

The mempool concept is shared across chains, but the implementation details diverge.

Pending vs Queued Transactions

The difference that matters most for developers is Ethereum's split between pending and queued transactions. Ethereum transactions must execute in strict nonce order per account.

• Pending: the nonces are contiguous from the account's current on-chain nonce. A block can include these now.
• Queued: there is a gap. If the account's next nonce is 5 and you submit nonce 7, nonce 7 waits in the queue. When nonces 5 and 6 arrive, the node moves 7 to pending.

txpool_status reports the two counts separately. A queued count that keeps growing for one sender usually means a nonce gap in that sender's code. For a production approach to nonce tracking, see Nonce and Mempool Monitoring for Builders.

Bitcoin's UTXO model has no such split. Each transaction spends specific unspent outputs, and there is no per-address sequence. A child transaction can spend an unconfirmed parent's output, so Bitcoin Core tracks parent and child chains in the mempool instead.

What About Solana? Chains Without a Traditional Mempool

Not every blockchain has a mempool in the traditional sense. Solana is the most notable exception.

Solana eliminates the mempool through its Gulf Stream protocol. Solana publishes a deterministic leader schedule (the validator sequence is known in advance), so clients forward transactions directly to the upcoming block leader rather than broadcasting to the entire network. The transaction goes straight to the validator responsible for producing the next block.

Transactions on Solana reference a recent block hash and expire after about 150 slots (roughly 1 minute) if unprocessed. The implications for developers:

• No indefinite queuing. Unprocessed transactions expire. They fail silently under load rather than sitting in a backlog for hours.
• Retry logic is mandatory. Your application must detect expired transactions and resubmit with a fresh block hash. No mempool holds your transaction in reserve.
• QUIC protocol for flow control. Solana replaced UDP with QUIC in late 2022 for more reliable transaction forwarding, adding congestion control at the transport layer.
• Stake-Weighted Quality of Service (SWQoS). 80% of a leader's inbound connection capacity is reserved for staked validators. Unstaked nodes and RPC providers compete for the remaining 20%. If your RPC provider runs staked validators, your transactions get preferential forwarding.

L2 Chains and Private Sequencers

Layer 2 rollups like Arbitrum, Optimism, and Base use centralized sequencers with private transaction queues, not traditional P2P mempools. The sequencer receives transactions directly, orders them, and posts batches to Ethereum L1.

If you are porting Ethereum mempool monitoring code to L2s, expect differences. Standard txpool_* methods and pending transaction subscriptions often behave differently or are unavailable on sequencer-based chains.

The Hyperliquid Mempool

Hyperliquid has a mempool of its own. Nodes gossip signed actions (orders, cancels, modifies, TWAP orders, transfers, leverage changes) to each other before a block includes them. They are requests, not results: the exchange can still reject an action, and some never reach a block.

Hyperliquid's public API shows an order only after a block includes it. Dwellir streams the mempool over gRPC (StreamMempoolTxs) from its Tokyo region. In a test on 29 October 2026, the stream showed 95.7% of 427,020 matched orders before the public WebSocket, with a median lead of 357 ms. Method, filters and replay window are in Hyperliquid Mempool Stream over gRPC.

MEV - How the Public Mempool Creates Opportunities and Risks

The public mempool is a transparent order book. Every pending transaction - its parameters, gas price, and intent - is visible to anyone running a full node. This transparency enables Maximal Extractable Value (MEV): profit extracted by reordering, inserting, or censoring transactions within a block.

Common MEV Strategies

Frontrunning occurs when a searcher (a bot monitoring the mempool) spots a profitable pending transaction - say, a large DEX swap - and submits an identical trade with a higher gas price. The searcher's transaction executes first, capturing the price movement.

Sandwich attacks are more aggressive. The attacker places a buy order before a victim's large swap (raising the token price), lets the victim's swap execute at the inflated price, and immediately sells. The victim receives fewer tokens than expected, and the attacker pockets the difference. In early 2025 alone, about $289 million was extracted through sandwich attacks.

Backrunning places a transaction immediately after a state-changing event to capture arbitrage - for example, a DEX trade that moves a price away from equilibrium on one exchange relative to another.

The Scale of MEV

MEV is not a niche concern. Roughly $3.2 billion in MEV was extracted on Ethereum in 2023. Around 90% of Ethereum blocks use MEV-Boost, a system implementing Proposer-Builder Separation where specialized block builders construct optimally ordered blocks and validators select the most profitable one.

Private Mempools as Mitigation

The primary defense against mempool-based MEV is bypassing the public mempool entirely. Flashbots Protect routes transactions directly to block builders, hiding them from searchers scanning the public pool. Over 2.1 million unique accounts use Flashbots Protect, with $43 billion in DEX volume shielded from sandwich attacks. More than 50% of Ethereum gas now originates from private or protected transaction channels.

Oracle price feed updates are a common MEV target. Searchers backrun oracle updates to arbitrage the price difference between on-chain and off-chain markets. For a deeper look at protecting smart contracts from these attack vectors, see Smart Contract Security Best Practices.

How to View the Mempool

For a quick look, a block explorer is enough. Etherscan has a pending transactions page for Ethereum, and mempool.space shows the Bitcoin mempool by fee rate. Both show what their own nodes see, not a global view.

For gas estimation, transaction tracking, MEV detection and DeFi monitoring, read the mempool from a node over RPC. These are the methods.

Geth txpool Namespace

Geth exposes a dedicated txpool namespace with three methods:

txpool_status returns the count of pending and queued transactions - the quickest health check for mempool congestion.

// Request
{"jsonrpc":"2.0","method":"txpool_status","params":[],"id":1}

// Response
{"jsonrpc":"2.0","id":1,"result":{"pending":"0x10","queued":"0x7"}}

txpool_content returns full details of every pending and queued transaction, organized by sender address and nonce. Useful for inspecting specific accounts or debugging nonce gaps, but the response payload can be large on busy networks.

txpool_inspect returns human-readable summaries of all pooled transactions. Lighter than txpool_content and better suited for dashboards and monitoring scripts.

Standard Ethereum JSON-RPC Methods

Standard Ethereum JSON-RPC methods also provide mempool access beyond the Geth-specific namespace:

• eth_newPendingTransactionFilter - Creates a filter that tracks new pending transaction hashes. Poll it with eth_getFilterChanges to receive batches of new hashes since the last poll.
• eth_getBlockByNumber("pending", true) - Returns a hypothetical "pending block" constructed from the current mempool state. Useful for gas estimation and previewing what the next block might contain.

WebSocket Subscriptions

For real-time monitoring, WebSocket subscriptions are the standard approach:

// Subscribe to new pending transactions via WebSocket
{"jsonrpc":"2.0","method":"eth_subscribe","params":["newPendingTransactions"],"id":1}

// Server pushes transaction hashes as they arrive
{"jsonrpc":"2.0","method":"eth_subscription","params":{"subscription":"0x1","result":"0xabc123..."}}

eth_subscribe("newPendingTransactions") pushes new pending transaction hashes to your client the moment the node receives them. No polling overhead, no missed transactions between intervals. Geth also accepts a second parameter, ["newPendingTransactions", true], which pushes full transaction objects instead of hashes, so you skip one eth_getTransactionByHash call per transaction.

Bitcoin Core RPC

• getmempoolinfo returns the transaction count, total size, memory use and the current minimum fee rate the node accepts.
• getrawmempool returns the txids in the pool. Pass true for per-transaction detail (fees, size, ancestors and descendants).
• getmempoolentry <txid> returns the detail for one transaction.

HTTP vs WebSocket

HTTP JSON-RPC works for one-off queries like checking txpool_status. Real-time mempool monitoring requires WebSocket connections. HTTP polling at 1-second intervals introduces up to 1 second of latency and wastes requests when no new transactions exist. WebSocket eth_subscribe pushes events as they happen, with sub-second delivery.

For gas estimation services, transaction tracking interfaces, and MEV detection systems, use WebSocket.

A Critical Caveat

The txpool_* namespace is Geth-specific. Not all RPC providers expose it. Infura, for example, has blocked txpool methods since 2018. When evaluating an RPC provider, verify it supports the mempool methods your application requires - especially if you are building transaction monitoring tools or custom gas estimation logic.

Rescuing Stuck Transactions

Transactions get stuck when the fee you set was competitive at submission time but the market moved.

Ethereum

On Ethereum, you rescue a stuck transaction by resubmitting a new transaction with the same nonce but a higher gas price. Geth requires at least a 10% increase in both maxFeePerGas and maxPriorityFeePerGas to accept a replacement. For blob transactions, the blob pool requires a 100% increase.

To cancel a pending transaction entirely, send a zero-value transfer to your own address using the stuck transaction's nonce with a high gas price. The self-transfer replaces the original, effectively canceling it (you pay the gas fee for the replacement but the original action does not execute).

Bitcoin

Bitcoin offers two mechanisms:

Replace-by-Fee (RBF) lets you rebroadcast a transaction using the same UTXO inputs but with a higher fee. The new transaction replaces the original in mempools that support RBF. BIP125 required the original to signal that it was replaceable (opt-in RBF). Since Bitcoin Core 28.0 (October 2024), nodes default to full RBF (mempoolfullrbf=1) and accept a higher-fee replacement whether or not the original signalled.

Child-Pays-for-Parent (CPFP) works from the recipient side. The recipient (or sender, using a change output) creates a new transaction that spends the unconfirmed output and attaches a high fee. Miners evaluate the combined fee rate of parent and child, and if the average is attractive enough, they include both transactions.

Why Your RPC Provider Choice Affects Mempool Access

The mempool is a live data source served by the node your application connects to. Your RPC provider determines what mempool data you can access and how quickly you receive it.

Method availability varies by provider. Not all providers expose txpool_status, txpool_content, or txpool_inspect. If your application depends on these methods, confirm support before committing to a provider. The Best Ethereum RPC Providers 2026 comparison covers method support across major providers.

WebSocket support is required for real-time streams. eth_subscribe("newPendingTransactions") only works over WebSocket connections. Providers that offer HTTP-only endpoints cannot support real-time mempool monitoring.

Latency affects MEV exposure. The faster your transaction reaches a block producer, the less time searchers have to frontrun it. Low-latency RPC endpoints reduce the window between your transaction hitting the public mempool and being included in a block.

Mempool monitoring generates high call volumes. Subscribing to pending transactions on Ethereum produces thousands of events per second. Providers that use compute-unit pricing often apply multipliers to WebSocket subscriptions and txpool methods, making mempool monitoring disproportionately expensive. Dwellir counts 1 response as 1 credit for every method, with no compute-unit multipliers on subscription-heavy workloads. Dwellir's Ethereum endpoints include HTTPS and WebSocket URLs.

Archive nodes serve historical query use cases. Mempool access requires full nodes with the txpool namespace enabled - a different infrastructure requirement that not every provider fulfills by default.

Conclusion

The mempool sits between transaction submission and block confirmation, and it decides fee dynamics, transaction ordering and MEV. Each node maintains its own independent view - there is no single global pool. On Ethereum, the pending and queued split means nonce management directly affects whether your transaction is eligible for inclusion. On Bitcoin, UTXO-based inputs and fee-rate sorting determine priority. On Solana, the mempool does not exist at all - Gulf Stream forwards transactions directly to the scheduled leader.

For developers, the practical takeaway: mempool access depends on your RPC provider. The txpool_* methods, WebSocket subscriptions, and low-latency connections that enable real-time transaction monitoring are not universally available. Check method support, confirm WebSocket availability, and understand the pricing model for high-volume subscriptions before building mempool-dependent features.

For teams building applications that depend on mempool data - whether for gas estimation, transaction tracking, or DeFi monitoring - explore Dwellir's RPC endpoints or contact the team to discuss dedicated node cluster infrastructure.