You submit a transaction from your wallet. The block explorer shows "pending." Minutes pass. Then an hour. Your transaction is not confirmed, not failed, not anywhere visible. Where did it go?
The answer is the mempool - the invisible layer between "transaction submitted" and "transaction confirmed" that most developers never think about until something goes wrong. During high-demand events like NFT mints, token launches, or sudden gas price spikes, the mempool becomes the bottleneck that determines whether your transaction lands in the next block or sits in limbo. Sandwich attacks, stuck transactions, and failed bids all trace back to mempool dynamics.
If you are building production blockchain applications, the mempool affects your gas estimation, transaction tracking UX, DeFi security, and infrastructure costs. This guide breaks down how mempools work across major chains, how to read them via RPC, and what your infrastructure choices have to do with it.
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:
- 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.
- 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 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.
- Valid transactions enter the node's local mempool. Invalid transactions are rejected immediately with an error.
- 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.
- Peers receive, validate independently, and re-broadcast to their own peers. The transaction ripples outward across the network within seconds.
- A block producer (miner or validator) scans their mempool and selects transactions for the next block, typically prioritizing by fee.
- The transaction is included in a block and confirmed on-chain. The block propagates to all nodes.
- 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.
Mempool Size Limits
Nodes do not hold transactions forever. When the mempool fills up, lowest-fee transactions get evicted.
- Geth defaults: 5,160 pending transaction slots, 1,024 queued transaction slots. Non-executable transactions (those with future nonces) expire after 3 hours.
- Bitcoin Core: 300 MB mempool size limit. Transactions expire after 14 days if not confirmed.
These are defaults. Node operators can configure different limits, which means two nodes can have different eviction thresholds - another reason why there is no single "the mempool."
Bitcoin vs Ethereum Mempool - Key Differences
The mempool concept is shared across chains, but the implementation details diverge.
The most consequential difference for developers is Ethereum's split between pending and queued pools. Ethereum transactions must execute in strict nonce order per account. If your account's next expected nonce is 5 and you submit nonce 7, that transaction enters the queued pool. It cannot execute until nonces 5 and 6 are filled. Pending transactions have contiguous nonces starting from the account's current on-chain nonce and are eligible for immediate inclusion.
Bitcoin's UTXO model avoids this problem entirely. Each transaction references specific unspent outputs as inputs. There is no concept of sequential ordering per address.
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.
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 Read the Mempool - RPC Methods for Developers
Monitoring the mempool is essential for gas estimation, transaction tracking UX, MEV detection, and DeFi protocol monitoring. These are the RPC methods that make it possible.
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 witheth_getFilterChangesto 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.
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, WebSocket is non-negotiable.
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.
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, BIP125) 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. The original transaction must have been flagged as replaceable (opt-in RBF) at submission time.
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 provides WebSocket endpoints across 50+ chains with transparent 1:1 pricing - no compute-unit multipliers that penalize subscription-heavy workloads.
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 is the layer between transaction submission and block confirmation that governs 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 infrastructure.
