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 of the vendor guides that rank well in search.
It is out of date now. Besu stopped Clique block production in 25.12.0 and removed Clique completely in 26.4.0. So for a bank designing a private network today, the comparison is QBFT against IBFT 2.0. And honestly, even that one isn’t very close anymore.
It still matters, though. Consensus decides when a payment is final on the ledger, and how many servers have to fail before the network stops. It is also one of the few choices that is genuinely painful to change once several banks are live on a network.
This piece goes through how the two protocols work, where they really differ, who runs which one, and what an actual bank deployment looks like. It ends with a decision flow that architects can use on their own network.
Why Is Besu Consensus Now a Two-Protocol Choice?
Clique was the simplest of the three. It came from EIP-225; it could run on very few validators, and it kept going even with half of them down. The catch was finality. Clique never had immediate finality, so applications built on it had to cope with forks and chain reorganizations. Hence it wasn’t suitable for production.
Besu then retired it in two steps. Version 25.12.0 stopped Clique block production, and 26.4.0 removed it. Networks that started on Clique and later moved to proof of stake, Linea Mainnet being the obvious one, can still be synced.
The current documentation lists three supported protocols. QBFT is the recommended option for private networks, IBFT 2.0 is supported for existing private networks, and proof of stake is for Ethereum mainnet and public testnets. Proof of stake doesn’t apply to a bank’s private ledger, which leaves two.
One point here is, if your team built a sandbox on Clique at some stage, it needs rebuilding on QBFT first.
What Does Consensus Actually Do in a Bank’s Besu Network?
A consensus algorithm is the set of rules that nodes follow to agree on the next block of transactions. On Ethereum mainnet, Besu uses proof of stake because anyone can take part. Private bank networks use proof of authority (PoA) instead, where a known group of approved accounts, called validators, creates and confirms blocks. PoA gives faster block times and much higher throughput than mainnet proof of stake.
For a bank, speed isn’t really the main thing. Finality is. Finality is the point after which a transfer can’t be undone. The Principles for Financial Market Infrastructures require clear and final settlement for designated FMIs.
But many public networks only offer probabilistic finality that builds up over time.
QBFT and IBFT 2.0 both give immediate finality. A block is final the moment it is added, and the chain doesn’t fork. So the comparison between them comes down to more nuanced things, like how they recover from a failure, which standard they follow, and how the validator set is governed, etc.
How Does QBFT Work, and Why Does Besu Recommend It?
QBFT is a Byzantine fault-tolerant (BFT) consensus protocol. Byzantine fault tolerance means the network reaches correct agreement even when some nodes fail or send incorrect information. Validators take turns proposing blocks, and at least two-thirds of them must sign a block before it is added to the chain.
Each block is final as soon as it is added, and the chain does not fork. A network needs at least four validators to be Byzantine fault tolerant. Four or five validators can tolerate one unresponsive validator, and six to eight can tolerate two. Block times rise as validators are added. If more than a third stop participating, block production stops until enough of them come back. Nothing gets reversed when that happens. The chain just pauses.
Here are a couple of more things that set QBFT apart.
QBFT is an open standard. The Enterprise Ethereum Alliance published the QBFT specification for consortium use, and more than one Ethereum client implements it, like GoQuorum, Besu, etc. So members can run different client software as validators. One limit applies to mixed-client networks, though. Besu’s transitions feature, which changes validators or settings at a set block, is Besu-specific and cannot be used when other clients are validating. Running QBFT will not be enough then. On a mixed network, you can use voting or a smart contract, which is the normal way to change validators.
Here are the two ways we mentioned above to manage validators. Existing validators can vote members in or out, or a smart contract can hold the validator list. Consortia tend to like the contract route, because the admission rules become something an auditor can actually read. A network can switch between the two methods later at a planned block.
How Is IBFT 2.0 Different From QBFT?
IBFT 2.0 is the earlier BFT protocol in Besu and works in much the same way. Validators take turns creating blocks, a supermajority signs each one, and blocks are final with no forks. It has the same four-validator minimum and the same two-thirds liveness threshold. If more than one-third of validators stop participating, the network stops creating blocks.
The difference is what happens when the validator whose turn it is fails to deliver a block. The others then have to agree to skip it and move to the next validator. This step is called a round change. This is like a meeting where the chair doesn’t show up, and the room has to agree on a new one. The original Istanbul BFT, built in 2017 for GoQuorum, could get stuck at exactly this point when the network was slow. IBFT 2.0 was ConsenSys’s fix to this issue and also let validators vote members in or out. QBFT handles the hand-over more cleanly again, so it is less likely to stall on a bad network day.
So, on a normal day, the two feel much the same. The difference shows up on a bad day, when a validator hangs mid-round, or the link between two data centers gets flaky.
A few other things are there as well.
There are differences in status and governance. Besu supports IBFT 2.0 for existing private networks and recommends QBFT for new ones.
Source: Besu
The other point is the management of validators. IBFT 2.0 validators can be added or removed by vote only. Contract-based validator management is a QBFT feature. QBFT was added to Besu in release 21.1.0 to support interoperability with other Enterprise Ethereum Alliance clients.
An IBFT 2.0 network can move to QBFT without starting a new chain. Operators have to set a future block in the network’s configuration, and the consensus will switch to QBFT when that block is reached. The path is actively maintained. Besu 25.12.0 fixed a bug that affected the IBFT 2.0 to QBFT migration before.
There is no forced deadline to migrate, though, since the documentation describes IBFT 2.0 as supported.
If a bank decides to migrate, it has to be planned. Like, from block 2,000,000, use QBFT. Before that block number arrives, every bank running a node has to update its node’s configuration with the new rule. When the network reaches that block, every updated node starts using QBFT.
QBFT vs IBFT 2.0: A Comparison Of Two Besu Consensus
Who Runs QBFT and IBFT 2.0, and for What?
The pattern is pretty clear. Networks that banks and central banks have built since 2021 run QBFT. IBFT 2.0 shows up mainly in public-sector networks that are older than that.
Fnality is probably the most telling case, because it is live and regulated. The Sterling Fnality Payment System runs on Besu, went live in 2023, and is a systemically important payment system supervised by the Bank of England. Fnality says plainly that its payment system uses QBFT. A block is valid only once at least two-thirds of validators approve it, and Fnality links this choice to staying compliant with settlement finality rules. Only regulated deposit-takers in the Sterling Monetary Framework can join, so the validator model and the membership model line up quite neatly.
Project Agorá could be the biggest cross-border example. According to the BIS prototype report, published May 27, 2026, it has two layers. Commercial banks share one ledger for their tokenized deposits, and each central bank keeps its reserves on its own separate ledger. The shared platform runs on Besu with QBFT. In live trials in July 2026, 22 banks and five central banks made 30 real payments worth about CHF 800,000 in six currencies. Each payment settled in around 80 seconds on average.
The IBFT 2.0 examples are long-standing networks with many independent operators. EBSI dates from 2018 and LACChain’s BNDES network from 2020. For networks like these, a planned migration to QBFT is the question, not a new consensus choice.
The Bank of Korea is another example, but it gives a different lesson. They run the network as the only validator. Their view is that the value of this ledger is in programmable money. They don’t want to share control across many parties. Fair, but from a pure technical PoV, a network with three validators or fewer can still create blocks, but finality is not guaranteed if a validator misbehaves. But this trade-off is acceptable when the single operator is a central bank that everyone already trusts.
How Should a Bank Choose a Besu Consensus Setup?
For a new bank network, the protocol answer is QBFT. The real design choices sit underneath it, in who runs validators, how the set changes, and how large it is.
Read the flow from the top.
- Start every new network on QBFT. It is what Besu recommends and the only target of a supported migration.
- Size the validator set by the failures it has to survive. A set of 3f + 1 validators tolerates f failures, so four tolerate one and seven tolerate two. If more than a third stop, blocks stop too.
- Don’t make every member a validator. In the Drex example, they ran 6 validators among 26 nodes and planned a ceiling of 16. So membership and validation are separate decisions.
- Put validators in different places and, where the governance allows it, with different organizations. In the same Drex example, they spread its six validators across four data centers so no single site could halt the chain.
- If your rules for admitting a bank need to be written down and checked by auditors, put them in a smart contract. If the group is small and rarely changes, a simple vote among validators is enough. And if some banks will run software other than Besu, don’t use Besu’s own transition feature for changing validators.
- Published speed figures usually come from servers sitting in one data center. A network spread across cities will be slower, so run your own tests with your real number of validators, block time, and locations.
- Check legal finality separately. In QBFT, a transaction is irreversible on the ledger. But that doesn’t always mean the law also treats it as final. In case of Fnality, their transfers became legally final only after the UK granted it a settlement finality designation in late 2024.
Source: Fnality
Zeeve for Besu Consensus Design, Migration and Validator Operations
The protocol question for new bank networks now has a clear answer in QBFT. The harder work is in validator design, admission rules, sizing, and for older networks, a coordinated move off IBFT 2.0 or a retired Clique pilot.
Zeeve configures production Besu networks on QBFT or IBFT 2.0 and sets consensus around validator count, finality requirements, and the consortium’s governance model.
Zeeve is a Certified Solution Provider for Besu and a member of LF Decentralized Trust, with engineers who contribute to Besu. Its teams handle protocol customization and performance optimization, chain migration engineering, on-premises deployment, and 24/7 production support. Zeeve’s office infrastructure and processes are SOC 2 Type II and ISO 27001 compliant.
Schedule a call with our Besu experts today to discuss your requirements.
