Which consensus protocol should a new QBFT vs IBFT 2.0 Besu network use?
For a new permissioned Besu network, QBFT is the recommended consensus protocol. Both QBFT and IBFT 2.0 are proof-of-authority protocols that Besu supports for private networks, where a known set of validators takes turns proposing blocks and agrees on each one. The choice matters because consensus is set in the genesis file, and changing it later is a planned migration on a live chain, not a configuration tweak. QBFT is the protocol that Besu's current documentation treats as the forward path, and it is the one that carries the validator management options described in the next section. Clique is no longer an option at all: Besu 26.4.0 removed Clique consensus, so Besu can no longer start or produce blocks on pure Clique networks, per the GitHub release notes. Any Clique network you inherit needs its own migration plan before the next Besu upgrade.
Before go-live, confirm three things with your Besu release and your consortium. First, check the Besu QBFT documentation against the Besu version you plan to run, and record the exact consensus section you will place in the genesis file. Second, confirm which protocol every participating organization's node software is built to run, since a mixed or mismatched genesis will stop nodes from agreeing on a chain. Third, decide whether you will ever need to move from IBFT 2.0 to QBFT, because a live IBFT 2.0 network can migrate by adding a qbft section with a future startBlock and restarting every node before that block. Writing that migration into your operating runbook now is cheaper than improvising it under a deadline.
The protocol decision also shapes who owns the network's rules. Validator changes, upgrade timing and protocol transitions all need agreement among the operators who run validators, so the choice should be made in the same governance discussion as validator ownership and genesis sign-off. Ask your Besu integrator or internal platform team to document the chosen protocol, the planned transition path and the Besu version pinned for go-live, and keep that record under source control alongside the genesis file. Treat the protocol as a decision with a long life: it will outlast the first Besu release you deploy, and every later upgrade should be checked against it.
Why QBFT is the recommended default for new networks
QBFT gives a new permissioned network two validator selection methods and a documented path to change between them without starting a new chain. The cards below set out the decisions that make QBFT the usual starting point and the checks to run before you commit.
Validator selection by voting
QBFT can select validators through block header voting, so membership changes go through the consensus process itself. This suits a consortium where a defined group of operators agrees changes by vote. Before you commit, confirm how votes are proposed, counted and recorded, who holds voting rights, and how many votes a change needs. The QBFT documentation sets out the exact mechanics for your release.
Validator selection by contract
QBFT can also select validators through a smart contract, which holds the membership rules and the current set in a contract that every node reads. This fits networks whose governance rules are written down and enforced onchain. Your team must own that contract, so plan who can change it, how its code is reviewed and tested, and how a faulty change would be reverted before validators depend on it.
Transitions between selection methods
A QBFT network can switch between block header voting and contract-based selection at a scheduled point in the chain, so the governance model does not have to be final on day one. Treat the transition as a coordinated operator event: agree the block, confirm every validator is configured for the change, and confirm your node software supports it. Ask Besu maintainers or the QBFT docs to confirm the exact transition settings for your release before you rely on them.
Moving from IBFT 2.0 later
A network that starts on IBFT 2.0 can migrate to QBFT on a live chain. The documented method adds a qbft section with a future startBlock to the genesis file and requires restarting every node before that block. The migration is one-time, but it needs a window in which all operators coordinate restarts. Starting on QBFT removes that step from your plan, so confirm the steps in the migration guide against your release before scheduling it.
Clique is no longer an option
Besu 26.4.0 removed Clique consensus, and Besu cannot start or produce blocks on pure Clique networks. A new network that begins on Clique would need migrating before it could run on current releases. Check whether any proof-of-concept scripts, sample genesis files or vendor templates still use Clique, because those files will fail on current releases.
Pin consensus settings to each release
Besu uses calendar versions and ships roughly monthly, and the 26.6.0 release notes state that Besu requires JDK 25 to build and run. Keep consensus settings in the same source-controlled genesis and node configuration as the rest of the network, so every upgrade is tested against the same protocol choice. Ask your team to rehearse each release in a non-production network before it reaches validators.
Comparing QBFT, IBFT 2.0 and Clique for a new network
This table compares the three proof-of-authority options that have appeared in Besu private networks, against the questions a team asks when starting a new build. Read the rows as a decision path: first confirm whether Clique is even available, then check whether an existing IBFT 2.0 network already exists, and only then weigh QBFT's validator management options. For a new network, the takeaway is that QBFT is the option to plan around.
| Consideration | QBFT | IBFT 2.0 | Clique |
|---|---|---|---|
| Validator selection methods | Block header voting or smart contract selection | Block header voting only | Not applicable, removed from Besu |
| Validator management options | Contract-based selection and transitions between selection methods | Voting-based management only, per the Besu IBFT 2.0 to QBFT migration path | Not applicable |
| Migration path | Can be reached from a live IBFT 2.0 network by adding a future qbft section to the genesis file and restarting nodes before that block | Can migrate to QBFT, which is the documented route for existing networks | Not documented as a route, since Besu 26.4.0 cannot start or produce blocks on pure Clique networks |
| Current Besu support | Supported in current Besu releases | Supported in current Besu releases | Removed in Besu 26.4.0 (April 22, 2026) |
| Fit for a new build | Recommended starting point for a new permissioned network | Not recommended for a new build, since QBFT offers more options with the same starting path | Does not fit, because the client cannot run it |
| Fit for an existing live IBFT 2.0 network | Target for a planned migration, with a rehearsed restart plan | Remains workable while the network runs, but confirm the operational plan against current Besu releases | Not applicable |
| Planning effort to confirm | Genesis design, validator selection method and transition blocks | Existing configuration and any future QBFT migration | Any Clique network needs a migration plan before upgrading Besu |
What an existing IBFT 2.0 network can migrate to
A live IBFT 2.0 network can move to QBFT without rebuilding the chain. The method is to add a qbft section with a future startBlock to the genesis file, then restart every node before that block is reached. Until the milestone block, the network keeps running IBFT 2.0. From that block onward, the nodes apply QBFT rules. The existing chain history stays in place, so the migration does not require redeploying contracts or resyncing from a new genesis.
Every node must be restarted before the milestone block, because a node that has not loaded the new genesis configuration will keep applying IBFT 2.0 rules and will fall out of agreement with the nodes that have switched. In a consortium, the operators of each validator and RPC node must all confirm their restart window against the same block number, so the startBlock value has to be agreed in writing before anyone edits a file. Pick a block far enough ahead that every operator can schedule a maintenance window, and confirm that no node is left on an old configuration when the chain passes that height.
Before scheduling the migration, read the current migration page in the Besu documentation and confirm the exact genesis keys, the supported Besu release for your network, and the steps for validators and non-validator nodes. Check that your running Besu version is one that supports the migration path, and confirm it against the Besu releases on GitHub page, since removed features in recent releases affect what your nodes can run. Rehearse the change on a non-production copy of the network and confirm that rollback steps and a backup of node data exist before the milestone.
Validator management options only QBFT offers
The main reason to pick QBFT over IBFT 2.0 for a new network is that QBFT offers two ways to choose the validator set: validator changes by block header voting and selection by smart contract. IBFT 2.0 networks do not have these options, so a team that expects its validator set to change over time should settle which method it will use before genesis is written. Besu's QBFT documentation covers both methods and the transition mechanism that moves a network from one to the other, and the choice affects the genesis file, the governance process and the operating runbook.
With header voting, existing validators propose adding or removing validators, and the change is recorded in block headers once enough validators agree. The decisions to make are who holds a vote, what share of votes is required, and who may propose a change. With a selection contract, the validator set is read from a smart contract, so the decisions shift to who deploys and controls that contract, who holds its administrative keys, and whether changes need a second approval. In a consortium, the contract's owner effectively decides who validates, so ownership and change control should be agreed in writing by every member before go-live.
Transitions let a network move between the two methods at a block height set in advance, which means the team can start with one approach and change later without rebuilding the chain. Confirm with the Besu QBFT documentation which transition settings each release supports, and plan the change as a coordinated upgrade across all operators. For the operating detail, including voting procedures, contract-based changes, block time, timeouts and recovery when quorum is lost, see the Hyperledger Besu QBFT validator management content group.
How to set up QBFT on a new network
This sequence takes a permissioned Besu network from an agreed release to a running QBFT chain with known validators, enforced node permissions and a configuration record that can be rebuilt. Each step ends with a check so the next step starts from confirmed facts.
Confirm the Besu release and JDK 25
The platform or network lead picks the Besu release the network will run and confirms the build and runtime host have JDK 25, which the Besu 26.6.0 release notes state is required to build and run Besu. Choose a release from the current calendar series on the GitHub releases page, and record the exact version in the network design document. The check is a recorded version string and a JDK version reported on every planned validator host, with the same Besu binary or image digest used on all nodes.
Write the genesis file with a qbft section
The network architect writes the genesis file with a qbft section in the config block, setting the consensus parameters the network will run from block zero, such as block period and round timeouts, using the QBFT documentation as the reference for key names. Confirm the chain ID is unique to this network and that the genesis is identical on every node, since the genesis cannot be changed casually after launch. The check is a genesis file that parses, a chain ID recorded in the design record, and a file hash that every operator confirms before starting nodes.
Choose initial validators in extraData
The consortium decides the initial validator set and the architect encodes those validator addresses into the extraData field of the genesis block, which is how QBFT reads its starting validators. Each validator is controlled by the organization that operates its node, so confirm ownership and key custody for every address before encoding. The number of validators should follow the validator count analysis for the network, including the four-validator minimum described in the QBFT documentation. The check is a decoded extraData list that matches the agreed addresses one for one, reviewed by each participating organization.
Configure node permissions
Each operator writes a local permissions configuration file that lists the enode identities allowed to connect to their node, so only known participants can peer, and defines any account permissioning rules the consortium agrees on. Onchain permissioning was removed in Besu 25.6.0, so these rules must be local files that every node enforces. The check is a permissions file on each node that lists every other agreed node and no unknown enode, with the file kept identical across operators.
Start validators and confirm block production
The operators start the validator nodes with the same genesis and their own node keys, then the team watches the logs and the JSON-RPC endpoint to confirm peers connect and blocks are produced by the validator set. Keep the RPC interface private during this stage and use a validator-side check such as querying the latest block number and the block's proposer over the local endpoint. Confirm a block height that keeps advancing across several observations and that every validator appears in the validator list. The check is a live chain with advancing block height and validators producing blocks, with the start time and final block height recorded in the runbook.
Enable metrics and secure RPC access
Before the network takes application traffic, the operator enables the Prometheus metrics endpoint with the metrics option, keeps the default port unless the environment requires a change, and sets JSON-RPC authentication using either a credentials file or JWT validation against a public key. Besu does not terminate HTTPS natively, so confirm the TLS termination point in the reverse proxy or load balancer before exposing any RPC endpoint. The check is a Prometheus target reporting each node as up, and an authenticated request that fails without credentials.
Record the configuration under source control
The platform team commits the genesis file, the permissions files, the node configuration templates, the Besu version and the deployment scripts to a version-controlled repository, and excludes private node keys, which should be stored in the agreed key management system. Store the genesis hash and the validator list in the change record so that a rebuild or a new node can be checked against the original. The check is a clean repository that can recreate the same genesis hash and configuration from a fresh checkout, verified by a second operator.
What Clique's removal in Besu 26.4.0 means for existing networks
Besu 26.4.0 removed Clique consensus, so a pure Clique network can no longer start or produce blocks on current releases. The cards below cover the decisions this forces on teams that inherited or prototyped on Clique, and the order in which to make them.
Confirm the running Besu version
Start by checking which Besu version each node runs and whether any node is on a release at or after 26.4.0. A network that depends on Clique will not start or produce blocks on that release, so the version check tells you whether the problem is already live or still ahead of you. Record the version on every validator and RPC node, because a mixed fleet can hide the issue until a restart. Check the release notes for each version you plan to move through before you change anything.
Plan the move off Clique
Treat the move as a consensus change, not a routine upgrade. The realistic target for a new design is QBFT, which lets you define validators by block header vote or by smart contract. Decide the target protocol, the validator set and the block at which the change takes effect before writing any configuration. Confirm with your Besu vendor or community which migration path applies to your genesis and chain history, because the supported path depends on the consensus you are leaving.
Rehearse the migration in a non-production network
Build a copy of the network in a development or staging environment with the same genesis settings, validator count and node versions as production. Run the planned migration there, then check block production, peer connectivity, transaction processing and monitoring after the transition. Rehearsal is where you find problems with bootnodes, static node files and key placement. Do not touch production until the rehearsal produces the result you expect and the rollback steps have been tested.
Back up node data before any upgrade
Bonsai database format changes can be one-way, so an older Besu binary may be unable to open a database that a newer version has upgraded. Take a full backup of each node's data directory and keys before the version change, and store it outside the node. Test that a backup can be restored on a spare host with the prior Besu version. Without this step, a failed upgrade can leave you with no working rollback path.
Coordinate with every operator
In a consortium, each organization runs its own validators and nodes, so the Clique exit must be agreed by all of them. Agree on the target protocol, the transition block, the Besu version per node and the date of the change. Confirm who owns each validator key and bootnode, and who signs off on the production window. A single operator still on an old version can stall the network at the transition.
Document the decision and the rollback
Record why the network moved off Clique, which protocol it moved to, and the exact genesis and configuration changes. Keep these files under source control so the next person can reproduce the network. Write a rollback plan that names the backup to restore, the commands to run and the people who approve each step. Review the record with your security and compliance owners, since they will ask how the consensus change was tested and approved.
Questions buyers ask about QBFT vs IBFT 2.0
Is IBFT 2.0 still safe to pick for a new Besu network?
IBFT 2.0 remains a supported proof-of-authority option in Besu, but QBFT is the protocol we recommend for a new permissioned network. QBFT keeps the same validator model and adds validator management options that IBFT 2.0 does not offer, such as contract-based validator selection. Choosing IBFT 2.0 for a new build means you accept a later migration if you want those options. Confirm the current consensus support statement in the Besu documentation and release notes before you finalize the decision, because the project removes features over time.
What does a migration from IBFT 2.0 to QBFT require from each operator?
A live IBFT 2.0 network can move to QBFT by adding a qbft section with a future startBlock to the genesis file, then restarting every node before that block is reached. Each operator must update the genesis file on every node they run, choose a startBlock with enough lead time for all nodes to restart, and confirm that all validators use the same file. Operators should also rehearse the change on a non-production network first and keep a backup of node data. The exact configuration keys and any version prerequisites should be taken from the migration guide.
Can Clique networks still run on current Besu versions?
No. Besu 26.4.0 removed Clique consensus, so Besu can no longer start or produce blocks on pure Clique networks. Any team still running Clique needs a different plan, such as moving the chain to a supported consensus protocol through a planned migration, or keeping an older client version that can still run the network while the move is designed. Treat the Clique question as a blocker to confirm early, because it affects the client version, the chain history you carry forward and the test plan.
What drives the effort of choosing and migrating consensus?
The effort depends on how many organizations must agree, how many nodes each one runs, and how much change control the network already has. Governance and sign-off across parties usually take longer than the file edits. Other drivers include whether the network is live or not yet launched, the number of validators and RPC nodes that need a coordinated restart, the state of your configuration management, and how much testing you need on a rehearsal network. Ask any provider for a written scope that lists each node, each environment and each test before you accept a schedule.
Which parts of the consensus work carry recurring cost?
Most of the consensus setup is one-time work: choosing the protocol, writing the genesis configuration, and rehearsing the change. Recurring costs come from operating the network afterwards, including validator changes, client upgrades, monitoring and incident response. If you later use QBFT contract-based validator selection or transitions, those changes will recur as the validator set evolves. When you request a quote, ask which items are fixed, which are retainer-based, and what a later validator change would cost to run.
Can our own team choose and migrate consensus without a partner?
Yes, if your engineers can read the consensus documentation, manage the genesis file under source control, and coordinate restarts across every organization in the network. Teams with limited Besu experience usually need a rehearsal environment and a clear rollback plan before touching a live chain. A partner can help with scope, rehearsal, change planning and evidence, but the decision on which consensus to run and the sign-off remain with your organization. Assess your team against the migration steps before deciding.
What should we check in the Besu release notes before deciding?
Check the release notes for the client version you plan to run, because Besu ships new calendar releases roughly monthly and removes features across versions. Look for any statement about consensus protocols, database format changes and Java requirements. Note that Besu 26.6.0 requires JDK 25 to build and run, and that Bonsai database upgrades on first start cannot be opened by older versions. Plan a backup before each upgrade, and confirm the chosen release supports the consensus option you select.
How DeployOpen scopes Besu consensus design work
DeployOpen plans and implements open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and closed networks. For a Besu network, the consensus decision is not made in isolation. It is scoped against who runs validators, how many organizations must agree to a genesis and upgrade path, and which infrastructure each validator will sit on. Those answers determine whether a fixed-scope engagement needs to cover a single consensus choice, a full validator set design, or a migration plan from an existing IBFT 2.0 network.
Most engagements are fixed-scope, so the consensus work is written down before it starts. A typical written scope for this decision states the governance model, the validator owners, the target environments, the change process for the genesis file, and the verification steps that will show the chosen protocol works before go-live. The scope also names what is out of scope, such as validator key custody or permissioning, so those topics are not assumed to be covered. Ask for the scope document to list each deliverable and who signs off on the protocol choice.
Ongoing support, upgrade planning and continuous testing are available as retainers, and they matter here because Besu releases ship roughly monthly and each upgrade must be tested against the consensus configuration in use. DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs to ask for are the number of organizations and nodes, the environments in scope, the migration status of any existing network, and the support period you want covered. Confirm with the vendor and your own environment which items are included before accepting a quote.
