Mempool
Pool of pending transactions awaiting inclusion in a block.
A mempool, short for memory pool, is a node's local collection of valid pending transactions that have not yet been included in a block. Nodes receive transactions from wallets and peers, validate basic rules, store eligible entries, and relay them. Block producers select from the transactions they can see.
There is no single global mempool. Network latency, peer connections, local policies, fee thresholds, and capacity make node views differ. A transaction may reach one provider but not another. Private order-flow systems can deliver transactions directly to builders without exposing them through ordinary public peer-to-peer propagation.
The mempool matters because pending transactions reveal user intent before settlement. Searchers simulate swaps, liquidations, NFT mints, and arbitrage opportunities. They may submit competing or surrounding transactions, creating MEV and potential sandwich attacks. Public visibility is useful for fee estimation and monitoring but creates execution risk.
Transactions can remain pending when fees are too low or when an earlier nonce from the same EVM account blocks later ones. Nodes may eventually drop old entries without any on-chain fee because they were never executed. A wallet can sometimes replace a transaction by submitting the same nonce with a sufficiently higher fee. A “cancel” is normally a replacement transfer, not deletion.
Bitcoin mempools use different transaction and fee-rate rules from Ethereum. Conflicting spends, ancestor limits, replacement policies, and data size affect acceptance. Applications should follow chain-specific behavior rather than assume pending queues work identically.
Users should preserve the transaction hash, check several sources, and inspect nonce and fee before retrying. Blindly resubmitting can create confusion or duplicate application actions on chains without suitable guards. Developers need idempotent workflows, pending-state expiration, replacement detection, and reorg handling. A mempool is a temporary network view, not proof of confirmation, execution success, or eventual inclusion.
Wallets should explain whether a transaction is locally created, broadcast, observed by peers, replaced, dropped, included, or finalized. Combining these states into “pending” makes troubleshooting unsafe. Node operators need limits because a flood of transactions can consume memory and bandwidth. Researchers analyzing mempools should account for geographic and peer-selection bias, since one observation point cannot see all public or private order flow.
Frequently asked questions
- The offered fee may be uncompetitive, an earlier account nonce may still be pending, the transaction may not have propagated, or the sender may lack funds for maximum cost. Network rules and node filters also matter. Check nonce, fee cap, balance, and provider status. A supported wallet can replace or cancel, but confirmation is not guaranteed.
- No. Each node maintains its own view based on received transactions, peer connections, validation policy, capacity, and local filtering. Private relays and builders receive order flow absent from public gossip. Transactions can appear on one explorer but not another. A blockchain reaches consensus on blocks, not on a single universal pending-transaction queue shared by every participant.
- Private RPC endpoints, protected relays, builder submissions, and intent or batch-auction systems can keep a transaction from ordinary public gossip before inclusion. This may reduce front-running and sandwich exposure, but adds trust, censorship, privacy, and availability assumptions. Verify the provider, understand fallback behavior, and still set minimum output or other execution limits in the transaction.