Hiero vs Fabric vs Besu: Enterprise DLT Compared

Three enterprise distributed ledger platforms now live under the same governance umbrella -- and they couldn't be more architecturally different. Hiero (formerly the Hedera Hashgraph codebase, donated to the Linux Foundation Decentralized Trust in 2024) uses a directed acyclic graph with asynchronous Byzantine fault tolerance. Hyperledger Fabric uses a blockchain with execute-order-validate consensus. Hyperledger Besu runs an Ethereum-compatible blockchain with QBFT consensus. According to the Hyperledger Foundation's 2025 annual report, Fabric and Besu together account for over 74% of enterprise permissioned deployments -- but Hiero's addition to the ecosystem is changing the conversation.

Choosing between these platforms isn't about picking a winner. It's about matching architecture to requirements. This guide compares Hiero, Fabric, and Besu on every dimension that matters: consensus, privacy, smart contracts, throughput, cost, and real-world enterprise adoption.

For teams already comparing just Fabric and Besu, we have a dedicated deep-dive comparison. This guide adds Hiero to the picture.

TL;DR: Hiero excels at high-throughput public-permissioned workloads with 10,000+ TPS and sub-$0.001 transaction costs. Fabric dominates privacy-heavy multi-org use cases with channel isolation. Besu wins when EVM compatibility and Ethereum tooling matter. All three are now under Linux Foundation Decentralized Trust governance (Hyperledger Foundation, 2025).

What Is Hiero and How Did It Join the Linux Foundation?

Hiero is the open-source distributed ledger codebase originally developed by Hedera Hashgraph. In September 2024, the Hedera governing council voted to contribute its core codebase to the Linux Foundation Decentralized Trust, making it open-source under the same umbrella as Hyperledger Fabric and Besu. According to the Linux Foundation announcement (2024), this was the largest code donation in the foundation's history.

The name "Hiero" distinguishes the open-source project from the Hedera public network. Hedera continues to operate as a public DLT network running the Hiero codebase -- similar to how Ethereum is a network that runs various client implementations. But Hiero as a codebase can now be deployed privately, forked, or extended by anyone.

What Makes Hiero Different from Blockchain?

Hiero doesn't use a blockchain. It uses a hashgraph -- a data structure based on a directed acyclic graph (DAG). In a blockchain, transactions are bundled into blocks that form a single chain. In a hashgraph, events (containing transactions) are organized in a graph where each event references two previous events. There's no mining, no block production, and no chain of blocks.

This architectural difference matters. Blockchains process transactions sequentially within blocks. Hashgraph processes them in parallel through the DAG structure. The result is significantly higher throughput -- Hedera's public network has demonstrated over 10,000 transactions per second, according to Hedera network statistics (2025).

The Governance Shift

Before the Linux Foundation donation, Hedera was governed by a council of 39 organizations including Google, IBM, Boeing, Deutsche Telekom, and Standard Bank. That council governed the public Hedera network and the codebase together.

Now, the codebase (Hiero) is governed by the Linux Foundation's standard open-source governance model. The Hedera network's governing council continues to manage the public network itself. This separation is important -- it means Hiero's technical direction is now driven by open-source community consensus, not a corporate governing council.

How Do the Consensus Mechanisms Differ?

Consensus is where these three platforms diverge most sharply. Hiero uses asynchronous Byzantine fault tolerance via the hashgraph protocol. Fabric uses Raft (crash fault tolerant) or SmartBFT (Byzantine fault tolerant) depending on version. Besu uses QBFT or IBFT 2.0 for Byzantine fault tolerance. The Hyperledger Performance Working Group (2025) has benchmarked all three, finding throughput ranges from 800 TPS (Besu with QBFT) to 10,000+ TPS (Hiero's hashgraph).

Hiero: Hashgraph Consensus (aBFT)

Hashgraph achieves consensus through a protocol called "gossip about gossip" combined with virtual voting. Each node gossips events to randomly selected other nodes. Each event contains the transactions being submitted plus references to two previous events -- the node's own last event and the last event it received from another node.

The "virtual voting" part is what makes it clever. Instead of sending explicit vote messages (which consume bandwidth), nodes can mathematically determine how every other node would have voted based on the gossip history. This eliminates an entire round-trip of communication that traditional BFT protocols require.

The result is asynchronous BFT -- consensus is guaranteed regardless of network timing assumptions. Classic BFT protocols like PBFT, QBFT, and SmartBFT are partially synchronous: they assume messages eventually arrive within some time bound. Hashgraph makes no such assumption, making it theoretically more robust in unreliable network conditions.

Fabric: Pluggable Consensus

Fabric takes a modular approach. The ordering service is a separate component that can use different consensus implementations. Raft has been the default since Fabric 1.4.1 -- it's fast and simple but only crash fault tolerant. Fabric 3.0 added SmartBFT for Byzantine fault tolerance.

Raft elects a leader among orderer nodes. The leader proposes blocks; followers replicate them. If the leader crashes, a new election happens within seconds. SmartBFT replaces this with a BFT protocol that tolerates malicious orderers, but at a throughput cost.

Fabric's endorsement model is separate from ordering consensus. Transactions are endorsed (simulated) by peers before reaching the orderer. This two-phase approach means Fabric's total throughput depends on both endorsement capacity and ordering throughput.

For details on configuring QBFT specifically, see our QBFT consensus guide.

Besu: QBFT Consensus

Besu's recommended consensus for enterprise deployments is QBFT (Quorum Byzantine Fault Tolerant). QBFT is a four-phase BFT protocol: the proposer creates a block, validators exchange prepare messages, then commit messages, and finally the block is finalized. A round change protocol handles proposer failures.

QBFT provides immediate finality -- once a block is committed, it won't be reverted. This is critical for financial applications where probabilistic finality isn't acceptable. The trade-off is throughput: QBFT typically achieves 200-800 TPS depending on transaction complexity, according to ConsenSys benchmarks (2024).

Hiero's hashgraph consensus delivers 10,000+ TPS with aBFT guarantees through virtual voting and gossip-about-gossip (Hedera Network Stats, 2025). Fabric reaches 3,500 TPS with Raft (CFT) or 2,000-3,000 TPS with SmartBFT. Besu's QBFT provides immediate finality at 200-800 TPS (ConsenSys, 2024).

How Does Privacy Compare Across All Three?

Privacy is where Fabric pulls ahead decisively. According to a Forrester survey on enterprise blockchain (2024), 72% of organizations cite data privacy as their top blockchain requirement. Each platform handles privacy very differently, and the right choice depends on what "privacy" means in your specific context.

Hiero: Limited Native Privacy

Hiero's hashgraph was designed primarily for the public Hedera network, where transparency is a feature, not a bug. All transactions on the main network are visible to all nodes. For enterprise use cases requiring privacy, Hiero offers a few options.

Private deployments. You can run Hiero as a private network with restricted membership. All nodes in the private network see all transactions, but external parties can't access the network at all. This provides network-level privacy but no intra-network data isolation.

Hedera Consensus Service (HCS). HCS allows you to record hashes or encrypted data on the public ledger while keeping the actual data off-chain. This provides a public timestamp and ordering proof without exposing sensitive content. It's useful for audit trails and document timestamping.

Application-layer encryption. You can encrypt transaction payloads before submitting them to Hiero. Only parties with the decryption key can read the data. The network still orders and timestamps the encrypted transactions.

None of these approaches match the depth of Fabric's channel model or Besu's Tessera integration. Privacy in Hiero is largely an application-level concern.

Fabric: Channel-Level Isolation

Fabric's privacy model is the strongest of the three. Channels create entirely separate ledgers shared only by their members. Private data collections add another layer, allowing subset sharing within a channel. Transient data fields keep information off the ledger entirely.

For supply chain networks where competing suppliers share infrastructure but shouldn't see each other's pricing, Fabric's channel isolation is hard to beat. No other platform provides equivalent ledger-level data separation.

We've published a detailed comparison of blockchain privacy approaches if you need to go deeper.

Besu: Tessera Privacy Groups

Besu handles privacy through Tessera, a separate transaction manager. Private transactions are encrypted and sent off-chain to participating Tessera nodes. Only a hash marker appears on the shared ledger. Privacy groups define which nodes can access each set of private transactions.

This works well for bilateral confidentiality -- two parties exchanging data that others shouldn't see. But it doesn't provide the ledger-level separation that Fabric channels offer. All transactions, including privacy group markers, still flow through the same blockchain.

For a tutorial on Fabric's private data collections, see our Hyperledger Fabric private data tutorial.

Ready to deploy a privacy-focused blockchain network? Book a call with David to discuss your privacy requirements, or start deploying now with ChainLaunch.

What About Smart Contract Development?

Developer ecosystem size directly affects your project's hiring costs and development speed. Electric Capital's Developer Report (2024) counted over 23,000 monthly active Solidity developers globally, making Solidity the dominant smart contract language. Both Hiero and Besu can benefit from this pool, while Fabric's Go/Java chaincode has a smaller but deeply specialized developer community.

Hiero Smart Contracts

Hiero supports smart contracts through its own EVM-compatible layer. Developers can write Solidity contracts and deploy them on Hiero, tapping into the Ethereum tooling ecosystem (Hardhat, Foundry, OpenZeppelin). However, Hiero's EVM implementation has some differences from standard Ethereum -- gas costs, precompiled contracts, and certain opcodes behave differently.

Beyond the EVM, Hiero offers native services that don't exist in standard Ethereum. The Hedera Token Service (HTS) provides native token creation and management without deploying a smart contract. The Hedera Consensus Service (HCS) provides ordered, timestamped message logging. These native services are faster and cheaper than equivalent smart contract implementations.

Fabric Chaincode

Fabric supports chaincode in Go, Java, and Node.js. Go is the dominant choice in production deployments. The chaincode lifecycle is more complex than contract deployment on Hiero or Besu -- it requires packaging, installation on peers, organizational approval, and channel commitment. This governance overhead is a feature for enterprises that need multi-party approval before smart contracts go live, but it slows development iteration.

Besu Smart Contracts (Solidity)

Besu runs a standard Ethereum Virtual Machine. Any Solidity or Vyper contract works. The full Ethereum tooling ecosystem applies -- Hardhat, Foundry, Remix, Ethers.js, OpenZeppelin. Token standards (ERC-20, ERC-721, ERC-1155) work natively. There's no gap between Besu's EVM and mainnet Ethereum's EVM, which means public Ethereum developers can build on Besu without learning anything new.

How Do Costs Compare in Practice?

Cost structures differ dramatically across these three platforms. Hiero's public network charges per-transaction fees. Fabric and Besu are self-hosted, meaning you pay only for infrastructure. According to our own development cost analysis, traditional Hyperledger development ranges from $160,000 to $580,000 -- but the platform choice affects where those costs land.

Hiero Cost Model

On the public Hedera network, transactions have fixed USD-denominated fees. A cryptocurrency transfer costs $0.0001. A consensus message (HCS) costs $0.0001. A token transfer costs $0.001. A smart contract call varies based on gas but is typically under $0.01.

These costs are predictable and low -- but they're ongoing. High-volume applications processing millions of transactions per month can accumulate significant fees. A supply chain network recording 100,000 events daily would cost roughly $10 per day in transaction fees, or $3,650 annually. Infrastructure costs are zero since Hedera runs the nodes.

Running Hiero as a private network eliminates per-transaction fees but introduces infrastructure costs comparable to Fabric or Besu.

Fabric Cost Model

Fabric is entirely self-hosted. There are no per-transaction fees. You pay for the servers that run your peers, orderers, and CAs. A minimal 2-organization Fabric network requires 8-10 containers and costs $200-$600/month in cloud infrastructure, based on AWS pricing (2025) for equivalent compute.

The larger cost is typically development and operations. Fabric's complexity drives higher consulting rates. Senior Fabric developers earn $150,000-$200,000 annually in the US, according to Web3.career salary data (2025).

Besu Cost Model

Besu is also self-hosted with no per-transaction fees. Infrastructure costs are generally lower than Fabric because Besu networks require fewer components. A 4-validator Besu network with Tessera runs on $100-$300/month in cloud infrastructure.

Developer costs are typically lower than Fabric because Solidity developers are more available. Salaries range from $120,000-$170,000 for senior roles (Web3.career, 2025).

Which Platform Fits Which Use Case?

The right platform depends on your specific requirements -- not on which technology sounds most impressive. Based on the World Economic Forum's 2025 blockchain report, supply chain represents 31% of enterprise deployments, followed by financial services at 24% and identity management at 12%.

Choose Hiero When...

You need high throughput with public verifiability. If consumers, regulators, or auditors need to independently verify records without joining your network, Hiero's public network provides that transparency. Carbon credit registries, sustainability certifications, and public audit trails fit this pattern.

Transaction volume is very high. IoT networks generating millions of data points, micropayment systems processing thousands of transactions per second, or logging platforms that need ordered timestamps at scale -- Hiero's 10,000+ TPS handles these without breaking a sweat.

You want minimal infrastructure management. On the public Hedera network, you don't run nodes. You submit transactions and pay per use. For teams without dedicated blockchain DevOps, this removes significant operational burden.

Choose Fabric When...

Privacy between consortium members is critical. Supply chains where competitors share a network, healthcare networks exchanging patient data, trade finance platforms with bilateral confidentiality -- Fabric's channel model provides the strongest data isolation of any enterprise DLT.

You need fine-grained endorsement policies. "3 of 5 organizations must approve this transaction" is native in Fabric. Multi-party approval workflows, complex governance rules, and tiered access control are first-class features.

Your use case involves complex multi-organization business processes. When the blockchain needs to coordinate workflows across organizations with different roles, permissions, and data access levels, Fabric's architecture was built for exactly this.

Choose Besu When...

EVM compatibility matters. Tokenization projects, DeFi integrations, and anything that might interact with public Ethereum should start on Besu. The tooling, libraries, and developer talent are unmatched.

You want a hybrid public-private option. Besu can run as a fully permissioned private network and later bridge to Ethereum mainnet. This flexibility matters for tokenization projects that start private but eventually need public liquidity.

Token standards are a requirement. ERC-20, ERC-721, and ERC-1155 work natively on Besu. Building equivalent token functionality on Fabric requires custom chaincode.

You can deploy a Besu network in under 2 minutes to test these capabilities firsthand.

Can These Platforms Work Together?

Yes, and there are practical reasons to combine them. The Hyperledger Foundation (2024) reports that 31% of enterprise blockchain adopters run more than one DLT protocol. With all three platforms now under the same governance umbrella, interoperability is becoming a higher priority.

Fabric + Besu

This is the most common multi-protocol architecture we've seen. A Fabric network handles the core business process -- supply chain tracking, trade finance workflows -- where channel-based privacy is essential. A Besu network handles tokenization, settlement, or any function that benefits from EVM compatibility. Events bridge the two, typically through an off-chain middleware layer.

Hiero + Fabric

Hiero's Consensus Service (HCS) can provide a public timestamping and ordering layer for events that originate in a private Fabric network. A pharmaceutical supply chain might track drug movements on Fabric (for privacy between manufacturers, distributors, and pharmacies) while recording regulatory checkpoints on Hiero's public network (for FDA audit access).

Hiero + Besu

Both support Solidity smart contracts, making integration at the application layer simpler. A project might use Besu for a private permissioned network and Hiero's public network for public-facing verification or token listing.

The Interoperability Challenge

Cross-DLT interoperability remains a hard problem. There's no standard bridge protocol between these platforms. Most integrations today use application-layer middleware -- an off-chain service that reads events from one platform and writes corresponding transactions to another. Projects like Hyperledger Cacti (formerly Cactus) are working on standardized cross-ledger protocols, but they're not production-ready yet.

In our experience, the simplest approach is to design your architecture so that each platform handles a distinct function. Don't try to make them share state. Instead, define clear event boundaries: "when X happens on Fabric, record Y on Hiero." This keeps each platform doing what it does best.

Ready to deploy a multi-protocol blockchain infrastructure? Book a call with David to discuss your architecture, or start deploying now with ChainLaunch.

What Does the Future Look Like for Each Platform?

All three platforms are actively evolving. The Linux Foundation Decentralized Trust 2025 roadmap outlines development priorities that will shift the competitive landscape over the next 12-24 months.

Hiero's Roadmap

Hiero's transition to open-source governance is still settling. The immediate priorities are making the codebase fully self-hostable (without dependency on Hedera's public infrastructure), improving documentation for private deployments, and building a contributor community. Longer-term, expect improvements to EVM compatibility, privacy features (the biggest current gap), and interoperability with other Linux Foundation DLT projects.

Fabric's Roadmap

Classic Fabric continues to receive maintenance updates and SmartBFT improvements. The bigger story is Fabric-X -- a ground-up reimplementation with microservices architecture and Arma BFT consensus. Fabric-X is in Hyperledger Labs and targets 20,000+ TPS with horizontal scaling. We've written a detailed guide to Fabric-X covering the architecture changes and migration path.

Besu's Roadmap

Besu evolves alongside the broader Ethereum ecosystem. Upcoming priorities include improved QBFT performance, better privacy capabilities, and support for new Ethereum Improvement Proposals (EIPs). Besu's position as the enterprise on-ramp to Ethereum means it benefits from the massive R&D investment flowing into the Ethereum ecosystem -- something neither Fabric nor Hiero can match.

FAQ

Is Hiero the same as Hedera?

No. Hiero is the open-source codebase that the Hedera governing council donated to the Linux Foundation in 2024. Hedera is the public network that runs the Hiero software. Think of it like the relationship between Chromium (open-source project) and Chrome (Google's product built on Chromium). You can run Hiero as a private network without any connection to the public Hedera network.

Which platform has the largest enterprise adoption?

Fabric leads in total enterprise deployments. The Hyperledger Foundation's 2025 report shows Fabric at approximately 46% of permissioned deployments, Besu at 28%, and Hiero/Hedera growing rapidly from a smaller base. Fabric's lead reflects its eight-year head start and strong adoption in supply chain and government. Besu is gaining ground through tokenization and DeFi use cases.

Can I migrate between these platforms?

Migration between fundamentally different architectures is expensive. Fabric chaincode (Go) can't run on Besu's EVM or Hiero's hashgraph. You'd need to rewrite smart contracts, restructure data models, and update all client integrations. Plan for 60-80% of original development effort. The exception: Besu and Hiero both support Solidity, so moving smart contracts between them is possible with moderate effort (adjustments for platform-specific APIs and gas behavior).

Which is cheapest to run?

For low-volume applications (under 10,000 transactions/day), Hiero's public network is cheapest -- no infrastructure to manage, and transaction fees total pennies per day. For high-volume applications, self-hosted Fabric or Besu avoid per-transaction fees entirely. Besu typically has lower infrastructure costs than Fabric due to simpler network architecture ($100-$300/month vs $200-$600/month for comparable deployments).

Do I need to choose just one?

No. Running multiple DLT protocols is increasingly common for organizations with diverse use cases. A retailer might use Fabric for supply chain traceability (privacy between suppliers) and Besu for a loyalty token program (ERC-20 compatibility). The key is to use a consistent infrastructure layer so you're not managing completely separate operational stacks for each platform.

Which is easiest to get started with?

For developers with Ethereum/Solidity experience, Besu is the easiest. You can deploy a Besu network in 2 minutes and start writing smart contracts immediately. For developers without blockchain experience, Hiero's public network has the lowest barrier -- no infrastructure setup, just API calls. Fabric has the steepest learning curve due to its unique architecture (channels, MSPs, endorsement policies, chaincode lifecycle).

Conclusion

Hiero, Fabric, and Besu each solve different problems for different architectures. Hiero delivers the highest throughput with the simplest operational model, but its privacy capabilities lag behind. Fabric provides the strongest data isolation through channels, but it's operationally complex and has a smaller developer pool. Besu offers the broadest tooling ecosystem and a bridge to public Ethereum, but its throughput is lower and its privacy model less granular than Fabric's.

The decision framework is straightforward. Start with your privacy requirements -- if you need ledger-level data separation, Fabric wins. Check your throughput needs -- if you're processing tens of thousands of transactions per second, Hiero is the only realistic option. Evaluate your developer ecosystem -- if Ethereum tooling and talent matter, Besu or Hiero's EVM layer are your choices.

For many enterprises, the answer isn't one platform. It's two -- each handling the use cases it was designed for, connected through well-defined event boundaries. The fact that all three now live under the same Linux Foundation governance makes this multi-platform approach more viable than ever.

Related guides: Hyperledger Fabric vs Besu | Blockchain Platform Selection Guide | QBFT Consensus in Besu | Deploy a Besu Network in 2 Minutes | What Is Fabric-X? | Blockchain Privacy Comparison

David Viejo is the founder of ChainLaunch and a Hyperledger Foundation contributor. He created the Bevel Operator Fabric project and has been building blockchain infrastructure tooling since 2020.