Hyperledger Besu vs Corda: when each platform is the right choice
Choose Besu when your network needs Ethereum tooling and EVM smart contracts on a permissioned network, and choose Corda when your data must stay between the parties to each deal. Besu gives every member a shared ledger that runs Ethereum-style transactions, while Corda shares state only with the parties involved in a flow and uses notaries to check that a state is not spent twice. Before comparing features, settle three questions: does the business need ledger state that every member can see, does the team have JVM or Solidity skills, and how much of the privacy model will your own engineers build?
The first question usually decides the architecture. If members are meant to read the same state and the consortium values one shared view, Besu's model fits, and its permissioning controls (node permissioning and account permissioning, configured per node in a permissions file) govern who connects and who can transact. If each bilateral or multi-party agreement must remain invisible to other members, Corda's point-to-point flows and notary design are built for that purpose, and you should confirm how notary ownership and availability will be run before committing. Note that Besu's onchain permissioning and Tessera privacy have been removed, so confirm current privacy options against the Besu documentation rather than relying on older guides.
The second question is about people. Besu runs on the Java stack and expects operators to handle JDK 25 for recent releases, while smart contracts are typically written in Solidity, which suits teams already building on Ethereum. Corda contracts are written in Java or other JVM languages and distributed applications are called CorDapps, so a JVM team will ramp faster there. Ask your engineers which language they will write contracts in for the next two years, and plan a short spike on your chosen platform before fixing scope in a written statement of work.
Which platform fits which institution scenario
This table maps common institution scenarios to the platform that fits better, tying each choice to Besu's shared ledger model or Corda's peer-to-peer flows with notaries. Read the reason column first, then check the confirm column for points that depend on facts you must verify with the vendor or your own environment.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Consortium sharing one common ledger where all members read the same state | Hyperledger Besu | Besu runs one shared Ethereum-compatible ledger that participants replicate, and QBFT is the recommended proof of authority option for private networks. Confirm governance of node and account permissioning in your own configuration. |
| Bilateral trade finance where counterparties must not see each other's deals | Corda | Corda shares data only with transaction participants over peer-to-peer flows, so a deal is not broadcast to the whole network. Confirm your privacy requirements against the flow design you build. |
| Ethereum-skilled team building a permissioned network | Hyperledger Besu | Besu is an Ethereum execution client written in Java, so Solidity-style tooling and Ethereum APIs carry over. Corda contracts are written in Java or other JVM languages, which your team would need to learn. |
| JVM-heavy bank with existing Kotlin or Java engineers | Corda | Corda itself is written in Kotlin on the JVM and CorDapps use Java or other JVM languages, so existing skills and build pipelines transfer. Besu also requires JDK 25 to build and run, which your platform team should check against its Java standards. |
| Network that needs a notary to order and check transaction uniqueness without global broadcast | Corda | Corda's notary validates uniqueness and sequencing without broadcasting transactions to all nodes, a model suited to regulated bilateral activity. Confirm which notary implementation and fault tolerance model your network will use, since this is a design decision for your architecture. |
| Regulated institution that needs a vendor-supported long-term roadmap for Corda 5 | Depends on support model: confirm before choosing | Corda 5 is developed and maintained by R3 under Apache-2.0, while the open source Corda 4 line is tagged at release-os-4.14.3. Ask R3 and your implementation partner for the support window, upgrade path and commercial terms for the version you plan to run. |
How Besu and Corda are built and what that means for operations
Besu and Corda solve the shared-data problem in different ways, and that difference sets what your team runs day to day. Besu is a node you operate alongside a consensus setup, while Corda splits work across node identities, flows, notaries and a language runtime. The cards below cover what each component asks operators to run, patch and verify.
Besu execution client and QBFT
Besu runs as a Java execution client, and on a private network your nodes agree on blocks through proof of authority. The Besu consensus documentation recommends QBFT as the enterprise-grade option and also supports IBFT 2.0. Operators own the validator set, the key material for each validator, and the choice of consensus protocol before go-live. Clique is no longer supported, so any older network built on it needs a plan before upgrading. Confirm which protocol and validator set your consortium will sign off on before you build.
Corda node and flow framework
Each Corda node is a party's own runtime that holds its vault and runs CorDapps. Flows define how two or more parties negotiate and sign a transaction over the peer-to-peer network, so there is no global broadcast of every transaction. Operators run one node per legal identity, manage its network connectivity and certificates, and update CorDapps in step with counterparties. Ask whether your counterparties will run the same Corda major version, since flows must interoperate across them.
Notary uniqueness and sequencing
A notary service checks that each state is consumed only once and that transactions are sequenced, without broadcasting the full transaction to the network. Choosing a notary is an operational decision: you decide whether it is run by your institution, a consortium member or a third party, and whether it is clustered for availability. Notary downtime can stall transactions that need its signature, so confirm recovery procedures, clustering and the notary's change process with your consortium before production.
Corda 4 and Corda 5 split
The original Corda architecture, covering Corda versions 1 through 4, lives in the corda/corda repository, while the second architecture sits in corda-runtime-os and forms the basis of Corda 5. Teams building new work need to know which line their vendors, CorDapps and tooling target before they commit. The most recent Corda 4 open source tag in the repository is release-os-4.14.3. Verify which architecture your chosen CorDapps and support contracts cover before deciding.
Java and Kotlin runtime requirements
Besu 26.6.0 requires JDK 25 to build and run, so Besu upgrades bring a JVM upgrade with them. Corda is written in Kotlin for the JVM, and its smart contracts are written in Java or other JVM languages. Your platform team therefore maintains JVM versions, dependency scanning and build pipelines for both stacks, and must check that each release lands on a supported runtime. Ask each vendor for its tested JDK matrix before you size your build and patch cycle.
Capability comparison: data model, languages, identity and tooling
This table compares how Hyperledger Besu and Corda handle data sharing, consensus or notaries, languages, permissioning, flows and release lines. Read each row against your own privacy requirements, since the two platforms solve confidentiality in fundamentally different ways. The main takeaway is that Besu fits teams that want an Ethereum-style shared ledger, while Corda fits teams that need transaction data limited to the parties involved.
| Capability | Hyperledger Besu | Corda |
|---|---|---|
| Data sharing model | Shared ledger: a permissioned network where nodes replicate the chain state under the network's rules | Peer-to-peer: transactions are shared only with the parties and counterparties that need them, with no global broadcast |
| Consensus or notary mechanism | Proof of authority on private networks using QBFT (recommended) or IBFT 2.0; Clique and Ethash are no longer supported | Notary infrastructure validates uniqueness and sequencing of transactions without global broadcast; confirm notary service options and high availability with R3 |
| Smart contract languages | Solidity and other EVM tooling, since Besu is an Ethereum execution client; confirm which EVM toolchains your team will use | Java and other JVM languages; Corda itself is written in Kotlin and targets the JVM |
| Network permissioning | Local permissioning files: node permissioning limits connections to known participants; account permissioning governs onboarding, suspension and restricted actions | Permissioned network with identity and network membership managed at the platform level; confirm the membership service and certificate model with R3 |
| Application model and flows | Applications are Ethereum smart contracts and off-chain services; no built-in peer-to-peer flow framework is described in the supplied facts | Flow framework manages communication and negotiation between participants; distributed applications are called CorDapps |
| Licensing | Apache-2.0 | Corda 4 repository under Apache-2.0; Corda 5 made available under Apache-2.0 by R3 |
| Current release line | Calendar versioning, roughly monthly; 26.10.0 released October 16, 2026, and requires JDK 25 | Corda 4 open source tag is release-os-4.14.3; Corda 5 is built on a second architecture in corda-runtime-os; confirm the current support window with R3 |
What the licenses and release lines mean for each platform
Besu is an Apache-2.0 licensed Ethereum client written in Java. The project is a Graduated project of LF Decentralized Trust, the Linux Foundation organization that now hosts the Hyperledger projects, and its source lives in the besu-eth/besu repository. Because the code is Apache-2.0, your team can run, modify and distribute it without a license fee for the software itself. Release numbers follow a year.month scheme and the project ships roughly monthly, so the latest supplied release is 26.10.0, dated October 16, 2026.
- License: Apache-2.0 for the client, with no paid edition described in the supplied facts.
- Governance: LF Decentralized Trust is the home project, with a Graduated status that signals an established governance process.
- Release cadence: Calendar-based versions with roughly monthly releases, so upgrade planning is continuous rather than annual.
- Runtime requirement: The 26.6.0 release notes state that Besu requires JDK 25 to build and run.
- Upgrade caution: The 26.10.0 notes say the Bonsai database auto-upgrades on first start and older versions cannot open it, so take a backup before upgrading.
Before committing, confirm with the LF Decentralized Trust project and the release notes how long each release line receives fixes, and plan a test environment that tracks the monthly cadence.
The first Corda architecture lives in the corda/corda repository and covers Corda versions 1 through 4. The repository is licensed under Apache-2.0, and the most recent Corda 4 open source tag is release-os-4.14.3. Corda itself is written in Kotlin and targets the JVM, and smart contracts can be written in Java and other JVM languages. For a team that wants an open source Corda footprint, this line is the one with a published, Apache-2.0 release tag you can pin and audit.
- License: Apache-2.0 for the corda/corda repository.
- Latest tag: release-os-4.14.3, the most recent Corda 4 open source tag in the repository.
- Language stack: Kotlin on the JVM, with CorDapps written in Java or other JVM languages.
- Scope of the line: It is the first architecture, so it is a different codebase from the Corda 5 runtime.
- Commercial terms: The supplied facts do not cover paid editions or support tiers for this line.
Ask R3 or the vendor which Corda 4 releases they still support, what security fix policy applies, and whether any commercial support exists for the open source tag.
Corda 5 is built on the second architecture, which lives in the corda-runtime-os repository. The supplied facts describe it as a scalable, permissioned peer-to-peer distributed ledger platform for regulated markets, developed and maintained by R3 and made available under Apache-2.0. Since it is a separate runtime and not an upgrade of the Corda 4 codebase, the license and release history of the two lines should be evaluated separately.
- License: Apache-2.0 for the corda-runtime-os repository.
- Maintainer: R3 develops and maintains the platform, which makes R3 the primary point of contact for roadmap questions.
- Architecture: A second-generation runtime that forms the basis of Corda 5, distinct from the Corda 4 repository.
- Release line: The supplied facts do not give a Corda 5 version or release date, so check the repository tags directly.
- Commercial terms: Paid editions, enterprise support tiers and service levels are not covered by the supplied facts.
Confirm with R3 the production support status of Corda 5, the compatibility path from Corda 4 CorDapps, and the commercial support terms in writing before you plan a rollout.
What drives running cost on each platform
Running cost for Besu and Corda comes from different places: node and consensus infrastructure on one side, notary and node hosting plus JVM expertise on the other. The cards below separate what is paid once from what recurs, and list what to ask for in any quote.
Infrastructure footprint
Besu runs as a set of nodes that each hold a full copy of chain state, with a consensus participant set (QBFT or IBFT 2.0) that you size and operate. Corda runs node hosting for each participant plus notary services that validate transactions without global broadcast. Ask any integrator to price the node count, database storage per node, and whether notaries are shared, clustered or per-party. Those choices set most of the recurring infrastructure bill.
Skills and talent pool
Besu uses the EVM and Solidity skills that a large developer market already has, and its client is written in Java. Corda uses Kotlin and Java on the JVM, with its own flow framework and CorDapp conventions, so the pool of engineers who already know it is smaller. Ask who will write and review contracts after go-live, and whether that cost is in your budget as a salaried role or as a retained vendor engagement.
Besu upgrade cadence
Besu ships on a calendar version line and releases roughly monthly, so upgrades are a recurring task rather than an occasional project. The 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older versions cannot open the upgraded database. Budget for a pre-upgrade backup on every node and a tested rollback path, because restoring a backup is the only way back.
Corda version line changes
Corda's first architecture lives in the corda/corda repository for versions 1 through 4, while Corda 5 comes from the separate corda-runtime-os repository and is a different architecture. Moving between these lines is a migration project, not a routine patch. Ask R3 or your integrator for the support window of the line you select, and whether your CorDapps must be rewritten or can be ported.
Support and licensing
Both platforms are Apache-2.0 open source, so software licensing itself is not the recurring cost. The recurring cost is paid support, which you buy from a vendor, a foundation member or an implementation partner under a separate contract. Confirm in writing what the support covers, response expectations, and whether any commercial distribution or add-on carries its own license terms.
One-time versus recurring spend
Implementation, network design, and CorDapp or chaincode build are one-time costs that you pay a partner to deliver under a fixed scope. Operations, monitoring, patching, upgrades and on-call are recurring. Ask any quote to split these lines, to state who holds the keys and notary identities, and to name the hours or retainer that cover upgrades after go-live.
Moving a permissioned network from Besu to Corda or back
This sequence gives a consortium a defensible path between a shared-ledger Besu network and a peer-to-peer Corda network, with each move ending in documented, tested state that both sides have signed off. The work is mostly redesign rather than data copying, so the order below is built to surface that redesign early.
Inventory data, contracts and participants
Start by listing every smart contract, the state it holds, the accounts and nodes that interact with it, and the off-chain systems that read or write to it. Record which business rules live in code and which live only in legal agreements or runbooks. Assign an owner to each participant and confirm who has authority to approve a change. The step is done when the consortium signs off one inventory that every participant recognizes, because each later step depends on it.
Map shared state to bilateral flows
Besu keeps one shared ledger that every node can read, while Corda moves data through flows between the parties to a transaction. For each contract state, decide which participants need to see it, who must sign, and whether a third party needs a copy. Going the other way, identify where a Corda flow relied on a shared view and decide how to replace it with an explicit publication step. The output is a flow map that lists each interaction, its counterparties and its required signatures. Review it with legal and compliance before any code is written.
Rebuild identity and permissioning
Besu's local permissioning uses a node permissions file for connections and an account permissions file for onboarding and suspension, so those rules must be re-expressed in Corda's identity and network model. Confirm how each participant's keys are issued, stored and rotated under your key policy, and confirm how the target platform handles membership changes and revocation. Test that a removed participant cannot transact on the new network. The check is a written access matrix that matches the inventory from the first step.
Plan the notary and its availability
Corda's notary validates the uniqueness and ordering of transactions, so any move to Corda needs a decision about which notary service runs, who operates it, and what happens when it is unavailable. Moving from Corda to Besu removes the notary but adds a consensus layer, which needs its own validator set and fault tolerance decision. Ask the platform vendor or your implementation partner to confirm the notary options available in your edition and version. The step is complete when the notary design is documented and reviewed by the operators who will run it.
Rebuild contracts in the target language
Solidity contracts on Besu do not run on Corda, and Corda CorDapps are written in Java or other JVM languages, so each contract must be rewritten rather than translated line by line. Reimplement the business rules recorded in step one, and keep a traceability table that links each rule to its new code and test. Rebuild integrations, node configuration and monitoring for the target platform at the same time. The output is a versioned code base with a test suite that proves each rule still holds.
Back up before any upgrade
Before any upgrade or migration step on the Besu side, take a full backup of the node data. The Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older Besu versions cannot open an upgraded database, so rollback depends entirely on that backup. Test the restore procedure on a separate node before relying on it. The step is done when a restore has been rehearsed and the backup location, retention and owner are recorded.
Run parallel testing against live-like data
Run the old and new networks side by side with the same test transactions, including failure cases such as a rejected signature, a notary outage or a removed participant. Compare resulting states, not only success or failure messages, and record every difference. Involve the business owners who will sign off on outcomes. The check is a reconciliation report showing zero unexplained differences across the agreed scenarios.
Cut over and retain the rollback path
Schedule the cutover with every participant, freeze writes on the source network, migrate the agreed records, and switch integrations to the new platform. Keep the source network read-only and its backup available for an agreed period set in the cutover plan. Confirm with each participant that their systems read the new ledger correctly. The step closes when the consortium signs a cutover record and the decommissioning plan for the old network is approved.
Where Besu and Corda implementation projects usually run long
Besu projects tend to run long in network design, not in installing the client. The consensus choice comes first: the Besu consensus documentation recommends QBFT for enterprise private networks, and Clique is no longer supported, so any network built on Clique must be redesigned before it can run on current releases. The validator set, the node permissions file and the account permissions file (both part of Besu's local permissioning) then need agreement from every member, because each node enforces its own copy. Build time is affected too: Besu 26.6.0 requires JDK 25 to build and run, so the team must confirm that its CI images, base images and hardened hosts can meet that requirement. Monitoring metrics should be planned before go-live, not after, since operators need them to see validator health during the first weeks. Confirm with Besu's maintainers and your own platform team which release line you will standardize on.
Corda projects run long for different reasons. Node topology is a design decision with consequences for every counterparty: which parties host nodes, where the notary sits, and how identities are issued and trusted between counterparties. The notary choice determines how transaction uniqueness is checked, so it should be settled before any CorDapp is coded. CorDapp development involves two separate jobs, writing smart contracts in Java or another JVM language and designing the flows that move messages between participants over the peer-to-peer network. Flow design is where most rework happens, because each step must match the negotiated business process. Confirm with R3 which Corda line and runtime your use case targets, since the first architecture (Corda 1 through 4) and the second (Corda 5) are maintained in different repositories.
The most common delays are governance and legal, not code. Members often stall on who signs off on the network rules, who can onboard a new participant, and who can suspend an account, and those answers must map directly to Besu's account permissioning or to Corda's identity and notary decisions. Legal data-sharing rules also take time to translate into contract logic, so plan a workshop that turns each rule into a testable condition. On Besu, legacy configuration is a frequent hidden cost: settings for Clique, Tessera privacy or onchain permissioning must be removed, and Besu's own release notes show these features were withdrawn across 25.6.0, 25.7.0 and 26.4.0. Ask the vendor or your integrator for a configuration audit before migration, and treat any old node as a rebuild rather than an upgrade.
Questions buyers ask before choosing Besu or Corda
Can a bank run Besu without connecting to a public chain?
Yes. Besu supports private, permissioned networks using proof-of-authority consensus, and the LF Decentralized Trust project page describes QBFT and IBFT 2.0 as the options for enterprise and consortium environments. A private network does not touch Ethereum Mainnet, so no public consensus client is needed. The part to confirm is the network design itself: who runs validators, how node and account permissioning are configured through the permissions file, and how keys are stored. Ask the implementation partner for a written list of nodes, roles and permissioning rules before any build starts, and check whether your compliance team accepts the chosen validator model.
How much more effort is a Corda CorDapp than a Solidity contract?
The effort depends less on the contract language and more on the data model and the workflow around it. Corda smart contracts are written in Java or other JVM languages, and distributed applications are called CorDapps. Because Corda shares data only with the parties to a transaction, your team must design flows for communication and negotiation between participants and decide how notaries fit into each transaction path. A Solidity contract on a shared ledger often needs less of that design but more care around public exposure of state. Treat the difference as a question for a scoped proof of concept: ask for estimated effort per flow and per integration, and compare it with the same use case on Besu.
Is Corda 5 ready for production in my environment?
Corda 5 is described as a scalable, permissioned peer-to-peer distributed ledger platform for regulated markets, developed and maintained by R3 and released under Apache-2.0. The first Corda architecture, in the corda/corda repository, covers versions 1 through 4, and the most recent Corda 4 open source tag is release-os-4.14.3. Whether Corda 5 fits your production needs depends on your own testing, support terms from R3, and the platform features your use case requires. Confirm the current release status, supported deployment topology and upgrade path with R3 directly, and do not assume that an open source repository alone settles production readiness.
What does the work need from our internal team?
Both platforms need engineers who can operate a permissioned network, not only write application code. For Besu, the team needs Java and Ethereum tooling skills, operational knowledge of proof-of-authority validators, and the discipline to handle upgrades. Besu releases use a year.month scheme, ship roughly monthly, and require JDK 25 to build and run, so a release calendar and test environment matter. For Corda, the team needs JVM and Kotlin or Java skills, flow design, and notary and identity operations. Map these needs against the roles you have, and state in the scope which skills DeployOpen would supply and which your staff must own after handover.
Can we do the implementation in-house instead of hiring an outside team?
Yes, many teams do, especially where they already run JVM services and have strong platform engineering. The trade-off is time to competence and the risk of gaps in key management, backups and upgrades. Besu's Bonsai database auto-upgrades on first start, and older Besu versions cannot open an upgraded database, so rollback depends on a backup taken before the upgrade. Corda requires careful notary and identity design. Build an internal plan that covers architecture review, security testing and runbooks, and decide which parts you would buy as a fixed-scope engagement. DeployOpen implements, hardens, documents and supports self-hosted platforms inside the client's infrastructure, but the decision remains yours.
What drives the cost of an outside engagement for Besu or Corda?
The main cost drivers are the number of nodes and organizations, the number of flows or smart contracts, integrations with core systems, the permissioning and identity model, security testing scope, and the compliance evidence you need. Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so ask for a quote built from a written scope that lists each node, flow, integration, test type and handover item separately. Ask which costs are one-time and which recur each year.
Which platform should a regulated team pick first?
Pick Besu when your team already works with Ethereum tooling, wants an Ethereum-compatible permissioned network, and can accept a Java-based stack with monthly releases. Pick Corda when your use case centers on bilateral or small-group transactions where data must stay limited to the parties involved and you can accept a notary-based design and R3's roadmap. Neither choice is final, since both are Apache-2.0 licensed and migrating later means rebuilding the application layer. Run one representative use case on each platform, record effort and operational findings, and confirm support terms in writing before you commit.
How DeployOpen helps choose, implement or migrate a permissioned ledger
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Besu or Corda decision, we start by agreeing on the data-sharing model, the participants and the operating boundaries before any platform is installed.
How we scope
- Map which parties must see which transactions, and where a shared ledger or peer-to-peer flows fit that model.
- Confirm your consensus, permissioning and privacy requirements against the current Besu and Corda documentation.
- Agree a fixed written scope covering deliverables, timelines and responsibilities before work starts.
How we build
- Stand up the chosen platform in your cloud accounts, data centers or air-gapped network.
- Build integrations with your identity, key management, monitoring and existing core systems.
- Test node permissioning, access controls and application logic, and document the results.
How we hand over
- Deliver architecture, runbooks, configuration records and operating procedures your team can run.
- Document the upgrade and rollback path, including the backup your team must take before upgrades.
- Walk your engineers and security staff through the build so they can operate it without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan platform upgrades against each release's notes, including changes that affect existing nodes.
- Confirm retainer scope, response expectations and upgrade coverage in writing before signing.
