Where Besu fits
Besu is an Ethereum execution client written in Java and licensed under Apache-2.0, and a graduated project of LF Decentralized Trust. Paired with a consensus client, it runs on Ethereum Mainnet and public testnets. On its own, it runs private permissioned networks that use proof of authority consensus with QBFT or IBFT 2.0.
Teams in banking, payments and digital assets look at private and consortium EVM networks for tokenization and settlement because Solidity, Ethereum tooling and standard token interfaces carry over while membership stays under their control. An implementation covers governance, validator placement, permissioning, contracts, key custody, integration with core systems and custodians, and an operating model shared across participants.
The project has changed noticeably in recent releases. The repository moved to besu-eth/besu in 26.4.0, the documentation now lives at docs.besu-eth.org, and several features older private networks relied on have been removed. Plan against the changelog for the release you deploy.
Discovery: network governance and use case
Most decisions on a permissioned network are about who may do what. Agree them before writing genesis files.
| Decision | Questions to settle | Output |
|---|---|---|
| Network model | A private network run by one firm, a consortium operated by several members, or deployment to a public network. | Network model and list of operating members. |
| Governance | Who adds or removes validators, admits members, approves contract upgrades and changes genesis parameters. | Governance charter and change procedure. |
| Validator set | How many validators each member runs and where, given that losing more than a third halts block production. | Validator placement plan. |
| Asset and contract model | Token standards, issuance and redemption flows, transfer restrictions, upgrade mechanism and admin keys. | Contract specification and threat model. |
| Integration points | Core ledgers, payment rails, custody, KYC records and reporting. | Integration list with an owner per interface. |
Consensus and network configuration
The Besu documentation calls QBFT the recommended enterprise-grade consensus protocol for private networks. Validators take turns proposing blocks and a super-majority must sign each one. If more than a third of validators stop participating, block production stops, so production networks need at least four validators. Agree genesis settings such as blockperiodseconds, requesttimeoutseconds and epochlength before launch.
Validators are managed by block header voting through the QBFT JSON-RPC methods, or by a validator smart contract that puts the governance rules on chain. Switching method later uses a transition at a future block, which needs a coordinated restart of all nodes.
Besu still supports IBFT 2.0 and documents a migration to QBFT at a chosen start block. Recent releases fixed several issues on migration networks, so rehearse the migration on a copy of the network with the exact target release.
Tessera private transactions and onchain permissioning were removed in 25.6.0. Clique was removed in 26.4.0, though networks that moved from Clique to proof of stake still sync. Proof of work removal finished in 26.7.0. Networks that depend on these need a redesign before upgrading.
Permissioning and confidentiality
Besu supports node permissioning, which restricts peer connections to known nodes, and account permissioning, which restricts which accounts can submit transactions. Local permissioning reads rules from a file on each node and is enforced only by that node, so configuration management must keep the files consistent. The plugin API's permissioning service allows custom rules, for example checking membership against an external registry.
With Tessera privacy removed, confidential data needs another design: sensitive data off chain with hashes or commitments on chain, separate contracts or networks for groups of participants, or application-level privacy, which the maintainers' removal announcement points to. Choose the pattern during discovery, because it shapes contracts, integrations and data retention.
Extension points and integrations
Customization happens in contracts, plugins and the services around the nodes.
Smart contracts
Token, registry and settlement contracts in Solidity, with access control, transfer restrictions tied to your onboarding records, and pause and upgrade mechanisms that match the governance charter. DeployOpen's smart contract security testing reviews them before deployment.
Besu plugins
Java plugins extend Besu without a fork, for example with permissioning rules, transaction selection, extra RPC methods or a security module for node key operations. The plugin API is being reorganized into per-feature modules, so pin plugin builds to a Besu version.
Signing and custody
Transaction signing usually runs outside the node, in an external signer such as Web3Signer, which can use keys from an external vault, or in a custody platform. Map which keys sign issuance, transfers and admin operations, and who controls each.
Core systems and payment rails
An integration layer reads contract events, posts entries to the core ledger and triggers fiat legs on payment rails. QBFT blocks are final once added, but consumers still need idempotent processing and replay after outages.
Node layout, hosting and key management
Each member runs its nodes in its own infrastructure, so agree these settings across the network.
| Area | Approach | Check |
|---|---|---|
| Node roles | Separate validators, bootnodes and RPC nodes. Applications reach RPC nodes through a gateway and never call validators directly. | No validator RPC port is reachable from application networks. |
| RPC access | Enable JSON-RPC authentication with a credentials file or externally issued JWTs, grant per-method permissions, and terminate TLS in front of RPC nodes. | Application tokens cannot call admin or voting methods. |
| Storage and sync | The docs pair the ENTERPRISE (or PRIVATE) profile with full sync and Forest storage. Some database format upgrades are one-way, so snapshot data directories before upgrading. | A node rebuilt from a snapshot catches up within the recovery target. |
| Node keys | Node keys identify nodes in permissioning and validator sets. Generate them under a written procedure and restrict file access, or use a security module plugin to delegate key operations to an HSM-backed implementation. | Replacing a validator key has been rehearsed. |
| Monitoring | Collect Prometheus metrics and logs. Alert on stalled block production, frequent round changes, falling peer counts and validators that stop proposing. | Stopping one validator raises an alert while blocks continue. |
Testing and rollout
Contract testing covers unit and property tests, access control, upgrade paths and a security review. Network testing covers stopping validators up to the fault limit, partitions, permissioning denials, key replacement and representative load. Integration testing reconciles on-chain balances with the core ledger and custodian records, including after restarts and replayed events.
Roll out in stages. Run a test network operated by the same members under the same governance process, admit members one at a time, and rehearse validator changes and a contract upgrade before production assets are issued. Keep genesis, permissioning and deployment records in version control with their approvals.
Upgrades, versions and common questions
How often does Besu release?
Besu uses calendar-based version numbers, such as 26.9.0, and releases frequently; it has required Java 21 or later since 24.6.0. Each changelog entry lists breaking changes and upcoming removals. Read them before every upgrade, since several long-standing features have been removed since 2024.
How do we upgrade a QBFT network?
Upgrade one validator at a time so a super-majority stays online, and confirm each node rejoins and proposes before moving on. Some releases need compatibility flags during rolling upgrades, such as the flag that keeps upgraded nodes compatible with 25.x nodes on BFT networks. Genesis transitions need a coordinated restart.
We use Tessera private transactions. What now?
Releases from 25.6.0 do not support them, and staying on an older release leaves you without fixes. Plan a move to an application-level privacy design, migrate or re-issue affected contracts, and agree a cutover with all members.
Should we use a public network instead?
It depends on who must validate, what data may be public and what regulators and counterparties accept. Confirm the position with your compliance function. DeployOpen's DIAN Framework describes patterns for connecting institutional finance systems with decentralized finance protocols.
Besu operating ownership
A permissioned network has a shared layer and a layer each member runs. Both need named owners.
Network operator
- Maintains genesis, bootnodes and permissioning files.
- Coordinates upgrades and transitions.
- Runs shared monitoring and incident channels.
Validator operators
- Run validators and RPC nodes in their own infrastructure.
- Protect node keys and apply upgrades on schedule.
- Vote on validator changes under the charter.
Contract and asset owners
- Own contracts and their admin keys.
- Approve contract upgrades.
- Reconcile on-chain balances with books of record.
Security and compliance
- Review key custody and signing policies.
- Commission contract and infrastructure testing.
- Keep evidence for audits and regulators.
Scope and handover
Effort depends on the number of members and validators, the governance model, contract complexity, the confidentiality design, signing and custody choices, the integrations with core systems and whether an existing network has to migrate off removed features.
DeployOpen runs governance and design workshops with members, builds genesis and permissioning as code, deploys and hardens nodes in each member's infrastructure, integrates signing, custody and core systems, tests contracts and infrastructure, and rehearses validator changes and upgrades. Handover includes the governance charter, network design, key procedures, contract test records, reconciliation design, alert routes and upgrade runbooks.
