Skip to main content

Transaction pool

All nodes maintain a transaction pool to store pending transactions before processing.

Transaction pools are categorized into the following two types:

  • Layered - Recommended for public blockchain networks.
  • Sequenced - Recommended for private blockchain networks.

You can use specific options and methods to configure and monitor the transaction pool.


When submitting private transactions, the privacy marker transaction is submitted to the transaction pool, not the private transaction itself.

Layered transaction pool

The layered transaction pool is the default transaction pool implementation. The implementation separates the pool into layers according to value and executability of the transactions. The first layer keeps only the highest-value transactions that can feasibly go into the next block. The other two layers ensure Besu always has a backlog of transactions to fill blocks, maximizing the amount of fees.

Layered pools have additional parameters that allow you to limit and configure the number of transactions in different layers, enabling them to handle high volumes and sort transactions at a faster speed.

With the layered transaction pool, Besu produces more profitable blocks more quickly, with more denial-of-service protection, and using less CPU than with the legacy transaction pool.

If you previously configured transaction pool behavior, upgrade to the layered transaction pool by:

You can opt out of the layered transaction pool implementation by setting the --tx-pool option to sequenced.

Sequenced transaction pool

In the sequenced transaction pool, transactions are processed strictly in the order they are received. Although sequenced transaction pools lack the flexibility of layered pools, they help maintain a consistent and transparent transaction order, which is often useful in private blockchains.

You can select the sequenced transaction pool by setting --tx-pool=sequenced.

If you set the enterprise configuration profile using --profile=enterprise or --profile=private, the sequenced transaction pool is set by default.

The sequenced transaction pool suits enterprise environments because it functions like a first-in-first-out (FIFO) queue and processes transactions in the order of submission, regardless of the sender. When the pool reaches capacity, the newer transactions are evicted first, reducing the likelihood of a nonce gap and avoiding the need to resubmit older transactions.

Dropping transactions when the layered transaction pool is full

When the transaction pool is full, it accepts and retains local transactions in preference to remote transactions. If the transaction pool is full of local transactions, Besu drops the oldest local transactions first. That is, a full transaction pool continues to accept new local transactions by first dropping remote transactions and then by dropping the oldest local transactions.

Replacing transactions with the same sender and nonce

In networks with a base fee and priced gas

You can replace a pending transaction with a transaction that has the same sender and nonce but a higher gas price.

If sending a legacy transaction, the old transaction is replaced if the new transaction has a gas price higher than the existing gas price by the percentage specified by --tx-pool-price-bump.

If sending an EIP1559 transaction, the old transaction is replaced if one of the following is true:

  • The new transaction's effective gas price is higher than the existing gas price by the percentage specified by --tx-pool-price-bump AND the new effective priority fee is greater than or equal to the existing priority fee.

  • The new transaction's effective gas price is the equal to the existing gas price AND the new effective priority fee is higher than the existing priority fee by the percentage specified by --tx-pool-price-bump.

The default value for --tx-pool-price-bump is 10%.

In networks with zero base base or free gas

To enable replacing transactions in the transaction pool for zero base fee networks, or free gas networks:

Transaction pool methods and options

You can configure and monitor the transaction pool using the following methods, subscriptions, and options:

Methodtxpool_besuTransactionsAPI method to list transactions in the transaction pool.
Methodtxpool_besuStatisticsAPI method to list statistics of the transaction pool.
Methodtxpool_besuPendingTransactionsAPI method to list pending transactions in the transaction pool.
SubscriptionnewPendingTransactionsRPC subscription to notify of transactions added to the transaction pool.
SubscriptiondroppedPendingTransactionsRPC subscription to notify of transactions dropped from the transaction pool.
Option--tx-poolOption to specify the type of transaction pool to use.
Option--tx-pool-enable-save-restoreOption to enable save and restore functionality for the transaction pool.
Option--tx-pool-layer-max-capacityOption to specify the maximum memory capacity of the layered transaction pool.
Option--tx-pool-limit-by-account-percentageOption to limit the transaction pool by account percentage.
Option--tx-pool-max-future-by-senderOption to specify the maximum number of future transactions by sender.
Option--tx-pool-max-prioritizedOption to specify the maximum number of prioritized transactions.
Option--tx-pool-max-prioritized-by-typeOption to specify the maximum number of prioritized transactions by type.
Option--tx-pool-max-sizeOption to specify the maximum size of the transaction pool.
Option--tx-pool-min-gas-priceOption to specify the minimum gas price for transactions in the pool.
Option--tx-pool-no-local-priorityOption to disable local priority for transactions.
Option--tx-pool-price-bumpOption to specify the price bump percentage to replace an existing transaction.
Option--tx-pool-priority-sendersOption to specify sender addresses to prioritize in the transaction pool.
Option--tx-pool-retention-hoursOption to specify the number of hours to retain transactions in the pool.
Option--tx-pool-save-fileOption to specify the file for saving the transaction pool state.

The option --tx-pool-layer-max-capacity is applicable only for layered transaction pools.