Which transaction pool should a private Besu network use?
For a private network, Besu recommends the sequenced pool, selected with --tx-pool=sequenced. The layered pool is the default, but it is aimed at public networks, where many unknown senders submit transactions and the node has to handle arbitrary load and fee competition. A consortium or enterprise team running a permissioned chain usually has a known set of senders, so the sequenced pool is the better fit. Make this decision during design, before the first validator starts, because it is a node setting that every operator must agree on and it shapes how capacity and transaction ordering behave from day one.
The choice also changes which tuning options apply. The layered pool is limited by memory rather than transaction count, configured with --tx-pool-layer-max-capacity, and it replaces --tx-pool-limit-by-account-percentage with --tx-pool-max-future-by-sender. Teams that copy settings from a public-network guide or an older configuration file can end up with options that no longer match the pool they run. Before go-live, confirm which pool each node will use, check that its flags match that pool, and record the decision with the genesis and node configuration. The Besu transaction pool documentation lists the current options for each implementation.
Ask your Besu implementation partner or internal platform team to confirm three things in writing: the pool each node will run, the sender limits that match your onboarding model, and the test results from submitting your expected transaction volume to a staging network. Re-check these settings after each Besu upgrade, since pool options are part of the release notes you should review before moving to a new calendar version.
How the layered and sequenced pools differ
Besu ships two transaction pool implementations, and the option you pick changes how each node holds pending transactions and which settings you tune. The cards below compare them and flag the configuration points to review before you commit to one for a private network.
Layered pool is the default
The layered pool is the default and the option Besu documents for public networks. A node runs it unless you set the pool type, so private operators can inherit it without ever making a deliberate choice. Confirm in the docs for your Besu version which pool each node actually runs before you tune any pool setting, and record that answer in your configuration baseline.
Sequenced pool for private networks
Besu's documentation recommends the sequenced pool for private networks, and you select it with --tx-pool=sequenced. The setting belongs to each node, so every node you operate should carry the same value. Put the flag in your deployment templates explicitly, then ask the platform team to show it in the rendered configuration of each validator and RPC node.
Layered pool capacity follows memory
The layered pool is limited by memory, so the number of pending transactions it can hold depends on how much memory the node has set aside for the pool. The main capacity setting is --tx-pool-layer-max-capacity. Size node memory together with that value, and keep both in the same review so a memory change does not quietly shift pool behavior.
Per-sender limit options change
The layered pool replaces --tx-pool-limit-by-account-percentage with --tx-pool-max-future-by-sender. Any startup script, Helm value or Ansible variable that still sets the old key needs review after an upgrade or pool switch. The old option was expressed as a percentage, so confirm the unit of the new option before you copy a value across.
Confirm behavior for your version
Pool behavior, defaults and option names are documented per release, and Besu ships new versions roughly monthly. The topic documentation describes the current options, but your build may differ. Read the transaction pool page for the version you run, and review the release notes between your current version and the target before any change.
Test the switch before rollout
Changing the pool is a node configuration change, so it needs a restart and a controlled rollout. Test the switch on a non-production network with validator count and transaction submission patterns close to production. Compare pending transaction behavior under sustained load before you change the production configuration, and keep the previous setting ready for rollback.
Transaction pool options and when each fits
This table compares the pool selection flag, the capacity settings and the per-sender limit across the sequenced and layered pools. Read each row as a setting that either stays the same or changes depending on which pool you select. The main takeaway is that the sender limit and capacity options are not interchangeable between the two pools, so confirm each flag in your release before you carry settings over.
| Option | Sequenced pool (private networks) | Layered pool (default) |
|---|---|---|
| Selection flag | Set with --tx-pool=sequenced, the recommended choice for private networks | Default when no pool flag is set, recommended for public networks |
| Capacity control | Capacity settings apply to the sequenced pool; confirm the exact option names in your release | Limited by memory rather than transaction count through --tx-pool-layer-max-capacity |
| Per-sender limit | Account percentage limit (--tx-pool-limit-by-account-percentage) is the setting to review; confirm whether it applies in your release | Replaces the account percentage limit with --tx-pool-max-future-by-sender |
| Sizing driver | Transaction count and sender behavior on a small, known set of participants | Available memory on each node, since the layered pool is bounded by memory |
| Fit for a private network | Usually the better match when participants are known and transaction volume is predictable | Chosen when you want the public-network default behavior or are following generic guidance |
| What to verify before go-live | Flag spelling, the per-sender setting and behavior under a test load in your release | Memory headroom on every node and the per-sender value you set in place of the old percentage limit |
| Change when switching pools | Reapply pool settings on every node, because the option set differs | Remove the account percentage flag from configuration files, since the layered pool does not use it |
Setting up the sequenced pool on a private network
This sequence moves the transaction pool choice from a design decision to a tested, versioned configuration that behaves the same way on every node. It ends with a staging proof and a record your operators can reproduce.
Decide the pool during network design
The network architect records the transaction pool choice in the design document alongside genesis settings, validator count and node roles. For a private network the Besu documentation recommends the sequenced pool, selected with the --tx-pool=sequenced option, while the layered pool is the default and is aimed at public networks. Confirm with your architects whether any node in the design will run a different pool, because that choice must be made once and applied everywhere. Done when the design record names the pool, the reason for it and the owner of the decision.
Map every node that accepts transactions
The platform team lists each Besu node that receives transactions from applications, wallets or other participants, including validators, RPC nodes and any relay or bootnode that forwards submissions. Each entry records the node's configuration file and how it is started, whether by systemd, a container image or a Kubernetes manifest. Mixed pool settings across these nodes make ordering and capacity behavior hard to explain, so the inventory is the baseline for the next step. Done when the inventory has one row per node and each row names the file that controls its startup options.
Set the pool option on every node
The platform engineer adds tx-pool="sequenced" to the configuration of each node in the inventory, or passes --tx-pool=sequenced at startup, and changes the setting in the same change window across the network. Mixed settings are the main source of confusion, so the change is reviewed as one pull request rather than node by node. Restart each node in the agreed order and confirm the startup log shows the sequenced pool being used. Done when every node in the inventory reports the same pool in its startup output.
Adjust capacity and per-sender limits
The sequenced pool does not use the layered pool's memory-based setting, so capacity planning moves to the settings the sequenced pool documents. Review the transaction pool page of the Besu documentation for the options that apply to your release, and confirm them against the version you run before editing values. Set limits that match the expected number of senders, the volume of pending transactions and the memory available on each node. Record why each value was chosen so later tuning has a starting point. Done when each limit has a stated value, a reason and a confirmed option name for your Besu version.
Test submission and ordering on staging
The test engineer runs a staging network with the same pool settings and submits transactions from several test accounts at once, including bursts that approach the per-sender limit. The test checks that transactions are accepted, that nonces are processed in the expected order, and that a transaction with a gap in its nonce waits rather than being dropped or executed early. The engineer also restarts one node during the burst to confirm the pool recovers after a restart. Done when the test results show accepted, ordered and recovered transactions, and any surprising behavior is logged as a defect before go-live.
Compare staging behavior with the design record
The architect checks the staging results against the design record and the capacity notes from the earlier step. Any value that did not behave as expected is corrected, retested and linked to the change that fixed it. Ask your Besu support channel or the documentation maintainers to confirm any behavior you cannot reproduce from the docs, rather than assuming it. Done when the design record and the staging report agree on pool choice, limits and observed ordering.
Store the configuration in source control
The platform team commits the final node configuration, the pool option, the capacity values and the staging test scripts to the same repository as the genesis file and deployment manifests. Each change is reviewed, tagged with the Besu version it was tested against and linked to the design record. Any future Besu upgrade reruns the staging test before the pool setting is carried forward. Done when a new engineer can rebuild every node's pool configuration from the repository and the tagged staging report.
Trade-offs to weigh before go-live
The first decision is which pool to run, and for a private network the sequenced pool is the option Besu documents as the recommendation. The layered pool is the default and is aimed at public-network behavior, where many unknown senders submit transactions and the node must judge them by memory use rather than by a fixed count. A consortium chain usually has a known set of senders, so the sequenced pool is the better fit for most teams. Confirm the choice in the Besu transaction pool documentation for the release you will deploy, because defaults and option names change across calendar releases, and set it explicitly with --tx-pool=sequenced so the setting is visible in your configuration file under source control.
Switching pools also changes how you size and limit senders. The layered pool is bounded by memory through --tx-pool-layer-max-capacity and uses --tx-pool-max-future-by-sender in place of --tx-pool-limit-by-account-percentage. Any runbook, Ansible role or Kubernetes manifest that still sets the older option will need review before you move between pools, and a test on a non-production node should confirm that the limits you expect are the limits the node enforces. Ask your platform or client team to document, for each node role, which pool is active and which capacity and sender settings apply to it, so that validators and non-validating nodes are not configured on different assumptions.
The pool choice also shapes how you test and troubleshoot dropped transactions. A transaction that disappears from one node may be evicted for a capacity or per-sender reason that differs between pools, so your test plan should submit nonce gaps, bursts from a single account and traffic at the capacity limit, then record which node reports what. Keep the pool setting in every node's logs and monitoring labels so an incident responder can tell which behavior applies. Before go-live, agree in writing who owns pool configuration changes and who re-runs this test after each Besu upgrade, since a release can alter defaults that your current settings depend on.
Operational risks of the pool choice
The pool setting is only as safe as its consistency across the network, its behavior under load and the record that explains why it was chosen. The cards below cover the checks that connect those concerns for a private Besu network.
Keep pool settings identical
Validators, RPC nodes and any other node that accepts transactions should run the same transaction pool implementation and limits. A node on a different pool can accept or hold transactions that its peers handle differently, which makes behavior depend on which node a client happens to query. Review the node configuration files as a set before each change and confirm that the --tx-pool setting matches on every node. Check this again after any node is rebuilt or added.
Flooding from a single sender
Pool limits decide how much a single account can queue before its transactions are rejected or displaced. In a private network with a small set of known senders, one misbehaving application or a retry loop can fill the pool and delay other participants. Under the layered pool, the sender limit is set through --tx-pool-max-future-by-sender, and under the sequenced pool the per-account behavior differs. Test a burst from one account in your environment and confirm that other accounts still get transactions included.
Monitor pool metrics in Prometheus
Besu exposes metrics for Prometheus when --metrics-enabled is set, on port 9545 by default. Pool size, rejected transactions and transaction age are the signals that show a pool problem before users report it. Scrape every validator and RPC node, not only one entry point, so that a divergence between nodes is visible. Agree alert thresholds with the teams that submit transactions, and confirm the exact metric names in your Besu version before you write alert rules.
Record the choice in the design record
The pool choice affects capacity, sender behavior and troubleshooting, so it belongs in the network design record next to genesis settings, gas settings and validator count. Note which pool is in use, the limits set for it, the reason for the choice and the date it was reviewed. Operators who inherit the network later need this to interpret dropped transactions and to plan upgrades, because the pool options can change between Besu releases.
Verify behavior in your environment
The documented behavior of each pool describes the software, not the load profile of your network. Block time, number of senders, transaction size, and the RPC path your applications use all change how the pool behaves. Run a test that mirrors your expected traffic, including bursts and failed transactions, and record the results before go-live. Ask your Besu support or implementation partner to confirm the pool behavior for the exact release you plan to run.
Questions teams ask about transaction pool choice
Why does Besu recommend the sequenced pool for private networks?
Besu's documentation recommends the sequenced pool for private networks and keeps the layered pool as the default, which is aimed at public networks. The layered pool is built to handle the wide range of senders, fee levels and transaction volumes found on a public chain. A private network usually has a known, small set of participants and a more predictable transaction flow, so a simpler ordering model fits the workload better. Your team should confirm the current guidance in the Besu transaction pool documentation and test the choice against your own transaction profile before go-live.
Can a private network keep the layered default pool?
Yes. Besu runs the layered pool by default, so a private network can keep it without any change. The question is whether the default matches your traffic pattern and your operating model. Keeping the default means your team carries less configuration work now, but it also means you must understand how the layered pool limits memory and future transactions per sender. If your network will have few senders and predictable nonces, confirm in testing that the default behaves as you expect under load before you commit to it.
Which settings change when moving from the layered pool to the sequenced pool?
The pool is selected with the --tx-pool=sequenced option. Two settings also differ between the pools. The layered pool is limited by memory rather than transaction count, configured with --tx-pool-layer-max-capacity, and it replaces --tx-pool-limit-by-account-percentage with --tx-pool-max-future-by-sender. Teams moving to the sequenced pool should review their node configuration files for these keys, remove options that no longer apply, and confirm the resulting limits in a test environment. Check the exact option behavior in the Besu release you run, since options change across calendar releases.
What does changing the transaction pool cost, and what drives the effort?
The direct cost is the effort to change configuration, test it on a non-production network, and roll it out to every node. Pool choice is a configuration change, so the work is usually small in code terms but significant in verification. The main drivers are the number of nodes, whether each operator controls its own configuration, how many test scenarios you need (such as bursts of transactions, rejected transactions and restarts), and how formally your change process requires evidence. Ask any partner for a quote built on a written scope that lists the nodes, the test cases and the rollout plan. No duration is given here because it depends on your environment.
What must our team provide before a pool change can be scoped?
Prepare an inventory of every node and its current configuration file, the Besu version each node runs, and the transaction profile you expect in production, including typical volumes, sender counts and any bursty batch jobs. You also need the change window rules, rollback expectations and the monitoring you already use. Because some layered-pool options differ from sequenced-pool options, the team should identify which keys are set today. Access to a non-production network that mirrors production configuration is important, since a pool change is hard to validate without realistic traffic.
Can our internal engineers make the pool change without outside help?
Often yes, if your team already operates the network and has staff who understand Besu configuration, testing and rollback. The change is limited to node configuration, but it affects transaction handling for every participant, so it needs disciplined testing and a coordinated rollout across organizations that share the network. Teams without recent Besu operations experience, or without a test network, usually find the validation work is the hard part. An outside partner can plan the scope in writing, run the tests and document the evidence, but the decision on production timing stays with your change board.
What goes wrong if the pool setting does not match the workload?
Mismatches usually show up as transactions that stay pending longer than expected, senders blocked by per-sender limits, or memory pressure on nodes under bursty load. Each of these is easier to diagnose when your team has baseline metrics from before the change. Before going live, check transaction counts, pending pool size, rejected transactions and node memory under realistic load. Also confirm that every node uses the same pool setting, because inconsistent nodes can behave differently when they receive the same transactions.
Do pool changes affect the chain or existing data?
Changing the transaction pool setting changes how each node holds pending transactions before they are included in blocks. It does not rewrite the chain history. Pending transactions held in memory are not carried forward in the same way, so senders may need to resubmit or wait for their transactions to be processed. Plan the change in a quiet period, tell application owners what to expect and confirm the exact restart behavior in the Besu release your network runs.
What a DeployOpen engagement covers for the pool
A DeployOpen engagement treats the transaction pool choice as one decision inside a fixed-scope Besu design, agreed in writing before work starts. The first step is a review of your network's transaction profile with your team: how many organizations submit transactions, whether submission comes through a few gateways or many applications, how bursty the traffic is, and whether any senders need to queue future-nonce transactions. We also confirm which validators and nodes will accept transactions from applications, because the pool setting applies per node and the choice has to match how those nodes are used.
Based on that review, DeployOpen writes the configuration for each node role. For a sequenced pool this means setting --tx-pool=sequenced on the nodes that need it and reviewing any existing --tx-pool-limit-by-account-percentage values, which do not carry over to the layered pool. Where the layered pool is kept, the work covers --tx-pool-layer-max-capacity and --tx-pool-max-future-by-sender. We confirm the exact option names and their behavior against the Besu transaction pool documentation for the Besu release you run, since options change across the calendar release cadence.
Testing happens on a staging network that mirrors your production node count, genesis settings and transaction generators, before any change reaches production. The handover includes the configuration as versioned files, a runbook for changing the pool setting during an upgrade, and a short procedure for checking pool behavior under load. DeployOpen cannot promise a particular throughput or latency result, because those depend on your hardware, workload and network topology, which the staging results will show. Ask any partner to confirm the staging scope, the acceptance criteria and who signs off the results in the written scope.
How DeployOpen scopes and supports Besu transaction pool work
DeployOpen plans the transaction pool choice as part of the private network design, before genesis and node configuration are fixed. We scope, build, test and document the chosen pool on networks running in infrastructure you control, then hand over the configuration and runbooks your operators need.
How we scope
- Written scope lists which nodes run the sequenced or layered pool and why each role was assigned that pool.
- Scope records the transaction pool flags, memory capacity and per-sender limits each node will use.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We set the pool option across validator and RPC nodes in one reviewed configuration baseline.
- We test submission bursts, nonce gaps and replacement transactions against the chosen pool before go-live.
- We confirm that every node in the network uses a consistent pool setting and record any exceptions.
How we hand over
- You receive the node configuration files, a record of each pool option and the reason it was chosen.
- Handover includes a runbook for changing pool settings, including the steps for a rolling restart of nodes.
- Documentation names the Besu version tested and the checks to repeat when you move to a newer release.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer work can re-test the pool configuration when Besu releases change pool behavior or flags.
- Ask for a quote from the written scope, which sets the deliverables, environments and review points.
