What changes when several organizations run one Hyperledger Besu consortium network
When several organizations each run Besu nodes, the question is no longer how to run one network but how separate operators keep one chain agreed. Each member runs its own validators, RPC nodes and bootnodes, yet every node must accept the same genesis, the same validator set and the same consensus rules. Nothing in a Besu private network is enforced by a central console, so the consortium has to agree in writing on what each member runs, who can change it and how changes are rolled out before any node joins.
Besu's private network features put trust decisions on each node. QBFT validators reach agreement only when enough of them are online and honest, and the local permissioning configuration described in the Besu docs is enforced by each node on its own. A node's permissions file restricts which peers it connects to and which accounts it accepts, so two members can hold different allowlists without any single party noticing. The consortium therefore needs a shared, versioned record of the permissions each member applies, plus a check that each node's file matches it. Plugins are the route the maintainers suggest for features that were removed from core, such as the former privacy and onchain permissioning options, so each member that uses one must run the same plugin version and understand its behavior.
Four things need joint ownership. The genesis file, including the initial validators in extraData, is effectively fixed once the chain runs, so changes must be agreed by all members before launch. The validator set and bootnode addresses must be known to every operator, and a bootnode change affects every peer that relies on it. Upgrade timing also needs coordination: the Besu 26.10.0 release notes state that the Bonsai database upgrades on first start and older versions cannot open it, so each member should confirm its rollback path and backup before moving to a new release. Ask each member to confirm who holds which key, which release it runs, and who is authorized to approve a change to any of these four items.
Who owns validators, bootnodes and permissions in a shared network
In a shared Besu network, each organization controls its own nodes, but the rules those nodes enforce must agree. The cards below cover the decisions that sit between the consortium agreement and the configuration files on each operator's servers, and what each one costs to get wrong.
Validator ownership per organization
Each validator in a QBFT network holds a node key and signs blocks, so the organization running it controls part of block production. Agree in writing how many validators each member runs, who may restart or replace one, and who is paged when a validator drops out. Confirm that no single member can stop block production alone when quorum depends on several operators. Validator count and placement should be decided before the genesis is signed.
Bootnode ownership and redundancy
Bootnodes are the entry points new nodes use to find the network, so their availability affects every member. Decide which organizations host bootnodes, how many run in separate failure domains, and who updates enode addresses when a host changes. An unreachable bootnode does not stop established peers from talking, but it blocks new nodes from joining. Ask each member to confirm who holds the enode records and how changes are announced.
The permissions file each node enforces
Besu's local permissioning reads a permissions configuration file on each node. Node permissioning limits connections to known participants, so a node will only peer with enodes it has been told to accept. Because every operator enforces its own file, a member that never updates it can keep a stale or overly broad list. Agree on who authors the canonical list, how it is distributed, and how each operator confirms its copy matches.
Account onboarding and suspension rights
Account permissioning in Besu covers onboarding rules, suspending accounts and restricting actions, and it is also enforced locally. A consortium must decide which member may approve a new account, who can suspend one after an incident, and how fast each operator must apply that change. Without a defined owner, a suspension agreed by the group may take effect on some nodes and not others. Confirm these rights, response times and escalation contacts in the consortium agreement.
Change control for the shared genesis
The genesis file defines the chain's consensus rules and initial validators, and every member must start from the same version. Settle who proposes changes, what approval threshold applies and how a new genesis or fork milestone is scheduled across operators. Changes that alter consensus settings cannot be applied by one member alone without splitting the network. Confirm the approval process, the notice period and the rollback plan in writing before the first node starts.
How each node enforces the network of trust locally
Besu enforces permissioning on each node, not once for the whole network. Its local permissioning has two parts. Node permissioning decides which peers a node will connect to, based on an allowlist of enode identities. Account permissioning decides which accounts may transact, covering onboarding rules, suspending accounts and restricting specific actions. Both are configured through a permissions configuration file on every node, as described in the Besu permissioning documentation. Read the docs for the exact configuration keys in the Besu version you run, since these files are version-sensitive.
Because each node holds its own file, one node's allowlist does not change what another node accepts. A consortium therefore has to agree on the node and account lists as a governed artifact, then distribute the same content to every operator and track changes through review. Ask each member to confirm, in writing, which file version their nodes run, and plan a check that compares hashes across nodes after every change. A node added to the allowlist on one side but not the other will fail to peer, which looks like a network fault and is hard to trace.
Onchain permissioning, where a smart contract held the lists, was removed in Besu 25.6.0 (June 4, 2025). Consortia that relied on it cannot simply upgrade and keep the same model. They need to choose between a local file managed under change control and a permissioning plugin that reads from a system they operate, and they should confirm the plugin's behavior and maintenance status before committing. The choice affects who can approve a new member and how quickly a compromised account can be suspended, so settle it during governance design rather than at go-live.
How a consortium brings its first shared network online
This sequence moves a group of organizations from a signed governance agreement to a shared Besu network that every member can verify independently. Each step ends with a check that a named party can perform, so no one has to rely on another member's word that the network is ready.
Agree governance and change control
Before any node is configured, the members agree in writing who may propose changes to the genesis file, the validator set, bootnodes and permissioning, how proposals are reviewed, and how each member is notified of a change. The consortium also names a technical contact for each organization. Done means every member has signed the same governance document and holds the same version of it. Ask each member to confirm in writing who can approve a change, because that list decides who can later block or accept a validator or upgrade decision.
Fix the shared genesis and initial validators
One agreed genesis file is drafted and circulated, including the consensus section, the initial validator addresses in the extraData field, the gas settings and any preallocated accounts. Every member reviews the same file, and the consortium records its hash. Done means each member's independent review has been recorded and every member has the identical file on record. Ask for the genesis hash to be published in the governance record, since any later difference between members traces back to this file.
Assign validator and bootnode ownership
Each validator key and each bootnode is assigned to one organization that operates it, with a named owner who can restart the node, rotate its keys and report its status. Ownership is recorded alongside the node's address and enode. Done means the ownership register matches the validator list in the genesis file one to one. Confirm that each owner holds its node's private key in a location only that owner controls, and that no organization holds another member's key.
Write each member's permissions file
Each organization writes its node permissions file, which lists the enodes that its node may connect to. Each organization also writes its account permissions where it applies, such as onboarding rules and any suspended accounts. The files are kept under version control and reviewed against the membership list from the governance step. Done means every permissions file lists the same set of members and each file is committed to the consortium's configuration repository. Because each node enforces its own file locally, a mismatch here shows up as a peer that will not connect, so compare the lists before go-live.
Bring up bootnodes and validators
Each owner starts its bootnodes first, then its validators, using the agreed genesis file and its permissions file. Bootnode enodes are shared through the governance record so every member can add them. Done means each validator reports the genesis hash the consortium recorded, and each bootnode is reachable from the other members' networks. Check the genesis hash on every node before moving on, because a node started from a different file will fork away from the rest of the network without raising a clear error.
Admit members through documented onboarding
Members that are not validators join through the onboarding procedure written in the governance step. The procedure covers who submits the request, who approves it, how the permissions files are updated on every node, and who records the change. Done means the new member appears in each permissions file, in the consortium's membership record, and in the onboarding log with the approver's name. Confirm that the change was applied on every existing node, not only on the new member's node, since a single outdated file can split peer connectivity.
Verify peers, block production and metrics
Once the network is up, each owner checks that its node has the expected peers, that blocks are being produced at the expected interval, and that the metrics endpoint shows the node is healthy. Each member compares its peer count and latest block hash with the others. Done means every validator has the expected peers, every member can see the same chain head, and the monitoring records are available to each owner. Ask each member to confirm the head block hash it sees, because agreement on that value is the clearest sign that the members are on one network.
Why upgrade timing and removed features need joint decisions
In a consortium, no member can upgrade Besu on its own schedule without consequences for the others. Besu ships roughly monthly under calendar versions, and the releases page lists 26.7.0, 26.8.0, 26.9.0 and 26.10.0 as the next steps. Each member's node runs the same chain, so the members need to agree on which release each operator will adopt, when protocol milestones take effect, and who moves first in a shared test environment. A node that falls behind on a version that changes behavior can stop following the network, and the network's governance has to decide how much lag is acceptable before a member is treated as out of step. Confirm your own cadence with the release notes for each version you plan to run.
Several removals make these decisions harder for consortia that were set up before 2025. Besu 25.6.0 removed the Tessera privacy feature and onchain permissioning, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups. Besu 26.4.0 removed Clique consensus, so a pure Clique network can no longer start or produce blocks. If any member's existing network still depends on these features, the consortium must choose a migration path before the upgrade reaches that member, and the choice affects every other member's configuration. Ask each member to list the features and RPC groups its applications call, and compare that list against the removal notes for the target release.
Before any member upgrades, every member needs a verified backup. The 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and that older versions cannot open an upgraded database, so rolling back means restoring a backup taken before the change. Agree on a shared backup standard, a rehearsal in a non-production network, and a record of which member upgraded at which block or date. JDK 25 is also required to build and run Besu, according to the 26.6.0 release notes, so each operator should confirm its build and runtime images meet that requirement before scheduling the change.
Limits to confirm with the Besu maintainers and your consortium
Several parts of a multi-organization Besu design depend on what the current release supports and what each member has agreed to run. The cards below list the points to confirm in writing before governance documents, onboarding plans and member applications are finalized.
Privacy approach after Tessera
Tessera privacy and the EEA and PRIV privacy RPC groups were removed from Besu, so any plan that keeps transaction data private between members must be checked against the release you intend to run. Confirm with the maintainers whether the approach you have in mind is supported, whether it runs as a plugin or external service, and who in the consortium will own its upgrades. Ask for the removal notes that apply to your target version.
Consensus and milestone plan
Every member must agree on the consensus protocol and any scheduled milestone blocks before go-live, and those choices must match the Besu release each member runs. Clique is no longer supported for block production, so any network that started on it needs a documented migration path. Confirm that the milestone plan, the release in use and the consensus configuration line up, and record the agreed upgrade order.
Permissioning without plugins or forks
Onchain permissioning was removed, so the consortium's access rules must be enforced through local permissions files, a maintained plugin or a fork. Each approach has different upgrade and support consequences. Ask the maintainers and your integrator whether the rules you need can be expressed locally, and if a plugin or fork is required, confirm who maintains it, how it tracks new releases and what happens when a member changes it.
RPC authentication for member applications
Besu supports username and password credentials or JWTs validated against a public key, but it does not terminate HTTPS itself. Member applications, identity providers and gateways must fit that model, so confirm how each application will obtain and refresh tokens, where TLS is terminated, and which methods each caller may use. Test these flows with each member's applications before sharing RPC endpoints across the consortium.
Besu version on every member node
Members upgrade on their own schedules, and a database format change can prevent older versions from opening a node's data. Ask each member to report the exact Besu version and JDK it runs, and agree on a minimum version and a shared compatibility window. Confirm that each member keeps a backup taken before any upgrade, since the 26.10.0 notes say older versions cannot open an upgraded Bonsai database.
Questions consortium teams ask before bringing in a partner
Can one organization run the whole Besu consortium network alone?
Yes, technically one organization can operate every node, but a consortium network is only as trusted as the process that governs it. The operator of all nodes controls validator keys, bootnodes, genesis changes and permissions files for every member, which other members will rarely accept. In most consortia each member runs its own validators and nodes, and a single operator runs the shared tooling, monitoring and upgrade coordination under written rules. Confirm with each member which decisions they want to hold for themselves before deciding who operates what.
What drives the effort and cost of a consortium Besu engagement?
Effort grows with the number of member organizations, the complexity of governance and the number of approvals each change needs. Other drivers are how keys are stored (plain key files versus hardware security modules), how often members onboard or leave, and how frequently calendar releases are rolled out across every operator. Cost components usually include discovery and design, build of the shared configuration, validator and node setup inside each member's environment, testing and handover, and any retainer for later upgrades. Ask for a quote that lists each member's environment separately, the onboarding steps assumed and the upgrade cadence covered.
What must the consortium provide before a partner starts work?
The consortium must name accountable owners, record decisions and grant access to each member's environment. Named owners should cover the genesis and upgrade decisions, validator and bootnode ownership, and the approver for permissions changes. A decision record should hold agreed values such as validator set, block time, gas settings and the Besu version to run. Each member should provide access to its cloud account, data center or closed network, plus its own security and change-management contacts. Without these, scoping cannot be fixed in writing.
How long does a multi-organization Besu engagement take?
Duration depends on the written scope, not on a fixed figure. The main variables are how many members must agree on the design, how many environments need access and onboarding, whether a migration from an older consensus or privacy setup is included, and how many test rounds the consortium wants before go-live. Ask for a timeline that shows which work waits on member approvals, since those waits often set the schedule more than engineering does. Ask for milestones tied to each member's sign-off rather than a single end date.
Can consortium members run this network without a partner?
Members with experienced Besu and Kubernetes or infrastructure teams can run their own nodes, but the hard part is agreement across organizations. Each member must keep its node permissions file consistent with the consortium list, and account permissioning rules must match across operators. Since Besu removed Tessera, onchain permissioning and Clique, members also need current guidance on what the chosen release supports. Ask whether your team has capacity to follow each Besu release, which the project publishes roughly monthly, and to test upgrades before production.
Who signs off on permissions changes in a shared network?
The consortium should decide this in writing, and the approval should be a named role rather than an individual. Besu enforces permissions locally on each node, so a change agreed by the group still has to be applied by every member's operator. Node permissioning restricts which peers connect, and account permissioning controls onboarding, suspension and allowed actions. A common control is a change request that lists the affected nodes, requires approval from each member's security owner, and records the date each node applied it. Ask your partner how it will evidence that every node applied the same file.
What breaks most often when several organizations share a Besu network?
The most common failures come from configuration drift and unsynchronized change. A node with an outdated permissions file or genesis value may refuse peers or fork from the group, and a member that upgrades Besu without coordination can leave others unable to open a newer database. Bootnode changes that are not shared can stop new nodes from joining. Ask for configuration kept under source control, a rehearsed upgrade in a non-production environment, and monitoring of peer counts and block production from the first day.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the infrastructure each client controls. For a multi-organization Besu network, we start by agreeing in writing who runs which node, who owns each key and how the shared genesis and upgrade decisions will be made before any build begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope maps each organization's nodes, validator and bootnode ownership, and which permissioning rules each node enforces locally.
- A quote follows from that written scope, so each participant can see what their own organization is paying for and what is shared.
How we build
- We build the network inside each organization's own cloud accounts, data centers or closed networks, as agreed in the scope.
- Genesis, node permissions, account permissions and JSON-RPC authentication are configured as version-controlled files that every party reviews.
- Test runs cover peer connections, validator failover, rejected transactions and a rehearsed Besu upgrade in a non-production environment before go-live.
How we hand over
- Each organization receives documentation for its own nodes, keys, backups and monitoring, along with the shared network runbook.
- Backups are taken and restore steps are tested, including the backup needed before any Besu upgrade, since older versions cannot open an upgraded database.
- Handover includes the decision log for genesis, validator set and upgrade choices, so later members can see why the network is configured as it is.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Support agreements should name which organization approves each upgrade, validator change and permissioning update on the shared network.
- Ask for a written support scope that covers calendar release reviews, monitoring response and recovery work when quorum is lost.
