Transaction Pool (Mempool)

The mempool is not a single server but a distributed network of unconfirmed transactions. Each node maintains its own version, validating transactions against consensus rules (e.g., valid signature, sufficient gas, nonce sequence). Invalid transactions are rejected and never propagate.

• Key Role: Acts as a buffer, decoupling transaction submission from block production.
• Propagation: Transactions are gossiped peer-to-peer across the network.

The mempool is a dynamic marketplace where users bid for block space using transaction fees. Miners/validators typically select transactions with the highest fee-per-gas or transaction fee to maximize revenue.

• Gas Auction: Users can increase fees to expedite confirmation during network congestion.
• Pending State: Low-fee transactions may remain in the pool for extended periods or be dropped.

Mempools have finite capacity. When full, nodes employ eviction policies to manage memory. Common strategies include:

• Fee-based eviction: Dropping the lowest-fee transactions first.
• Time-based eviction: Removing stale transactions after a timeout.
• Example: Bitcoin Core's default mempool limits to ~300 MB, which can hold tens of thousands of transactions.

The public visibility of pending transactions in the mempool creates opportunities for Maximal Extractable Value (MEV). Observant actors (searchers, validators) can exploit this by:

• Front-running: Submitting a transaction with a higher fee to execute before a visible pending trade.
• Back-running: Executing immediately after a known transaction (e.g., a large DEX swap).
• Sandwich attacks: Placing orders before and after a target transaction.

Not all mempools are identical. Differences arise from:

• Client Software: Geth, Erigon, and Nethermind for Ethereum have different default sizes and policies.
• Custom Filters: Nodes can implement bespoke rules to filter certain transactions.
• Network Topology: A node's connection peers affect which transactions it sees first, leading to mempool fragmentation.

Wallets and users query the mempool to estimate optimal transaction fees. By analyzing the density and fee rates of pending transactions, they can predict confirmation times. This creates a real-time fee market where users bid for block space.

• Example: A wallet scans the mempool, sees many high-fee transactions, and suggests a higher gas price to ensure timely inclusion in the next Ethereum block.

The public visibility of pending transactions in the mempool enables Maximal Extractable Value (MEV). Searchers run bots to scan for profitable opportunities, such as arbitrage or liquidations, and submit their own transactions with higher fees to be executed first.

• Common tactic: A sandwich attack where a sebot places orders before and after a victim's large DEX trade to profit from the price impact.

Individual nodes enforce local policies to manage their mempool and prevent spam. These policies define which transactions are accepted or rejected.

• Key policies: Minimum fee thresholds, maximum mempool size, and rules against nonce gap transactions.
• Purpose: Protects node resources and ensures network stability by filtering out invalid or resource-intensive transactions.

Different blockchains implement and utilize mempools in distinct ways based on their consensus and scalability designs.

• Bitcoin: A simple, unordered pool where miners typically select transactions by highest fee rate.
• Ethereum: A more complex pool that must consider gas limits and execution semantics for smart contracts.
• Solana: Uses a local fee-based queue system, as its high throughput requires rapid transaction forwarding and validation.

Censorship occurs when validators or block proposers deliberately exclude certain transactions from blocks. Attack vectors include:

• Governance-level censorship: A dominant validator or cartel refusing to include transactions from specific addresses (e.g., sanctioned entities).
• Time-bandit attacks: Reorganizing the chain to orphan blocks containing unwanted transactions.
• Mempool isolation: Network-level attacks where nodes refuse to propagate transactions, preventing them from reaching honest validators. This undermines network neutrality and permissionless access.

An attacker can attempt to Denial-of-Service (DoS) the network by flooding the mempool with low-fee, computationally expensive, or spam transactions. This aims to:

• Bloat the mempool size, causing node memory exhaustion and crashes.
• Increase network latency for legitimate users by forcing them to compete with spam.
• Exploit gas limits by filling blocks with junk, preventing real transactions from being included. Defenses include minimum fee requirements, transaction expiration, and DoS-resistant client implementations.

These attacks manipulate the standard transaction replacement mechanisms.

• Replacement Cycling: An attacker broadcasts a transaction with a higher fee, then repeatedly replaces it with new versions (bumping the nonce) to keep it at the top of the priority queue, effectively 'clogging' that account's sequence and blocking its legitimate transactions.
• Fee Bumping Griefing: A malicious actor can continuously outbid a victim's fee bumps on their own pending transaction, forcing the victim to pay exorbitant fees or have their transaction stuck. Protocols like EIP-1559 mitigate this by making fee estimation more predictable.

The public mempool is a major source of privacy leakage. Every pending transaction reveals:

• Wallet addresses and their associations.
• Trading intent and strategy before execution.
• Smart contract interactions and parameters. This enables sniping bots to copy trades or target vulnerable deployments. Solutions include private transaction relays (e.g., Flashbots Protect), encrypted mempools, and commit-reveal schemes that hide transaction details until they are included in a block.

Smart contracts that use block.timestamp or the presence of a transaction in the mempool as an oracle create attack surfaces.

• Timestamp Manipulation: Miners/validators have limited ability to influence the block timestamp, which can affect time-sensitive contracts.
• Mempool Griefing: An attacker can see a pending transaction that triggers a favorable contract state, then frontrun it with a transaction that changes the state negatively for the victim. This exploits the time delay between transaction broadcast and block inclusion, highlighting the danger of using mempool state as a trusted signal.

The journey of a transaction from creation to finality, with the mempool as a critical staging area. Key stages include:

• Creation & Signing: A user creates and cryptographically signs a transaction.
• Broadcast: The transaction is sent to a node and propagated across the peer-to-peer network.
• Mempool Staging: Nodes validate and hold the transaction in their local mempool.
• Block Inclusion: A miner/validator selects it for inclusion in a new block.
• Confirmation: The block is added to the canonical chain, finalizing the transaction.

In networks like Ethereum, users attach gas fees to incentivize miners/validators to include their transaction. The priority fee (or tip) is a critical component paid directly to the block producer on top of the base fee. Transactions with higher total fees are prioritized in the mempool and are more likely to be included in the next block, creating a competitive fee market.

The network participant responsible for creating the next block. This entity selects transactions from its view of the mempool, orders them, and executes them to form a candidate block. Their selection algorithm, which typically prioritizes transactions offering the highest fees, directly determines which pending transactions are cleared from the mempool.

A protocol mechanism that allows a user to replace a stuck transaction in the mempool by broadcasting a new transaction with the same nonce but a higher fee. This is used to accelerate a transaction that is being outbid by others. Not all blockchains support RBF; it is a configurable node policy, most notably available in Bitcoin (as a standard) and Ethereum (via transaction type).

Maximal Extractable Value (MEV) refers to profit that can be extracted by reordering, including, or censoring transactions within a block. Frontrunning is a common MEV strategy where a searcher sees a pending transaction (e.g., a large DEX trade) in the mempool and submits their own transaction with a higher fee to execute a profitable trade just before it. The mempool's public nature is essential for MEV activity.

There is no single global mempool. Each node runs its own mempool software (e.g., Geth, Erigon, Besu for Ethereum) with configurable policies on:

• Transaction validity rules
• Size limits and eviction policies
• Fee filtering and prioritization
• Peer-to-peer gossip protocols This leads to slight variations in which transactions different nodes see and relay, meaning the mempool state is eventually consistent but not perfectly synchronized.