Hyperledger Fabric vs Corda: which to choose

Hyperledger Fabric or Corda: when each one fits

If you are a regulated consortium sharing one process across several members, Hyperledger Fabric fits best when many parties must see the same shared state through channels. Fabric's execute, order, validate flow runs chaincode written in Go, Java or Node.js, and its ordering service can run Raft, which is crash fault tolerant, or the Byzantine fault tolerant service that arrived in v3.0. If you are a bilateral or small-group market where each transaction involves only the parties to it, Corda fits best when point-to-point flows and notary-based uniqueness matter more than a shared ledger. Corda smart contracts are written in Java or other JVM languages, and distributed applications are called CorDapps. Neither platform is the right default for every consortium, so treat this section as a filter before you read the detail below.

The decision usually turns on three things. First, the privacy model: list which data each participant must never see, then check whether Fabric channels and private data collections, or Corda's flows and notary design, keep that data where it belongs for your use case. Ask both vendors and your own security architects to confirm this against a concrete transaction flow, not a diagram. Second, team language skills: if your engineers already work in Go, Java or Node.js, Fabric chaincode lowers the learning curve, while a JVM team may find Corda more natural. Third, Corda version maturity: the open source repository corda/corda holds the first architecture (Corda 1 through 4), and the second architecture, which forms the basis of Corda 5, lives in a separate repository. Confirm with R3 which line you can support for the next several years before you commit.

Which platform fits which regulated scenario

This table maps common regulated scenarios to the platform that tends to fit each one, and names the condition that makes that fit hold. Read each row as a question about your own network: if the condition describes your situation, the named platform is the likelier starting point, and if it does not, the other platform may fit better.

Scenario	Better starting point	Condition that makes it so
Many participants sharing one ledger view	Hyperledger Fabric	Fabric channels let a defined group of organizations share a ledger and private data collections, with membership managed through MSPs. Confirm that your governance model can run a channel per business relationship or a shared channel with private collections.
Bilateral trade finance between a few parties	Corda	Corda sends transaction data only to the parties involved in a state, through point-to-point flows. This suits deals where each pair of counterparties needs strict data separation, though a shared trade network with many members would need a different design review.
Team skilled in Go, Node.js or Java chaincode	Hyperledger Fabric	Fabric chaincode can be written in Go, Java and Node.js, so existing developers in those languages can contribute without learning a new runtime. Confirm the language version and SDK support you need for your chosen Fabric line.
Team skilled in JVM languages	Corda	CorDapps are written in Java or other JVM languages, and Corda itself is built in Kotlin on the JVM. Teams already running JVM services can reuse build tooling, testing habits and operations skills.
Need for a dedicated notary to order and validate transactions	Corda	Corda's notary validates uniqueness and sequencing of transactions without global broadcast, so a notary is a designed component you must size, run and govern. Choose Corda if a notary service with a clear trust owner is acceptable to your participants.
No appetite for a separate notary service	Hyperledger Fabric	Fabric uses an ordering service with Raft or BFT options instead of a notary per transaction model. Confirm which ordering option meets your fault tolerance target, since BFT ordering is only available in v3.x.
Heavy reliance on a specific upgrade path to a new major line	Hyperledger Fabric	Fabric publishes a four-step upgrade guide and maintains v2.5 as the LTS line alongside v3.1. Confirm your timeline against the Fabric upgrade documentation, because v3.0 removed Solo and Kafka ordering and the v1.x legacy lifecycle.
Existing Corda 4 deployment or Corda 5 evaluation	Corda	Corda 4 is maintained in the corda/corda repository, while Corda 5 is built on a separate runtime repository. Confirm with R3 which line you are targeting, since the two architectures differ and migration planning depends on it.

How Fabric channels and Corda flows are built

Fabric and Corda both let organizations share a ledger without a public network, but they divide the work differently. Fabric scopes data to channels and runs ordering as a shared service, while Corda sends transactions only to the parties involved and relies on notaries to prevent double spends. The cards below cover what each design means for the people who run the network.

Fabric execute, order, validate flow

Fabric separates transaction handling into three steps: peers simulate a proposal against chaincode, the ordering service puts endorsed transactions in sequence, and peers validate them before committing to the ledger. This means endorsement policies, peer capacity and chaincode behavior all affect throughput and failure handling. Check which organizations must endorse each transaction type, since that decides who must be online for a business transaction to complete. Endorsement policy design is the step most often underestimated.

Channels and private data collections

A channel is a separate ledger shared by a defined set of members, and private data collections keep specific payloads off the channel for selected organizations while leaving a hash on the shared ledger. Each new channel adds membership, configuration and lifecycle work for the operator. Ask who administers channel membership and how private data is purged or retained, because those decisions shape audit and data-minimization obligations.

Raft ordering for crash fault tolerance

Raft is the ordering option Fabric documentation recommends, and it tolerates crashed nodes while a majority remains available. A five node cluster tolerates the loss of two nodes. Raft assumes orderers are operated by trusted parties, so consortia should agree in writing who runs each orderer and where it is hosted. Plan for orderer upgrades in a rolling fashion, since each node must be upgraded in turn.

BFT ordering with SmartBFT

Fabric v3.0 added a Byzantine fault tolerant ordering service based on SmartBFT, which tolerates failures of up to, but not including, one third of ordering nodes. It suits networks where orderers may act maliciously rather than only crash, but it adds operating cost and requires the 3.x line. Confirm with the vendor how BFT orderer membership changes and recovery work before choosing it for a production network.

Corda peer-to-peer nodes and flows

In Corda, each organization runs its own node, and the flow framework handles the messages and negotiation between the parties to a transaction over a peer-to-peer network. Data goes only to the participants who need it, which means no network-wide broadcast. Operators own their node infrastructure, so ask who maintains node upgrades, certificates and connectivity for each counterparty, and how flows are tested across versions.

Corda notaries and CorDapps

Corda's notary validates the uniqueness and sequencing of transactions without broadcasting them to the whole network, so a notary is a shared dependency that must be available for transactions to finalize. Smart contracts, called CorDapps, are written in Java or other JVM languages. Decide who operates the notary, whether it is a single or clustered service, and how a team will support JVM skills for CorDapp maintenance.

Capability comparison: privacy, languages, consensus and identity

This table sets Fabric's channels, chaincode, ordering service and Fabric CA against Corda's point-to-point flows, JVM CorDapps and notaries. Read each row as a question to put to both platforms, and treat the cells as the starting point for a proof of concept rather than a final verdict.

Capability	Hyperledger Fabric	Corda
Privacy model	Channels separate ledgers between member groups, and private data collections keep specific data off shared peers	Point-to-point flows share transaction data only with parties to that transaction, with no global broadcast
Smart contract languages	Chaincode in general-purpose languages such as Go, Java and Node.js	CorDapps written in Java or other JVM languages such as Kotlin, on a Kotlin-based platform
Consensus or notary approach	Ordering service using Raft (crash fault tolerant) or BFT ordering (new in v3.0, SmartBFT)	Notary validates transaction uniqueness and sequencing without global broadcast; confirm notary options in your Corda version
Identity and user registry	Fabric CA issues enrollment certificates, handles renewal and revocation, and can use LDAP as the user registry	Confirm identity and certificate management options with R3 documentation and your chosen deployment
Upgrade path	Fabric v2.5 is the LTS line; v3.0 removed Solo, Kafka and the v1.x chaincode lifecycle, so migration steps are required	Corda 4 open source (release-os-4.14.3 is the latest tag) and Corda 5 use different architectures, so moving between them is a re-architecture
Maintained release lines	v3.1 (latest v3.1.5) and v2.5 (latest v2.5.16) both receive patch releases	Corda 4 open source line is in the corda/corda repository; Corda 5 is in corda-runtime-os; confirm current support status with R3
License	Apache-2.0	Apache-2.0 for the corda/corda repository and Corda 5 runtime

Apache-2.0 licensing and the Corda 4 to Corda 5 split

Hyperledger Fabric is licensed under Apache-2.0, and LF Decentralized Trust lists it as a Graduated project. Two lines are maintained in parallel: v3.1, with the latest release v3.1.5 published June 18, 2026, and v2.5, which the Fabric documentation describes as the long-term support release for production users, with v2.5.16 published the same day.

License: Apache-2.0 applies to the Fabric codebase, so you can use, modify and redistribute it under those terms. Confirm with your legal team how that license interacts with any third-party modules you add.
Maintained lines: v3.1 and v2.5 both receive patch releases, so you choose a line rather than a single current version.
LTS path: The documentation names v2.5 as the LTS release for production, which matters if your change window is slow.
Upgrade route: Moving from v2.5 to v3.x requires migrating Kafka ordering to Raft and moving channels to the v2.x lifecycle first.
Support model: Confirm with your Fabric distributor or internal platform team who handles security patches for the line you pick.

Before committing, check the current release notes for the line you plan to run and confirm the patch cadence in writing.

Why Fabric's 3.x upgrade shapes the plan

If you are weighing Fabric against Corda, the first Fabric decision is which line you will run, because the 3.x line changes what an existing network must do before it can move. Fabric v3.0 removed the Solo and Kafka consensus options and the v1.x legacy chaincode lifecycle. A network still ordering through Kafka must migrate to Raft, and every channel must move to the v2.x lifecycle, before the upgrade can proceed. Confirm your current ordering type and lifecycle state for each channel now, since that inventory sets the size of the preparatory work regardless of which platform you pick.

The Fabric upgrade guide describes four steps: back up the ledger and MSPs, upgrade the orderer binaries in a rolling fashion, upgrade the peer binaries in a rolling fashion, then update the application channel capability levels. The backup step is the one to rehearse, since it covers the ledger and the membership service provider material that identities depend on. Ask your delivery partner to show how that backup is restored in a test environment, and treat the rolling order as a control you verify rather than assume.

The Fabric Gateway client API is compatible with both v2.5 and v3.0, so client applications can be upgraded separately from the network. That gives a Corda-comparison team a useful option: keep application code stable while the network moves on its own schedule. Check whether your business applications call the Gateway API or older peer interfaces, because only the first gets that separation. Also confirm the v2.5 long-term support window and patch cadence with the Fabric maintainers before you commit to a timeline.

What drives the running cost of each platform

Running Hyperledger Fabric or Corda costs more than the software, which is free under Apache-2.0 for both. The cost sits in the nodes that order or notarize transactions, the scarce engineering skills each platform needs, the upgrade work that recurs with each release line, and the governance effort that comes with a multi-party network. Use these cards to build a quote request that compares like with like.

Peer and orderer infrastructure

A Fabric network runs peer nodes for each organization and an ordering service, typically Raft with a majority of nodes needed to keep working. A five node Raft cluster tolerates the loss of two nodes, so you pay for five ordering nodes before any peer. Corda instead runs a node per party plus notary services, and the notary design (single, clustered or validating) sets how much capacity you need. Ask the quote to price each node type, its storage and its backup, and to state who operates the notary. Infrastructure is the largest recurring line in both.

Fabric engineering skills

Fabric chaincode is written in general-purpose languages such as Go, Java and Node.js, so the team may already have some of the skills, but production chaincode still needs developers who understand endorsement policies, private data collections and channel design. Operating the network needs people who understand MSPs, certificate lifecycles and the Fabric CA. Ask the quote who owns chaincode review and whether the scope includes training your staff. Salary levels are a market question you should check locally, not a figure this page can supply.

Corda engineering skills

Corda CorDapps are written in Java or other JVM languages, and Corda itself is written in Kotlin on the JVM. The scarcer skill is Corda-specific design: flows for negotiation between participants, contract and state modeling, and notary behavior. A team that already runs JVM services can ramp faster, but a team with no Corda experience should budget for that learning in the scope. Ask whether the quote includes Corda design review and whether it covers the JVM build and dependency tooling your engineers will use.

Upgrade effort per release line

Fabric v3.0 removed Solo and Kafka consensus and the v1.x legacy chaincode lifecycle, so a v2.5 network that runs Kafka or older lifecycle code faces a migration before upgrading. The documented upgrade path back up the ledger and MSPs, roll orderers, roll peers, then update channel capabilities, repeats for each move. Corda splits its history into Corda 4 open source and the Corda 5 runtime, which is a separate architecture rather than an in-place patch. Ask any quote to price the upgrade path for the line you pick and the test cycle that comes with it.

Support from foundations and vendors

Fabric is a Graduated project at LF Decentralized Trust, and both its 2.5 and 3.x lines receive patch releases, but open-source support is community support unless you contract it. Corda 5 is developed and maintained by R3, and the open source Corda 4 line has a last tag of release-os-4.14.3. Ask each vendor or implementation partner what support tier is included, what response times are contracted, and whether it covers the line you run. DeployOpen offers ongoing support as retainers under a written scope, and its quotes follow from that scope.

Consortium governance overhead

Both platforms require agreement among parties before a network runs. Fabric needs agreed channel membership, endorsement policies, MSP and certificate authority arrangements, and an ordering service operator model. Corda needs agreed notary choice, CorDapp versions and flow compatibility across nodes. Governance work recurs when members join, leave or change keys, and it is often the largest cost in a consortium that has not yet agreed on roles. Ask the quote to include a governance workshop and a written operating model, and confirm who signs off changes.

Moving a permissioned ledger from one platform to the other

This sequence moves a ledger between Fabric and Corda without losing the business rules, identity mapping or audit trail that the existing network depends on. Each step ends with a check the team can verify before the next one starts.

Confirm the data and identity model
Start by writing down what the current network records, who owns each record, and which identities transact. On Fabric, that means channels, private data collections, and the MSP and Fabric CA identity hierarchy. On Corda, it means states, participants, and the certificate authority that issues node identities. Compliance, risk, and the business owners should sign off on this inventory, because it defines what must survive the move. The step is done when every asset has an owner, a privacy boundary, and a mapped identity on the target side.
Map business logic to the target contract model
Translate each chaincode function or CorDapp contract into the target model, with the logic written down before any code is ported. Chaincode runs on a key-value world state, while CorDapps work with states and contracts in Java or other JVM languages, so the mapping is a design task, not a syntax conversion. Developers and domain experts review the mapping together. The step closes when each business rule has a named counterpart and the team agrees on what is out of scope.
Rebuild contracts, flows and integrations
Build the new contracts, flows and external integrations on the target platform, then test them against the mapped rules in a non-production environment. On Corda, flows replace the point-to-point messaging that Fabric handles through endorsement and the ordering path, so the team must design the counterparty exchange explicitly. Integrations with core systems, identity providers, and reporting tools are rebuilt in the same pass. The step is complete when the test suite passes against the agreed rule set and every integration has a documented owner.
Rebuild the network topology and ordering or notary setup
Stand up the target network with its node layout, certificate authority, and ordering or notary service. Fabric teams choose an ordering service, and the Fabric ordering documentation describes Raft and, from v3.0, a BFT option, so the team should confirm the fault tolerance it needs. Corda teams decide how notaries are deployed and who operates them. Confirm the network with the operations team, including backup procedures for each component. The step is complete when the network runs a test transaction end to end and the operators have a written runbook.
Run parallel reconciliation
Feed the same business transactions into the legacy and target networks for a defined window, then compare the resulting records. Reconciliation should cover balances, state counts, identity attribution, and rejected transactions, and every difference needs a documented cause. Auditors or compliance staff should review the comparison method before it starts. The step closes when the team can show that the two networks produce matching results for the agreed set of transaction types, with exceptions recorded and accepted by the business owner.
Migrate historical data and cut over
Decide which historical records move to the new ledger, which stay in an archive of the legacy network, and how each archive is kept accessible to auditors. Freeze writes on the legacy network, load the agreed data, and switch client applications to the new endpoints in one controlled change. Keep the legacy network readable until the business owner confirms the cutover. The step is done when production traffic runs on the target platform, the archive is verified, and the rollback procedure has been tested.
Document what transfers and what is rebuilt
Record the outcome of the migration in a single document. Business logic design, identity policies, and the process documentation usually carry over with light revision. Contracts, flows, client integrations, and operating runbooks are rebuilt for the new platform and need new tests and sign-off. Compliance evidence, including the reconciliation results and the change approvals, goes into the audit file. The step is done when the document has been reviewed by the control owners and stored where auditors can find it.

Where Fabric and Corda implementation projects run long

The longest stretches in a Fabric or Corda project are rarely the software installs. They are the agreements that must exist before a node can join a network. On Fabric, the membership service provider (MSP) definitions decide which organizations can sign and which identities are trusted, and Fabric CA can use LDAP as its user registry, so the consortium has to agree on enrollment authority, certificate lifetimes and revocation handling before anyone issues a certificate. On Corda, the equivalent work is agreeing on network membership, the network operator and the notary service that every participant will rely on. Ask each prospective member which identity provider and certificate authority they will use, who approves a new participant, and how a revoked identity is reported to the rest of the network.

Design decisions made early also drive rework later. On Fabric, channels define which organizations share a ledger, and private data collections define which subset of members can see which data, with the peer-side hashes visible to the channel. Changing collection policies or splitting a channel after data is live is expensive, so settle the membership and data-visibility matrix on paper first. On Corda, the flow framework and notary design determine how parties negotiate and finalize transactions, and whether a validating or non-validating notary fits the privacy requirement. Confirm with your own risk and legal teams which data may reach a notary, and test flow failure and retry behavior in a non-production network before go-live.

HSM integration and the upgrade path are the two items most often underestimated. Fabric documents how to use a hardware security module for peer and orderer keys, but the key ceremony, HSM partitioning, backup and failover all belong to your own environment and your HSM vendor, so confirm them in writing before build. For upgrades, Fabric describes a four-step process: back up the ledger and MSPs, upgrade orderers, upgrade peers in a rolling fashion, then update channel capability levels. Fabric 3.0 also removed Kafka ordering and the legacy chaincode lifecycle, so any network still on those components needs a migration plan. For Corda, confirm with R3 or your delivery partner which runtime line you are targeting, since the Corda 4 and Corda 5 codebases are separate.

Questions buyers ask before choosing Fabric or Corda

What does the implementation effort for Fabric or Corda depend on?

The effort depends mostly on the business network you need to build, not on the license, since both platforms are Apache-2.0. Fabric work centers on defining channels, private data collections, endorsement policies, the ordering service and the membership service providers each organization uses. Corda work centers on the states and contracts that model your assets, the flows that move them between parties, and the notary arrangement. Ask any vendor or partner to break the effort into design, build, integration with your identity and key systems, and testing, and to state which parts are fixed in a written scope before work starts.

Can our own engineers run Fabric or Corda without outside help?

A team with strong distributed systems and JVM or Go experience can run either platform, but both need people who understand consensus, certificates and key management. Fabric operators manage orderers, peers, Fabric CA and the upgrade sequence, which the Fabric upgrade guide describes as 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. Corda operators manage nodes, notaries and CorDapp releases. Confirm whether your staff have run a production network before, and whether you want outside help for the first go-live only or for ongoing operations.

How long does a pilot take, and what drives the timeline?

No fixed duration applies to every pilot, and no researched figure is available here to quote. The timeline is driven by the number of participating organizations, how many business processes the pilot covers, how much identity and key infrastructure must be connected, and whether a hardware security module is part of the design. Fabric pilots also depend on which release line you choose, and Corda pilots depend on how many notary and node operators must agree on configuration. Ask for a milestone plan in the written scope that lists each dependency, including the participants who must sign off.

Which programming skills does each platform require?

Fabric chaincode is written in general-purpose languages such as Go, Java and Node.js, so a team with any of those skills can start. Corda smart contracts are written in Java and other JVM languages, and Corda itself is written in Kotlin, so JVM developers have the most direct path. Your choice should match the skills you can hire or retain, the language your integration team already uses, and the review process your auditors expect. Plan for training on the platform's transaction model in either case, since Fabric's execute, order, validate flow and Corda's point-to-point flows work differently from typical application code.

Is Corda 4 or Corda 5 the right line for a new project?

The two lines are different codebases, so the choice matters before design begins. The corda/corda repository holds the first architecture, covering Corda versions 1 through 4, and the most recent Corda 4 open source tag is release-os-4.14.3. The second architecture lives in the corda-runtime-os repository and forms the basis of Corda 5, which R3 develops and maintains under Apache-2.0. Corda 4 is the older line, so confirm its support window with R3 before you commit. Ask any partner to show which line their reference designs use and how a move from one to the other would be handled.

How expensive is it to switch from Fabric or Corda later?

Switching costs come from the application logic and the data model, not from the license fee, since both platforms are open source. Fabric chaincode, channel layout and private data collections are tied to Fabric's transaction flow, so moving to Corda means redesigning the contracts and the privacy model. Corda CorDapps and states are tied to the JVM and Corda's flow framework, so moving to Fabric means rewriting those flows. Within Fabric, moving between v2.5 and v3.x also requires planning, because v3.0 removed Solo and Kafka consensus and the v1.x legacy chaincode lifecycle. Ask for an estimate of the migration effort in writing, with the data and identity components listed separately.

What does a consultant handle, and what stays in-house?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing. For a Fabric or Corda network, that can include the network design, deployment, identity and key integration, backup procedures and upgrade runbooks, plus security testing of the applications and nodes. Your organization should keep decisions about which counterparties join, governance rules, and business ownership of the data. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do that work. Ongoing support, upgrades and continuous testing are available as retainers.

Which compliance evidence should we ask a partner to prepare?

Ask the partner to prepare the systems, controls and evidence your assessor will need, such as network diagrams, key management records, access reviews, backup test results and change logs from the upgrade process. Fabric's operations service and Fabric CA reports give some of this data, while Corda evidence depends on node and notary logs. DeployOpen prepares this evidence for compliance assessments but does not issue attestations or certifications, so confirm which independent auditor or certification body your regulator accepts before work begins.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Hyperledger Fabric vs Corda, we start with the decision and the governance model, then build and document only what the chosen platform needs.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We confirm which Fabric line or Corda release your network needs, and which ledger features your use case depends on.
Scope covers node topology, identity and certificate authorities, ordering or notary design, and the target hosting environment.

How we build

We deploy and configure the chosen platform in your infrastructure, including channels or flows, chaincode or CorDapp packaging, and identity integration.
We run security testing against the application, APIs and infrastructure as part of the build, before go-live.
We prepare systems, controls and evidence for compliance assessments, without issuing audit reports or certifications.

How we hand over

Handover includes architecture documentation, runbooks for node operations and a record of configuration decisions.
We document the backup approach for ledgers, keys and identities, and walk your operators through restore steps.
Your team receives the written scope outcomes, so the platform can be operated and extended without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
Retainers can cover planning for version moves, such as Fabric upgrades or Corda release changes, before they reach production.
We can re-run security testing after changes to chaincode, CorDapps, identity or network topology.

Hyperledger Fabric vs Corda