Transaction Pool Eviction

The most common eviction strategy, where transactions are ranked and removed based on a priority score. This typically combines:

• Transaction fee per unit of gas (e.g., Gwei)
• Transaction age (time in pool)
• Resource consumption (e.g., gas limit, calldata size) Low-fee, old, or resource-intensive transactions are evicted first to make room for higher-value ones.

Nodes enforce hard limits on pool capacity, triggering eviction when thresholds are exceeded. Key limits include:

• Total pool size in bytes (to constrain memory)
• Maximum number of transactions (e.g., 10,000 pending TXs)
• Per-account transaction caps (to prevent spam from single addresses) When a limit is hit, the lowest-priority transactions are purged until the pool is under capacity.

Transactions are automatically evicted after a predefined duration in the pool, known as their Time-To-Live. This prevents stale transactions from occupying space indefinitely. For example, a default TTL might be 3 hours. If a transaction isn't mined within that window, it is dropped and must be re-broadcast by the wallet, often with a higher fee.

The Replace-By-Fee (RBF) protocol allows a sender to broadcast a new transaction that replaces a prior unconfirmed one, typically with a higher fee. This can directly cause eviction:

• The original, lower-fee transaction is evicted from the pool.
• The new, higher-fee transaction takes its place. RBF is a user-initiated form of eviction that optimizes for fee market dynamics.

Eviction policies are a primary defense against Denial-of-Service (DoS) attacks that flood the pool. Key protections include:

• Banning accounts that send invalid or spam transactions.
• Rate-limiting incoming connections.
• Evicting transactions that fail initial validation checks (e.g., invalid nonce, insufficient gas). These rules ensure the node remains responsive for legitimate users.

Eviction logic is not standardized and varies significantly between node client software (e.g., Geth, Erigon, Besu). This leads to network-wide effects:

• A transaction evicted from one node's pool may persist in another's.
• Differences in pool sizing and priority algorithms can cause inconsistent transaction propagation.
• Miners/validators often run customized, more aggressive eviction policies to maximize fee revenue.

Transactions are evicted after exceeding a predefined Time-to-Live (TTL). This prevents stale transactions from occupying pool space indefinitely. For example, Ethereum nodes often drop transactions older than a set number of blocks or a specific timestamp. This is a primary defense against memory exhaustion from old, non-executable transactions.

Transactions from a specific sender are evicted if there is a nonce gap. Blockchain state transitions require sequential nonces. If a transaction with a nonce N is missing, all subsequent transactions from that sender with nonces >N are considered invalid for inclusion and are removed to free up pool capacity.

Nodes enforce a minimum acceptable gas price or priority fee. Transactions offering a fee below this dynamic floor are evicted. This floor often rises with network congestion, automatically clearing out low-fee transactions that are unlikely to be mined, ensuring the pool contains economically viable candidates.

Eviction is triggered when the total number of transactions or the pool's memory usage exceeds a hard cap. To make room for new transactions, the node removes the lowest-priority transactions, typically those with the lowest fee-per-gas. This is a critical mechanism for preventing resource exhaustion attacks.

To prevent a single account from spamming the pool, nodes may implement per-account limits. If an account submits transactions beyond its allotted slots, the oldest or lowest-fee transactions from that account are evicted. This ensures fair access to the transaction pool across many users.

Transactions that become invalid due to on-chain state changes are evicted. Common triggers include:

• Insufficient balance for the transaction's value + gas.
• Invalidated smart contract logic (e.g., a condition in the contract code that no longer passes). The node continuously validates pool transactions against the latest state.

Eviction policies are a primary defense against Denial-of-Service (DoS) attacks and spam. By removing low-fee or invalid transactions, they prevent the mempool from becoming a permanent storage for malicious traffic, ensuring the network can process legitimate transactions. This protects full nodes from resource exhaustion and maintains baseline network liveness.

The eviction logic directly shapes transaction lifecycle predictability. Aggressive eviction can lead to transactions being dropped, forcing users to re-submit. This uncertainty complicates fee estimation services, which must model not just inclusion probability but also the risk of eviction before confirmation, especially during periods of high congestion.

Eviction rules create a competitive arena for Maximal Extractable Value (MEV). Builders and searchers must strategize around the mempool's volatility:

• Transaction replacement: Strategies like Replace-By-Fee (RBF) can be used to prevent eviction.
• Private order flows: To avoid front-running and eviction risks, searchers send bundles directly to builders via private mempools or relays.

Application developers must build for eviction scenarios. Wallets implement features like:

• Automatic re-broadcasting of stuck transactions.
• Fee bumping interfaces (e.g., RBF, CPFP).
• Stale nonce handling to manage the chain of pending transactions if an earlier one is evicted.

For cross-chain bridges and atomic arbitrage bots, eviction introduces settlement risk. A transaction on one chain (e.g., initiating a bridge withdrawal) must be matched by a transaction on another. If one leg is evicted, the entire arbitrage or bridge operation can fail, potentially leading to funds being locked or lost opportunities.

Changes to eviction policy (e.g., size limits, fee thresholds) are non-trivial consensus parameters or client implementation details. Debates around these rules, such as increasing the mempool size, involve trade-offs between decentralization (node resource requirements) and usability, often requiring broad community coordination via Ethereum Improvement Proposals (EIPs) or similar governance processes.

A transaction fee is the payment, denominated in the network's native token (e.g., ETH, BTC), made by a user to compensate validators for processing and securing their transaction. It is the primary metric for transaction prioritization within the pool. Higher fees increase the likelihood of inclusion and reduce the risk of eviction during congestion.

Mempool flooding occurs when the network is inundated with a high volume of transactions, often from spam or arbitrage bots, exceeding typical processing capacity. This congestion:

• Drives up fee markets competitively.
• Triggers aggressive eviction policies as nodes reach memory limits.
• Can cause network-wide delays for low-fee transactions.

An orphaned or stale transaction is one that has been removed from all nodes' mempools without being included in a block. This can happen due to:

• Eviction after exceeding time or size limits.
• Being outbid by higher-fee transactions over a long period.
• Invalidated by a conflicting transaction (e.g., double-spend). Users must then rebroadcast it.

Fee estimation is the process by which wallets and users predict the optimal fee (gas price) required for timely transaction inclusion, based on current mempool conditions. Accurate estimation helps users avoid submitting transactions with fees so low they are immediately evicted or perpetually stuck. Methods include analyzing historical data and real-time mempool congestion.