By Zeeve

If you looked at Besu consensus a couple of years ago, you probably saw a three way comparison of Clique, IBFT 2.0 and QBFT. A lot of content still shows that picture, including some vendor guides that rank well in search.

That comparison is now out of date. Besu stopped Clique block production in version 25.12.0 and removed Clique completely in version 26.4.0. For a bank designing a private network today, the practical comparison is between QBFT and IBFT 2.0.

This choice matters because consensus determines when a payment becomes final on the ledger and how many servers can fail before the network stops producing blocks. It is also one of the more difficult architectural decisions to change once multiple institutions are operating on a shared network.

This article looks at how the two protocols work, where they differ, how they are used in institutional networks, and what architects should consider when selecting a consensus mechanism.

Why Is Besu Consensus Now a Two Protocol Choice?

Clique was the simplest of the three. It came from EIP 225, could run with relatively few validators, and continued producing blocks even when some validators were unavailable.

Its limitation was finality. Clique did not provide immediate finality, meaning applications had to account for possible forks and chain reorganizations.

Besu retired Clique in two stages:

• Version 25.12.0 stopped Clique block production.
• Version 26.4.0 removed Clique completely.

Networks that previously used Clique and later moved to other consensus mechanisms can still be synchronized where supported.

Besu currently recommends QBFT for private networks and supports IBFT 2.0 for existing private networks. Proof of stake is used for Ethereum mainnet and public test networks.

For institutions designing private Besu networks, this makes QBFT and IBFT 2.0 the relevant options to evaluate.

What Does Consensus Actually Do in a Bank’s Besu Network?

A consensus algorithm defines the rules that nodes follow to agree on the next block of transactions.

On Ethereum mainnet, Besu uses proof of stake. Private bank networks commonly use proof of authority (PoA), where a known group of approved accounts, called validators, creates and confirms blocks.

For banks, transaction speed is only one consideration. Finality is particularly important.

Finality is the point at which a transaction is considered irreversible on the ledger. The Principles for Financial Market Infrastructures also emphasize clear and final settlement for designated financial market infrastructures.

Many public networks offer probabilistic finality, where confidence in a transaction increases over time.

QBFT and IBFT 2.0 both provide immediate finality. A block is final once it is added, and the chain does not fork.

The differences between the two protocols become more relevant when looking at failure recovery, protocol specifications and validator governance.

How Does QBFT Work, and Why Does Besu Recommend It?

QBFT is a Byzantine fault tolerant consensus protocol.

Byzantine fault tolerance means that a network can reach agreement even when some nodes fail or send incorrect information.

Validators take turns proposing blocks, and at least two thirds of the validators must sign a block before it is added to the chain.

Some important characteristics of QBFT include:

• A minimum of four validators is required for Byzantine fault tolerance.
• Four or five validators can tolerate one unresponsive validator.
• Six to eight validators can tolerate two unresponsive validators.
• If more than one third of validators stop participating, block production stops until enough validators return.
• Once a block is committed, it remains final.

The network may pause when too many validators become unavailable, but previously committed transactions are not reversed.

QBFT as an Open Standard

QBFT is an open standard. The Enterprise Ethereum Alliance published its specification for consortium use, and multiple Ethereum clients implement it, including GoQuorum and Besu.

This allows consortium members to operate different client software while participating in the same network.

There is one important limitation. Besu’s transitions feature, which allows validator changes or configuration updates at a predetermined block, is specific to Besu. It cannot be used when other clients are validating the same network.

Mixed client networks can instead use validator voting or smart contract based validator management.

How Are Validators Managed?

There are two common approaches to managing validators:

Validator voting: Existing validators vote to approve or remove members.

Smart contract based management: A smart contract maintains the validator list and applies predefined admission rules.

Consortiums may prefer the contract approach because membership and admission rules can be explicitly defined and inspected.

A network can also change its validator management approach at a planned block, depending on its configuration and requirements.

How Is IBFT 2.0 Different From QBFT?

IBFT 2.0 is an earlier Byzantine fault tolerant protocol supported by Besu.

Its general operating model is similar to QBFT. Validators take turns proposing blocks, a supermajority signs each block, and committed blocks achieve immediate finality.

It also has the same four validator minimum for Byzantine fault tolerance and the same two thirds participation requirement.

The main difference appears when the validator scheduled to propose a block fails to deliver it.

In IBFT 2.0, the other validators must agree to skip that validator and move to the next one. This process is called a round change.

Think of it as a meeting where the scheduled chairperson does not arrive. The remaining participants must agree to move to another person before the meeting can continue.

The original Istanbul BFT protocol, developed in 2017 for GoQuorum, could get stuck at this stage when the network experienced delays. IBFT 2.0 addressed this issue, while QBFT introduced further improvements to validator handovers.

Under normal conditions, the two protocols can behave similarly. Their differences become more noticeable when a validator becomes unresponsive or communication between data centres becomes unreliable.

Differences in Validator Management and Governance

There are also differences in protocol status and validator management.

• Besu recommends QBFT for new private networks.
• IBFT 2.0 remains supported for existing private networks.
• IBFT 2.0 supports validator membership changes through voting.
• QBFT supports voting and smart contract based validator management.

QBFT was introduced in Besu version 21.1.0 to support interoperability with other Enterprise Ethereum Alliance clients.

Can an IBFT 2.0 Network Migrate to QBFT?

Yes. An existing IBFT 2.0 network can migrate to QBFT without starting a new chain.

Operators configure a future block at which the consensus mechanism will change. Every participating organization must update its node configuration before the network reaches that block.

For example, a consortium may decide to switch to QBFT at block 2,000,000. All participating nodes must be updated with the new configuration before that block is reached.

This requires coordination between network operators and participating institutions.

There is no forced migration deadline because Besu continues to support IBFT 2.0.

What Do Institutional Deployments Tell Us?

Looking at existing institutional projects provides useful context for understanding how consensus decisions relate to real financial infrastructure.

Fnality

Fnality is one of the notable examples of a live institutional payment system using Besu and QBFT.

The Sterling Fnality Payment System went live in 2023 and is a systemically important payment system supervised by the Bank of England.

Fnality uses QBFT, where a block is valid once at least two thirds of validators approve it.

Its validator model is restricted to regulated deposit taking institutions within the Sterling Monetary Framework. This provides a defined participation model for its payment network.

Project Agorá

Project Agorá is exploring how tokenized commercial bank deposits and central bank reserves can work together on a shared platform.

According to the BIS prototype report published on May 27, 2026, its architecture has two layers:

• Commercial banks share one ledger for tokenized deposits.
• Each central bank maintains reserves on its own separate ledger.

The shared platform runs on Besu with QBFT.

The project demonstrates how multiple banks and central banks can participate in a coordinated settlement environment while maintaining distinct roles and responsibilities.

EBSI and LACChain

EBSI and LACChain’s BNDES network are examples of longer running networks that have used IBFT 2.0.

For networks with established participants, infrastructure and operational processes, migration to QBFT becomes a question of evaluating technical and operational requirements rather than simply selecting a consensus protocol for a new deployment.

Bank of Korea

The Bank of Korea provides a different example.

Its network operates with a single validator. The approach reflects a decision to retain control within one institution rather than distribute validation responsibilities across several parties.

A network with three validators or fewer may still produce blocks, but it does not provide the same Byzantine fault tolerance guarantees as a network with at least four validators.

This highlights an important architectural consideration: the consensus mechanism and the governance model need to be evaluated together.

How Should a Bank Choose a Besu Consensus Setup?

For a new private Besu network, QBFT is the recommended starting point. However, selecting the protocol is only one part of the overall architecture.

Several other considerations influence how the network should be designed.

1. Size the Validator Set According to Failure Requirements

A network with 3f + 1 validators can tolerate f Byzantine failures.

For example:

• Four validators can tolerate one failure.
• Seven validators can tolerate two failures.

The validator count should reflect the level of resilience required by the network.

2. Separate Network Membership From Validation

Not every participating institution needs to operate a validator.

An organization may participate in the network, use its applications and interact with other members without directly validating blocks.

This distinction can influence infrastructure costs, governance and operational responsibilities.

3. Distribute Validators Across Locations

Validators should be distributed across different locations and, where governance permits, different organizations.

For example, placing validators across multiple data centres can reduce the risk of one infrastructure failure stopping the entire network.

4. Define Validator Admission Rules

If a consortium has formal requirements for admitting new banks or removing existing participants, those rules should be clearly documented.

A smart contract can provide an auditable way to manage validator membership. Smaller networks with infrequent changes may find validator voting sufficient.

5. Consider Mixed Client Environments

If different institutions intend to operate different Ethereum clients, compatibility needs to be considered during the design stage.

Besu specific features may not work in a network where other client implementations are participating as validators.

6. Test Performance Under Realistic Conditions

Published performance figures often come from validators operating within one data centre.

A geographically distributed network may experience different results because of network latency and communication delays.

Testing should reflect the actual validator count, block time, infrastructure locations and network conditions.

7. Evaluate Legal Finality Separately

A transaction being irreversible on a blockchain does not automatically mean it is legally final.

This distinction is important for regulated financial infrastructure.

Fnality, for example, received settlement finality designation in the UK in late 2024. Its example highlights the relationship between technical settlement and the applicable legal framework.

Final Considerations

QBFT and IBFT 2.0 both provide immediate finality and Byzantine fault tolerance for private Besu networks.

For new networks, QBFT is the recommended option. Existing IBFT 2.0 networks should evaluate migration based on their operational requirements, validator governance and compatibility.

Ultimately, consensus is only one part of a production blockchain network. Validator distribution, membership rules, infrastructure resilience, performance testing and legal finality all influence how reliably the network operates.

These considerations are central to designing and operating enterprise Besu networks. Through its work with Besu infrastructure, Zeeve engages with the technical and operational challenges involved in building blockchain networks for institutional use cases.