Transaction Pool (Mempool)

Before entering the mempool, a node performs initial validation on each transaction. This checks for:

• Cryptographic signatures to verify authenticity.
• Sufficient balance to prevent double-spending.
• Correct format and size per network rules. Invalid transactions are rejected immediately, protecting the network from spam and malformed data.

The mempool is not a simple queue; it's a priority queue ordered primarily by transaction fee per unit of size (e.g., satoshis per virtual byte). Miners or validators select the highest-fee-paying transactions first to maximize revenue. This creates a fee market where users bid for block space, and transactions with insufficient fees may experience delays or be dropped.

A mempool has a finite size. When full, it employs eviction policies to manage capacity, typically removing the lowest-fee-rate transactions first. Its state is highly dynamic, fluctuating with network activity. Key metrics include:

• Mempool size in bytes or transaction count.
• Pending transaction count.
• Fee rate estimates for confirmation targets. Nodes may also implement transaction replacement policies (like RBF) allowing a sender to bump the fee of a stuck transaction.

Crucially, there is no single global mempool. Each node maintains its own independent mempool based on:

• Its specific connection graph to other peers.
• Locally configured policy rules (e.g., minimum relay fee).
• Propagation delays across the network. Therefore, transaction visibility and order can vary between nodes, making the system eventually consistent rather than perfectly synchronized.

For a miner or validator, the mempool is the source material for block construction. The proposer:

1. Selects transactions from their mempool based on fee priority and rules.
2. Attempts to fill the block's gas limit or block weight optimally.
3. Creates a candidate block and begins the proof-of-work or consensus process. This selection process directly links mempool dynamics to blockchain throughput and user experience.

The public visibility of pending transactions in the mempool enables Maximal Extractable Value (MEV) opportunities. Searchers and bots scan for profitable transactions (e.g., large DEX swaps) and may attempt to:

• Frontrun by submitting their own transaction with a higher fee to execute first.
• Backrun by executing an arbitrage transaction immediately after. This has led to specialized private transaction relays and MEV-Boost architectures in networks like Ethereum.

The mempool is the primary mechanism for a fee market. Users compete by attaching higher transaction fees to have their transactions prioritized by miners or validators. This creates a real-time auction where fees fluctuate based on network demand. Key dynamics include:

• Fee Estimation: Wallets analyze the mempool's pending transactions to suggest optimal fees.
• Fee Bumping: Users can replace a stuck transaction with a new one carrying a higher fee (via RBF or Child-Pays-For-Parent).
• EIP-1559: On Ethereum, a base fee is burned, and users add a priority fee (tip) for inclusion, making fee prediction more reliable.

Mempool design varies significantly across blockchains, affecting performance and security.

• Bitcoin: A simple, unordered buffer. Transactions are selected by fee rate (sat/vByte). Full nodes maintain individual mempools.
• Ethereum: A more structured pool, often separated into pending and queued sections based on nonce order. Clients like Geth and Erigon have configurable mempool logic.
• High-Throughput Chains (Solana, Avalanche): Often use a Gossip Protocol to propagate transactions quickly and may have shorter or more managed mempools to prevent spam.
• MEV-Boost: On Ethereum, searchers submit complex bundles of transactions directly to block builders, bypassing the public mempool.

The mempool is a vulnerable point in the network stack, targeted for several exploits.

• Frontrunning: Observing a pending transaction (e.g., a large DEX trade) and submitting a similar one with a higher fee to profit from the anticipated price impact.
• Denial-of-Service (DoS): Flooding the mempool with low-fee transactions to clog it and delay legitimate transactions.
• Mempool Sniping: In NFT minting, bots monitor for mint transactions and attempt to submit their own transaction in the same block.
• Time-Bandit Attacks: Miners could theoretically mine a secret chain and reorganize the blockchain based on profitable transactions seen in the mempool.

The mempool's state directly dictates the end-user's interaction with the blockchain.

• Transaction Stuck?: This means a transaction is broadcasted but languishing in the mempool due to a low fee. Wallets provide tools to accelerate or cancel it.
• Replace-by-Fee (RBF): A protocol allowing a sender to replace an unconfirmed transaction by broadcasting a new one with a higher fee and the same nonce.
• Accelerators: Services like ViaBTC or Flashbots' RPC endpoint allow users to submit transactions directly to mining pools for inclusion.
• Privacy Implications: Broadcasting to the public mempool exposes transaction details. Solutions like Taichi Network or Flashbots Protect offer private transaction routing.

For block producers, the mempool is a source of revenue and a resource to manage.

• Block Template Construction: Miners/validators select transactions from their view of the mempool to maximize fees while staying within block gas/size limits.
• Mempool Policies: Nodes set rules to limit mempool size, reject low-fee transactions, or filter certain transaction types to prevent spam.
• Orphaned Transactions: If a block is reorganized, transactions not included in the new canonical chain return to the mempool.
• MEV Extraction: Searchers pay priority fees (tips) to validators to include their profitable transaction bundles, making the mempool a source of Maximal Extractable Value.

Layer 2 and other scaling solutions fundamentally change mempool mechanics.

• Rollups (Optimistic & ZK): Transactions are submitted to a sequencer, which has its own mempool, before being batched and proven on Layer 1. This can reduce mainnet congestion.
• Private Mempools / Channels: Networks like Flashbots and Eden Network create private transaction channels to prevent frontrunning and extract MEV more efficiently.
• Subnets & Shards: In sharded or subnet-based architectures (Avalanche, Ethereum Danksharding), the mempool is distributed, reducing the global load on any single node.
• Future Research: Mempool-less designs or transaction ticket systems are explored to further mitigate spam and MEV issues.

Frontrunning is the practice of exploiting the visibility of pending transactions in the mempool to gain an unfair advantage. This is a primary source of Maximal Extractable Value (MEV). Attackers use bots to detect profitable pending transactions (e.g., large DEX swaps) and pay higher gas fees to have their own transaction included first, profiting from the price impact.

• Example: Seeing a large buy order for a token, a bot frontruns it, buying the token first and then selling it to the original trader at a higher price.
• Mitigation: Use private transaction relays or commit-reveal schemes to hide transaction intent.

The mempool's open nature allows nodes to replay or reorder transactions, which can be maliciously exploited.

• Replay Attacks: An attacker can copy a signed transaction from one network (e.g., Ethereum Mainnet) and broadcast it on another (e.g., a testnet fork), potentially draining funds if the same account exists on both chains.
• Reordering Attacks: Miners/validators can reorder transactions within a block to maximize their own profits via MEV, disrupting the expected execution order and causing failed transactions or worse prices for users.

Attackers can flood the mempool with low-fee or invalid transactions to deny service (DoS) to the network.

• Spam Flooding: Filling the mempool with transactions consumes node memory and bandwidth, slowing down network propagation and increasing latency for legitimate users.
• Griefing Attacks: An attacker can send transactions that appear to conflict with a victim's pending transaction (e.g., using the same nonce), causing one or both to fail, even if the attacker gains no direct profit. This increases costs and uncertainty.

Mempool transparency leads to significant timing and privacy leaks, revealing user behavior and strategy.

• Wallet Fingerprinting: The specific pattern of transactions from an address can deanonymize a user or entity.
• Strategy Exposure: Pending transactions from institutional traders or arbitrage bots reveal their market moves, allowing competitors to react.
• Sandwich Attacks: A specific frontrunning attack where the attacker places orders both before and after a victim's large trade, 'sandwiching' it for profit. This relies entirely on mempool visibility.

An Eclipse Attack isolates a specific node from the honest peer-to-peer network, feeding it a manipulated view of the mempool. The attacker connects to the victim node with many sybil identities and only relays selective transactions.

• Impact: The victim miner might include invalid or attacker-chosen transactions in their block, leading to orphaned blocks. A victim user might see incorrect gas prices or be tricked into signing malicious transactions based on false state data.
• Defense: Nodes use peer selection algorithms to resist sybil infiltration.

The mempool creates a real-time fee auction, which attackers can manipulate to destabilize the network or extract value.

• Fee Sniping: When a block reward is high, miners may ignore the current mempool and instead try to mine empty blocks or re-mine previous blocks with higher-fee transactions, undermining network throughput.
• PGA (Priority Gas Auction): Bots engage in automated bidding wars, rapidly outbidding each other for transaction priority, which can lead to extreme, unpredictable gas price spikes that harm regular users.