How to use this permissioned blockchain requirements checklist
A bank, public body or manufacturer about to choose or build a permissioned ledger needs one list it can paste into an RFP and score bids against. This checklist gives that list. It covers members and governance, consensus and fault tolerance, identity and certificate authority design, key storage and HSMs, privacy between members, smart contract lifecycle, node hosting per member, monitoring and upgrade policy. Each requirement is grouped into functional, security, integration, operational or compliance areas, and each carries a verification method, so the reader can ask a bidder to demonstrate it rather than simply claim it.
Work through the list in order of the decisions it forces. Several requirements point toward one platform. For example, if members need a crash fault tolerant ordering service or a Byzantine fault tolerant one, the choice narrows between Hyperledger Fabric and Besu, and the identity model (Fabric CA with MSPs or node and account permissioning in Besu) follows from that. Record which requirements are non-negotiable, which are preferences, and who on each member's side owns the evidence. Confirm current release lines directly with the project and with any bidder, because release support windows change between versions. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so treat each verification method here as evidence to collect for them, not as a result DeployOpen can certify.
Functional requirements a permissioned ledger must meet first
This table sets out the functional requirements for a Fabric or Besu network across governance, consensus, contract lifecycle and member privacy, with a verification method for each. Use it to decide which requirements must be proven in a staging network before any member onboards, and which can wait for a later phase.
| Requirement | Why it matters | How to verify it |
|---|---|---|
| Members and governance | Every member needs written rights to admit, suspend or remove peers, orderers and identities. Without this, the network has no authority to change its own membership. | Review the governance charter against the MSP and permissioning configuration. Confirm that each change path has a named approver and a recorded decision. |
| Ordering and consensus choice | Fabric v3.0 added a BFT ordering service based on SmartBFT, which tolerates failures of up to, but not including, one third of ordering nodes. Raft is the documented recommendation and is crash fault tolerant only. | Confirm which consensus the charter requires. For Raft, stop nodes in staging and check that a five node cluster still orders after losing two. For BFT, test that the faulty node count stays below one third. |
| Besu consensus and validator set | Besu supports QBFT or IBFT 2.0 for private networks. Clique is no longer supported after Besu 26.4.0, so a pure Clique network cannot be carried forward unchanged. | Check the consensus setting in the genesis and node configuration. Run a staging test that halts one validator and confirms block production continues within the fault tolerance the chosen protocol provides. |
| Contract lifecycle and upgrades | Fabric v3.0 removed the v1.x legacy chaincode lifecycle, so all channels must be on the v2.x lifecycle before upgrading. Contract changes need approval from the members who must endorse them. | Run a sample chaincode or contract upgrade in a staging network with the same member set. Confirm that endorsement policies, approvals and rollback steps match the charter. |
| Privacy between members | Members often should not see each other's transactions or data. Fabric channels and private data collections, and Besu node and account permissioning, each limit visibility in different ways. | Map each data flow to a channel, private collection or permissioned node. Test from a non-member or unauthorized node that data and connections are refused. |
| Identity and certificate authority | Enrollment, renewal and revocation decide who can transact. Fabric CA issues enrollment certificates and generates certificate revocation lists, so revocation must be tested, not assumed. | Revoke a test identity in staging and confirm that it can no longer submit or endorse. Check that the revocation list is published to every member node. |
| Upgrade and rollback readiness | Fabric's upgrade guide starts with a backup of the ledger and MSPs. Besu 26.10.0 auto-upgrades the Bonsai database on first start, and older versions cannot open it, so rollback depends on a pre-upgrade backup. | Perform a restore from backup on a copy of the ledger. Confirm the time and steps needed, and that the upgrade order (orderers, peers, then channel capabilities) is documented. |
When Hyperledger Fabric fits and when Besu fits
Fabric fits when the network needs members to see only the data they are entitled to see. Its channels partition the ledger so that a subset of members can share transactions and state, and its Membership Service Provider model ties every peer, orderer and client to an identity issued by a certificate authority. Fabric CA registers identities, optionally against LDAP, issues and renews enrollment certificates, and publishes revocation lists, which is the identity design most consortium governance teams will need to document.
- Channel-based isolation: Members that share a channel see its transactions and state, so channel membership should map to the governance agreement.
- Fabric CA identity: Enrollment, renewal and revocation are handled by the certificate authority, so its operating model is a checklist item in its own right.
- Long-term support line: The documentation names v2.5 as the LTS release for production users, and v2.5.16 and v3.1.5 were both published on June 18, 2026, so patches arrive on both lines in parallel.
- Raft or BFT ordering: Raft is the documented recommendation and tolerates the loss of a minority of orderers, while SmartBFT in v3.0 tolerates fewer than one third of ordering nodes failing.
- Migration debt: v3.0 removed Solo and Kafka ordering and the v1.x chaincode lifecycle, so older networks need migration work first.
Confirm with the vendor and your own environment which LTS line your upgrade policy will follow, and whether your members need SmartBFT or Raft before choosing a node count.",
Besu fits when the team wants Ethereum-compatible tooling and a client that supports private networks using proof-of-authority consensus, QBFT or IBFT 2.0. Permissioning is configured locally on each node: a node permissions file restricts which peers it connects to, and an account permissions file controls onboarding, suspension and allowed actions. Governance therefore lives in configuration files and operational procedures rather than in a channel model, which changes how the consortium audits who can do what.
- Node and account permissioning: Each node holds its own permissions configuration, so changes must be rolled out and evidenced on every node.
- Calendar versions: Besu uses calendar version numbers and ships roughly monthly, with 26.10.0 published on October 16, 2026, so the upgrade cadence must be scheduled deliberately.
- JDK 25 requirement: Besu 26.6.0 requires JDK 25 to build and run, which shapes base images and patching.
- Removed features: Tessera privacy, onchain permissioning, Clique consensus and the EEA and PRIV privacy RPC groups have been removed, so designs that depended on them need redesign.
- Backup before upgrade: The Bonsai database upgrades on first start and older versions cannot open it, so a backup is the only rollback path.
Confirm which consensus mode and privacy approach your network needs, since privacy features have changed across recent releases, and agree the upgrade cadence with your platform team before selecting a version.
Use this tab to map checklist requirements to a platform. Requirements about member isolation, certificate lifecycle and long-term support usually point toward Fabric. Requirements about Ethereum tooling, proof-of-authority consensus and per-node permissioning usually point toward Besu. Requirements about upgrade cadence and runtime dependencies apply to both, but they weigh differently depending on the platform.
- Isolation of data between members: Points toward Fabric channels, or toward Besu only if privacy is designed separately and confirmed.
- Identity and certificates: Points toward Fabric CA for an integrated model, or toward node keys and external identity systems on Besu.
- Consensus and fault tolerance: Fabric offers Raft and BFT ordering, while Besu offers QBFT and IBFT 2.0 for private networks.
- Upgrade policy: Fabric's LTS line supports a slower cadence, while Besu's monthly releases need a faster, scheduled process.
- Runtime and tooling: Besu's JDK 25 requirement and Ethereum tooling compatibility point toward Besu teams with Java and Ethereum skills.
Confirm with each vendor and your own architects which platform matches your privacy, identity and upgrade requirements before the reference architecture is drawn.
Security requirements for keys, identity and access
A permissioned network is only as trustworthy as the keys, certificates and access rules behind each member's nodes. The cards below cover the controls a network needs before go-live, from HSM-backed keys to enrollment, permissioning and API authentication. For each one, the question to ask is how the control is evidenced, not only whether it exists.
HSM-backed node and signing keys
Each member's node identity and signing keys should be generated and held in a hardware security module (HSM) or an equivalent protected store, so private key material never sits in plain files on a node host. Fabric documents how to use an HSM with its peers, orderers and CA components, and each member should confirm which key types its HSM supports. Ask for a key ceremony record covering who generated each key, where it was generated, who witnessed it and where backups are held. Verify by requesting a restore test from a backup in a non-production environment.
Enrollment, revocation and CRLs
Fabric CA can use its own user registry or LDAP, issues enrollment certificates, handles renewal and revocation, and generates certificate revocation lists (CRLs). Membership is only as strong as the process for removing a member or compromised identity, so the revocation path must be written down and tested. Confirm who can approve an enrollment, how identity attributes are checked before issuance, and how quickly a CRL reaches every node. Verify with a revocation drill: revoke a test identity and confirm that its transactions are rejected across all peers and orderers.
Node and account permissioning
Besu uses local permissioning files on each node. Node permissioning restricts which peers can connect, and account permissioning controls onboarding, suspension of accounts and the actions each account may take. These files are configured per node, so changes made on one node do not automatically apply to others, which makes drift between members a practical risk. Ask for the permission configuration files under version control, a named owner for each change and a record of who approved each entry. Verify by attempting a connection and a transaction from an unlisted account and confirming both are refused.
Encryption in transit and at rest
Member data crossing external networks should be encrypted in transit, and data stored on node hosts, backups and HSM-protected stores should be encrypted at rest. The FTC Safeguards Rule at 16 CFR 314.4 requires these protections for covered financial institutions, and networks serving other sectors often face comparable expectations. Confirm which channels carry peer-to-peer, orderer and client traffic, which certificates secure them and who rotates them. Verify by reviewing a configuration export and a sample of backup files to confirm encryption is applied to the stored data.
MFA and logging of authorized user activity
Every person who can reach a node, its administration interface or its keys should authenticate with multi-factor authentication, and their actions should be logged. Under 16 CFR 314.4, covered institutions must implement MFA for any individual accessing an information system and must log the activity of authorized users. Confirm which administrative paths are behind MFA, where logs are sent and who can alter them. Verify by selecting one administrator account, performing a configuration change and checking that the change appears in the central log with the correct user identity.
JSON-RPC authentication for Besu
Besu exposes a JSON-RPC interface that clients use to submit transactions and read state, and this interface must not be left open to unauthorized callers. Besu supports authentication for JSON-RPC requests, and each member should confirm which methods are exposed, on which interfaces and to which callers. Keep node keys and the RPC credentials under the same controls as other signing material. Verify by sending an unauthenticated request to a non-public RPC endpoint and confirming it is rejected, then recording the result in the security test file.
How to test a bidder's answers before you sign
This sequence turns the checklist into evidence you can compare across bidders. Each step asks for a written artifact or a walkthrough tied to a requirement, so you can see whether a proposal holds up before any contract is signed.
Request a written member onboarding design
Ask each bidder for a written design covering how a new member is admitted, which identities and certificate authority configuration it receives, and how node permissioning and account permissioning are set for that member. Ask who approves admission and who can suspend a member. The step is complete when the design names the Fabric CA or Besu permissioning files that will hold each rule, and your governance group has reviewed it against the membership and governance requirements in the checklist.
Confirm the consensus and fault tolerance choice
Ask the bidder to state which ordering or consensus service it will run, how many ordering nodes each member hosts, and how many node losses the design survives. Compare the answer with the Fabric ordering guidance and the Besu consensus options in the checklist. The step closes when the bidder's node count and failure tolerance are written into the design and your team can recalculate the tolerance from that count.
Run a tabletop upgrade from the 2.5 LTS line to 3.x
Ask the bidder to walk your team through a tabletop exercise that starts on a Fabric v2.5 LTS network and ends on the 3.x line. The walkthrough must show the Kafka-to-Raft ordering migration, the move of every channel to the v2.x chaincode lifecycle, and the rolling orderer and peer upgrades in order. Record each step and who signs it off. The step is complete when the bidder can name the preconditions it will check before the first binary is replaced.
Test the backup and rollback plan for Besu
Ask the bidder how it will take and verify a backup before any Besu upgrade, given that the Bonsai database upgrades automatically on first start and older versions cannot open the upgraded database. Ask for the restore runbook, where backups are stored, and who can authorize a rollback. A useful test is to ask for the restore steps on a non-production node and observe the result. The step is complete when the bidder shows that rollback depends on the backup and not on reverting the binary.
Check how keys and HSM use fit the design
Ask the bidder where each member's signing and node keys are generated, stored and backed up, and whether an HSM is used for them. Ask how the design handles certificate renewal and revocation through Fabric CA, and how a compromised key is replaced. The step closes when the answers are written against the key storage requirement and your security team confirms that the key lifecycle is documented.
Verify monitoring coverage across every member
Ask the bidder to map which metrics, logs and health checks run on each member's peers, orderers and validators, and who receives alerts for each member. Ask how a failing node at one member becomes visible to the others, and what each member can see without exposing its private data. The step is complete when the coverage map has an owner for every node and every alert path, and each alert has a documented response.
Compare the upgrade policy with the evidence you need
Ask the bidder for its written upgrade policy, including how it tracks LTS and patch releases, how it applies Besu release changes, and how each change is recorded as change management evidence. Compare the policy with the change management and logging expectations in the checklist. The step closes when every bidder has answered the same questions in writing and you can compare the answers side by side.
Integration requirements with existing systems
A permissioned ledger rarely works alone. Client applications, ERP and accounting systems, identity providers and signing services all need a defined path into the network. Each connection below needs an owner, an access model and a confirmed capability before the network design is final.
Client applications through the Fabric Gateway
Business applications submit transactions and read state through the Fabric Gateway client API, which is compatible with both Fabric v2.5 and v3.0. That compatibility lets client applications be upgraded separately from the network, so an application release does not force an orderer or peer change. Confirm which gateway version your applications use, whether your application language libraries are maintained for your chosen Fabric line, and who owns the release schedule for each side. Map every application to a channel and a chaincode it is allowed to invoke.
External signing and key services
Node and identity keys should stay in an HSM or a key service you control, not in application code. Fabric supports hardware security module integration for keys used by its components, so confirm which keys your design places in the HSM, which the operator can export, and how signing requests from client applications are authorized. Ask the partner how signing latency, HSM failover and key ceremonies are handled, and who holds the administrative credentials for each partition.
Identity provider integration
Fabric CA can use LDAP as its user registry, so enrollment can follow the directory your organization already runs. Decide whether your identity provider or Fabric CA is the source of truth for member identities, and how joiners, leavers and role changes flow into certificate issuance and revocation. Confirm that revocation lists are published to every peer and orderer in time to matter. Besu needs its own answer for JSON-RPC access, which should be checked against the authentication options in its documentation.
ERP and accounting system connectors
Postings from ERP and accounting systems must reach the ledger without duplication or gaps. Connectors typically sit between the ERP's outbound events or database and a Fabric client application, and must handle retries, idempotency keys and failed endorsements. Confirm whether your ERP vendor supports the integration pattern you need, whether the connector is custom or existing, and who tests reconciliation between the ERP ledger and the permissioned ledger. Agree on which system is the system of record for each transaction type.
Event and reporting feeds to finance and compliance
Finance and compliance teams need evidence of what was committed, when and by whom. Plan event feeds from peers and client applications into the reporting tools and archives your auditors use, and keep them separate from operational paths. Confirm that the record retention periods required for your jurisdiction are met by the archive, not only by the ledger, and that the feed can be replayed after a node restore. The SEC's Rule 17a-4(b) sets retention periods for broker-dealer records, so confirm with counsel whether ledger-derived records fall within scope.
API access control and rate limits
Every API that exposes the ledger needs its own access rules, separate from the network's permissioning. Besu documents node permissioning, which restricts connections to known participants, and account permissioning, which governs onboarding and suspension of accounts. Confirm how your JSON-RPC endpoints are exposed, whether they sit behind a gateway with authentication, and how access is logged and reviewed. Ask the partner which access controls are configuration, which need custom code, and how permission changes are approved and recorded.
Operational requirements: hosting, monitoring and upgrades
This table compares the operational requirements a permissioned ledger network must meet after launch, from node hosting and ordering availability to backups and upgrades. Each row names how to verify the requirement, so you can test a partner's answer against evidence rather than assurances. The main takeaway is that a network is only as recoverable as its last tested restore, and every member's node carries that obligation.
| Requirement | What it asks for | How to verify it |
|---|---|---|
| Node hosting per member | Each member runs its own peers, and orderers or validators where it has a governance role. Define in writing which member operates which node, in which account or data center, and who holds node keys. | Request the node placement matrix and the signed network governance document. Confirm each member can name its operator and hosting location. |
| High availability for ordering or validators | Fabric's recommended Raft ordering service is crash fault tolerant and works while a majority of nodes are up, so a five node cluster tolerates two failures. Fabric v3.0 also offers a BFT ordering service (SmartBFT) that tolerates failures below one third of orderers. Besu QBFT or IBFT 2.0 networks depend on validator quorum. | Run a planned failover test: stop orderers or validators one at a time and confirm transactions continue above quorum and halt below it. Record the results. |
| Operations and metrics endpoints for monitoring | Each node exposes an operations or metrics endpoint for health and performance data. Agree which metrics each member shares with the network operator, and who receives alerts when a node falls behind or a certificate nears expiry. | Confirm the endpoints are scraped into a central dashboard, and ask for a sample alert triggered by a deliberately stopped peer. Check that endpoints require authentication. |
| Backup and restore of ledger and MSPs | Back up the ledger and the MSP directories before every upgrade, and on a regular schedule. Besu's Bonsai database upgrades automatically on first start and older versions cannot open it, so a pre-upgrade backup is the only rollback path. Store backups with the key material's access controls. | Perform a restore test into an isolated environment, rebuild a node from backup, and confirm it resynchronizes to the same ledger height and identity state. Repeat on a set schedule and log the results. |
| Upgrade policy: rolling upgrades | Fabric's upgrade sequence is back up, upgrade orderers in a rolling fashion, upgrade peers in a rolling fashion, then raise channel capability levels. Besu releases roughly monthly, so define which releases each member adopts and how quickly. | Ask for a written upgrade runbook and a staging network that mirrors production. Confirm the rollout order, rollback steps and the approval record for each change. |
| Upgrade policy: capability levels | Channel capability levels are raised only after all binaries are updated. Raising them early can lock out nodes that have not upgraded, so the decision needs a joint sign-off from members. | Check the change record for the capability update and confirm every member's node version before the change. Keep the approval in the governance log. |
| Upgrade policy: version support | Fabric v2.5 is the long-term support release for production users, and v3.x receives patches in parallel. Fabric v3.0 removed Solo and Kafka ordering and the v1.x legacy chaincode lifecycle, and Besu has removed Tessera privacy, onchain permissioning and Clique. Define which line each member runs and the date it will move. | Ask the partner for a support calendar tied to vendor release notes, and a migration plan for any removed feature still in use. Confirm which versions are in production today. |
| Client application compatibility | The Fabric Gateway client API works with both v2.5 and v3.0, so applications can be upgraded separately from the network. Besu's JSON-RPC access needs authentication and its own release tracking. | Test client applications against the target network version in staging, and confirm the API authentication settings survive the upgrade. |
Which compliance requirements apply and what evidence they need
The first question for any permissioned ledger is whether it will hold regulated records at all. If it will, two US rules are the most likely to reach it: the FTC Safeguards Rule at 16 CFR 314.4, which applies to covered financial institutions, and SEC Rule 17a-4(b), which applies to broker-dealers. The Safeguards Rule asks for encryption of customer information in transit over external networks and at rest, multi-factor authentication for anyone accessing an information system, change management procedures, and logging of authorized user activity. For a Fabric or Besu network, that means evidence for TLS settings on peer and orderer endpoints, encryption of ledger and key storage, MFA on the administrative paths into node hosts and HSM consoles, a documented change process for chaincode and node upgrades, and log retention for enrollment, invocation and administrative actions. Where continuous monitoring is not in place, the rule also expects penetration testing every year and vulnerability assessments at least every six months under 16 CFR 314.4(d)(2).
SEC Rule 17a-4(b) is the retention question. It requires broker-dealers to preserve certain records, including bills receivable or payable, bank statements and originals of business communications, for not less than three years, with the first two in an easily accessible place. A ledger that becomes the book of record for any of these records needs a retention design that survives node replacement, Fabric or Besu version changes and a Besu database upgrade, which cannot be opened by older Besu versions. Decide early whether the ledger is the system of record or a copy, because that choice determines which backups, archives and exports must be retained and tested. Ask your counsel which record categories are in scope and ask your auditor which evidence they will sample.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration baselines, access reviews, test reports and change records. It does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. Confirm applicability with counsel and your auditor before you scope the network, because a member that is not a covered institution or broker-dealer may face different obligations, and the same ledger may serve members in different positions.
What buyers ask before hiring help with a permissioned ledger
What drives the cost of meeting this permissioned ledger checklist?
The main drivers are the number of members, the nodes each member runs, the HSM and key设计 choices, the governance work across members, and the amount of testing before go-live. Neither Hyperledger Fabric nor Besu carries a license fee, so the cost sits in people, infrastructure and external services. Each member pays for its own nodes, hardware or cloud capacity, and HSMs. The network as a whole pays for governance workshops, identity and certificate authority design, and smart contract development and review. Ask for a written scope that lists members, nodes per member, HSM model and count, which contracts are in scope, and which testing is included. Those items are what separate one quote from another.
How long does a permissioned ledger rollout take?
No duration can be stated from the research available here, so treat any figure you hear with caution. The length of a rollout depends on how many members must agree on governance and onboarding, how many nodes each member hosts, whether HSMs and certificate authorities must be procured, and how many smart contracts need development and review. Fabric's ordering service choice (Raft or the BFT option added in v3.0) also affects the design work. Ask the partner for a phased plan with milestones tied to named member sign-offs, and ask which steps depend on other members' readiness, since those are the usual sources of delay.
What does the work need from our own team?
Your team needs to supply decisions and access that only your organization can give. These include the business rules for membership and account onboarding, the names of the people who approve changes, the infrastructure where your nodes will run, and the policy for who holds keys and how they are protected. Engineers should be available for network connectivity, identity integration, logging and monitoring, and change management. Expect to name an owner for each node and for the governance process. Ask the partner to list these inputs in the written scope, with an owner and a due point for each, so that the schedule is not limited by unanswered questions.
Can our internal team run a permissioned ledger without an outside partner?
A capable internal team can run a network, but the question is whether it has the skills and capacity to cover the full checklist and keep it covered over time. The work spans consensus and fault tolerance design, certificate authority operations, HSM-backed key management, monitoring, upgrades and multi-party governance. Fabric's documentation recommends the Raft ordering service and describes four upgrade steps, and Besu's releases are frequent, so someone must watch the release calendar and test each change. Assess your team against each checklist area and decide which parts you will own. Many organizations keep governance and operations in-house and buy design reviews, testing or upgrade support.
How do upgrades affect a running permissioned network?
Upgrades can change how the network behaves, so they need a plan that covers every member. For Fabric, the upgrade guide describes four steps: back up the ledger and MSPs, upgrade orderers in a rolling fashion, upgrade peers in a rolling fashion, then update channel capability levels. Fabric v3.0 removed Solo and Kafka consensus and the legacy chaincode lifecycle, so Kafka ordering must move to Raft and channels must move to the v2.x lifecycle before upgrading. Besu's 26.10.0 release notes state that its Bonsai database auto-upgrades on first start and older versions cannot open it, so a backup taken before the upgrade is the only rollback path. Ask the partner how it coordinates upgrade windows across members, which release line it follows (Fabric v2.5 LTS or the 3.x line), and how it tests upgrades before production.
Which parts of the checklist carry the most compliance risk?
The areas with the most exposure are key storage, identity and access, change management and activity logging. Regulated institutions often map these to rules such as the FTC Safeguards Rule at 16 CFR 314.4, which requires encryption of customer information, multi-factor authentication for system access, change management procedures and logging of authorized user activity. The same rule requires penetration testing and vulnerability assessments at least every six months where continuous monitoring is not effective. Recordkeeping duties, such as those in SEC Rule 17a-4(b) for broker-dealers, may apply to ledger records. Confirm with your compliance team which obligations apply to your entity before you write the scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
What should a written scope for this work include?
A written scope should name every member and node, the identity and certificate authority design, the HSM model and key custody approach, the contracts and their upgrade rules, the monitoring stack, and the upgrade and backup policy. It should also list testing, documentation and handover items, and say which items are one-time and which recur. DeployOpen works on fixed-scope engagements agreed in writing before work starts, and offers ongoing support, upgrades and continuous testing as retainers. Ask for a deliverables list, acceptance criteria per deliverable, the member decisions required and the assumptions behind each estimate. Any quote should trace back to that scope.
Does a permissioned ledger need ongoing support after go-live?
Yes, a live network needs continuing work, and the cost of that work is usually recurring. Activities include monitoring node health, rotating certificates and keys, applying patch releases, planning version upgrades, and reviewing access changes as members join or leave. Fabric publishes patch releases on its 3.x and 2.5 LTS lines in parallel, and Besu ships roughly monthly, so the release cadence itself is a cost driver. Ask the partner whether support is a fixed retainer, what response expectations it covers, and which upgrade work is included. Retainers for ongoing support, upgrades and continuous testing are available from DeployOpen.
Turning the checklist into a selection decision
The first decision is not Fabric or Besu. It is which requirements are must-have, which are should-have and which can be confirmed later with the platform maintainers or your implementation partner. Must-haves are the items that would force a different design if they changed: who the members are, whether a member can be excluded, where personal or confidential data may sit, which signing keys must live in an HSM, and whether a supervisor or auditor needs to read the ledger directly. Should-haves shape operations, such as the number of ordering nodes per member or the upgrade cadence. Confirm-later items are details that depend on a vendor roadmap, such as a feature that may be sunset or a version line that may change, and they should be written down with an owner and a date to check.
Once the must-haves are fixed, the platform choice follows from the requirement profile rather than from a feature comparison. Hyperledger Fabric fits networks where members need channel-level data separation, a consortium-style identity model built on Fabric CA or an external registry, and a long-term support line for production. Its documentation recommends Raft ordering and describes a BFT ordering option in v3.0, so the fault tolerance you need should be matched to the ordering service you can actually staff. Besu fits networks that want Ethereum-compatible tooling and proof-of-authority consensus such as QBFT or IBFT 2.0. Ask both sets of maintainers which consensus options, privacy mechanisms and permissioning models are supported in the version you plan to run, because Besu has removed several privacy and permissioning features in recent releases. Feature lists alone will not reveal those removals or the operating burden behind them.
Governance usually takes longer than the technical build, so start it first. Membership rules, onboarding and suspension of members, who may change chaincode or contract logic, how keys are rotated, and who pays for each node are agreements among organizations, often with legal and compliance review on each side. Draft the governance charter and the permissioning policy before choosing hosting or software versions, because both depend on the answers. Expect to revisit the platform decision only if the governance outcome changes a must-have, not because a feature looked more attractive during evaluation.
How DeployOpen scopes, delivers and supports permissioned ledger work
DeployOpen turns a permissioned ledger requirements checklist into a written scope covering members, identity, keys, node hosting and upgrade policy before any build starts. The work runs inside the client's own cloud accounts, data centers or air-gapped networks, with the open-source Hyperledger Fabric or Besu platform deployed and handed over as documented systems.
How we scope
- Written scope lists the members, channels or permissioning model, and node count each member will operate.
- Requirements for identity, certificate authority design, HSM-backed key storage and privacy are agreed before build.
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before work begins.
How we build
- Nodes, ordering or validator services, certificate authorities and monitoring are deployed in the client's own infrastructure.
- Permissioning configuration, smart contract lifecycle steps and upgrade runbooks are written and tested against the agreed scope.
- Security testing covers the network and its interfaces before the network is accepted for use by members.
How we hand over
- Handover includes architecture records, configuration, key custody procedures and the member onboarding and upgrade runbooks.
- Evidence for change management, access logging and backup restoration is documented for the client's assessors.
- Each member receives the operating documentation needed to run its own nodes after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover patching across the Fabric 2.5 LTS or 3.x lines and planned Besu release adoption.
- Clients confirm with DeployOpen which support tier, response expectations and upgrade cadence are included in the quote.
