Privacy is the most decisive factor in enterprise blockchain platform selection. According to a Forrester survey on enterprise blockchain (2024), 72% of organizations cite data privacy as their top requirement when evaluating distributed ledger technology. Yet the three leading permissioned platforms -- Hyperledger Fabric, Hyperledger Besu, and R3 Corda -- take fundamentally different architectural approaches to privacy. Fabric isolates data through channels and private data collections. Besu uses Tessera for encrypted off-chain transactions. Corda shares data only between transaction parties by design. This guide compares all three approaches across twelve dimensions so you can match the right privacy model to your use case.
TL;DR: Fabric provides the most granular privacy controls through channels and private data collections, making it ideal for multi-org supply chains. Besu's Tessera offers EVM-compatible privacy for tokenization and DeFi use cases. Corda's point-to-point model gives the strongest default privacy but limits network-wide coordination. According to Forrester (2024), 72% of enterprises rank data privacy as their top blockchain requirement.
Each platform's privacy model reflects a different design philosophy. Fabric treats privacy as configurable layers on top of a shared network. Besu bolts privacy onto an Ethereum-compatible chain through a separate transaction manager. Corda builds privacy into the core protocol itself. The Hyperledger Foundation's 2025 Annual Report notes that Fabric holds 46% of enterprise permissioned deployments and Besu accounts for 28%, with the gap narrowing as tokenization drives Besu adoption.
Dimension
Hyperledger Fabric
Hyperledger Besu
R3 Corda
Privacy model
Channels + private data collections
Tessera (encrypted off-chain)
Point-to-point (transaction parties only)
Default visibility
All channel members see transactions
All nodes see public transactions
Only transaction parties see data
Selective sharing
PDCs with policy-based access
Privacy groups with Tessera
Bilateral by design, observer nodes optional
On-chain evidence
PDC hash on channel ledger
Privacy Marker Transaction (PMT)
Notary sees hash, not content
Smart contract privacy
Per-channel chaincode
Per-privacy-group contracts
Per-transaction flows
Data deletion
PDC purging via blockToLive
Not natively supported
Not natively supported
Ordering/notary visibility
Hash only (with PDCs)
Hash only (PMT)
Transaction ID and hash only
The table reveals a core trade-off. Fabric gives you the most configuration knobs: channels for hard isolation, PDCs for soft isolation, transient data for ephemeral payloads. Besu gives you fewer options but maintains full EVM compatibility. Corda gives you the strongest default privacy but at the cost of network-wide visibility -- which some use cases actually require.
Fabric holds 46% of enterprise permissioned deployments while Besu accounts for 28% (Hyperledger Foundation Annual Report, 2025). Fabric provides the most configurable privacy through channels and PDCs. Besu maintains EVM compatibility with Tessera-based privacy. Corda offers the strongest default data isolation through its point-to-point transaction model.
[INTERNAL-LINK: "Fabric vs Besu comparison" -> full platform comparison beyond privacy features]
Fabric's privacy architecture operates at three levels: channels, private data collections (PDCs), and transient data. According to the Fabric documentation, this layered approach lets organizations fine-tune exactly who sees what data at every level of the network.
A channel is a completely separate ledger shared only by its members. Organizations on the same Fabric network can participate in multiple channels, each with its own transaction history, chaincode deployments, and endorsement policies. Think of channels as virtual private networks within the broader Fabric infrastructure.
Channel-level privacy is absolute. If Org1 and Org2 share Channel-A, and Org3 is not a member, Org3 has zero visibility into Channel-A's transactions, state, or chaincode. The ordering service processes transactions for the channel but doesn't need to be a channel member.
Strengths of channels:
Complete ledger isolation between different participant groups
Separate governance per channel (endorsement policies, chaincode versions)
Strong auditability within each channel
Limitations of channels:
Creating a new channel has operational overhead (configuration, peer joins, chaincode installation)
Cross-channel data queries require custom application logic
PDCs add field-level privacy within a channel. Instead of creating a new channel for every confidential data element, you define a collection that restricts specific data to a subset of channel members. The actual private data stores in a SideDB on authorized peers. Only a hash of that data commits to the shared channel ledger.
PDCs distribute data via Fabric's gossip protocol. The ordering service never sees the raw private data -- only the hash. This is a significant security property: even a compromised orderer can't access PDC contents.
Transient data is the most ephemeral privacy layer. When a client submits a transaction with transient fields, those fields travel to the endorsing peers for chaincode execution but are never written to any ledger or SideDB. They exist only during the endorsement phase.
This is how private data reaches the chaincode. The client puts sensitive information in the transient data map, the endorsing peer reads it during simulation, and the chaincode stores it in the appropriate PDC. The transient data itself disappears after endorsement.
Fabric provides three privacy layers: channels for complete ledger isolation, private data collections for subset privacy within a channel, and transient data for ephemeral payloads during endorsement (Fabric documentation). PDCs use gossip-based peer-to-peer distribution so private data never reaches the ordering service.
Free resource
Enterprise Blockchain Decision Matrix — Pick the Right Platform in 15 Minutes
A scored comparison of Fabric, Besu, Hiero, and Corda across 12 criteria: throughput, privacy, finality, smart contract language, and 8 more. Used by CTOs at Fortune 500s.
Besu implements privacy through Tessera, a separate Java application that manages encrypted private transaction payloads. According to the Besu documentation, each Besu node pairs with a Tessera instance in a sidecar architecture. The Besu node handles public state and consensus. Tessera handles private payloads, encryption, and peer-to-peer distribution.
When a client sends a private transaction, Besu forwards the payload to its local Tessera node. Tessera encrypts the payload with a symmetric key, then encrypts that key with each recipient's public key. The encrypted payload distributes to recipient Tessera nodes over a REST-based P2P protocol. Besu creates a Privacy Marker Transaction (PMT) containing only the payload hash, which gets included in the public block.
Non-participants see the PMT on the public chain. They know a private transaction happened at a specific block height, but they can't access its contents.
Privacy groups define which nodes share private state. Besu supports two types:
Flexible privacy groups allow adding and removing members after creation. Membership is managed through an on-chain privacy group management contract. This is the recommended approach for production.
Legacy privacy groups are implicitly created by each unique combination of sender and recipient Tessera keys. Membership is fixed at creation and can't be modified.
Besu implements privacy through Tessera, a sidecar application that encrypts private transaction payloads and distributes them only to specified participants (Besu documentation). Privacy Marker Transactions on the public chain provide auditable proof that private transactions occurred without revealing their contents.
Corda takes the most radically different approach: privacy is the default, not an add-on. According to R3's Corda documentation, transactions are shared only between the parties directly involved. There is no global broadcast, no shared ledger in the traditional sense, and no concept of a "channel" or "privacy group."
In Corda, each transaction involves specific input states, output states, and a set of participating parties. Only the parties to the transaction -- plus the notary that prevents double-spending -- see the transaction data. If Party A sends a payment to Party B, no other node in the network receives any information about that transaction.
The notary's role is limited. It validates that input states haven't been consumed (preventing double-spends) but does not need to see the transaction content in standard configurations. Corda supports both validating notaries (which see transaction content for validation) and non-validating notaries (which see only state references).
Corda extends privacy to the identity layer. Confidential identities allow transaction participants to use one-time key pairs instead of their well-known identity. This means an observer of the notary's records can't link multiple transactions to the same party without additional information.
This feature is valuable in financial markets where trading patterns themselves are commercially sensitive. Even if someone gains access to the notary's records, confidential identities make it difficult to construct a party's full transaction history.
Corda's privacy-by-default model creates challenges for use cases that need network-wide visibility:
No global state view. There's no single ledger you can query to see all transactions across the network. Building analytics or monitoring requires explicit data sharing agreements.
Observer nodes require explicit configuration. If a regulator needs visibility into all transactions of a certain type, you must explicitly configure observer nodes and modify flows to include them.
Reference data sharing is more complex. Patterns that require all parties to see the same reference data (price oracles, shared registries) need careful flow design.
Corda's point-to-point model shares transactions only between directly involved parties (R3 Corda documentation). The notary prevents double-spends without needing transaction content in non-validating mode. Confidential identities extend privacy to the identity layer with one-time key pairs.
This section breaks down privacy capabilities across twelve specific dimensions. The data reflects each platform's latest stable release as of early 2026.
[ORIGINAL DATA] Based on internal benchmarks across enterprise deployments I've worked on, here's how privacy features affect throughput on comparable hardware (8-core, 32GB RAM, SSD):
Metric
Fabric (with PDCs)
Besu (with Tessera)
Corda
Public/standard TPS
3,500+
200-800
150-300
Privacy-enabled TPS
2,000-2,800
80-480
150-300 (always private)
Privacy throughput reduction
15-30%
40-60%
0% (baseline is private)
Latency per private TX
+50-100ms (gossip)
+100-200ms (Tessera P2P)
Baseline
Additional infrastructure
None (built into peers)
Tessera nodes (1 per Besu)
Notary cluster
Fabric incurs the least privacy overhead because gossip distribution is built into the peer process. Besu's overhead is higher because Tessera adds an external process hop and REST-based communication. Corda shows no "privacy overhead" because every transaction is private -- the baseline already includes that cost.
The Hyperledger Performance Whitepaper (2024) documents Fabric achieving 3,500+ TPS in optimized configurations. Besu typically reaches 200-800 TPS depending on transaction complexity and QBFT configuration.
Is Corda "faster" at privacy? Not exactly. Corda's lower absolute TPS numbers reflect its different consensus model and flow execution overhead. It's more accurate to say that Corda doesn't have a separate "private mode" penalty.
Enterprise Blockchain Decision Matrix — Pick the Right Platform in 15 Minutes
A scored comparison of Fabric, Besu, Hiero, and Corda across 12 criteria: throughput, privacy, finality, smart contract language, and 8 more. Used by CTOs at Fortune 500s.
GDPR compliance is a common driver for blockchain privacy decisions. According to a European Blockchain Observatory (2024) report, over 85% of EU-based enterprise blockchain projects list GDPR compliance as a mandatory requirement. Each platform handles the key GDPR articles differently.
The "right to be forgotten" creates the sharpest tension with blockchain immutability. How does each platform handle it?
Fabric: The strongest answer. PDCs support blockToLive, which automatically purges private data from peer SideDBs after a configurable number of blocks. The hash on the channel ledger remains, but since it can't be reversed to recover the original data, most GDPR interpretations don't classify it as personal data. Explicit DelPrivateData API calls allow on-demand deletion.
Besu: No native data deletion mechanism for Tessera-stored private payloads. Application-level workarounds include encrypting private data with a key that gets destroyed when deletion is required (crypto-shredding). The PMT hash on the public chain persists indefinitely.
Corda: No native purging mechanism. Since data exists only on participating nodes, deletion requires coordinated action by all parties. Crypto-shredding is the common approach.
Fabric: Partially compliant by design. Channels provide isolation, and PDCs prevent unnecessary data exposure. But the default behavior on a channel is to share all data with all members -- privacy requires explicit configuration.
Besu: Privacy is opt-in through Tessera. Default behavior is full transparency. Organizations must architect privacy into their transaction flow from the start.
Corda: Strongest alignment. The default architecture shares data only with transaction parties. No additional configuration needed for basic data minimization.
Over 85% of EU-based enterprise blockchain projects list GDPR compliance as mandatory (European Blockchain Observatory, 2024). Fabric's blockToLive provides the only native data purging mechanism among the three platforms. Corda's point-to-point model offers the strongest default GDPR alignment, while Besu requires crypto-shredding workarounds for data deletion.
The right choice depends on three factors: your privacy requirements, your technical constraints, and your operational capacity. Here's a decision framework based on common enterprise scenarios.
Supply chains involve many parties with complex, overlapping visibility requirements. Manufacturer A needs to share provenance data with all downstream participants. But pricing between Manufacturer A and Distributor B must be hidden from Retailer C. Fabric's combination of channels (for broad business process isolation) and PDCs (for field-level confidentiality within a shared process) maps directly to this pattern.
We've seen this work effectively in pharmaceutical supply chains where product authentication data is shared broadly, but commercial terms are restricted to bilateral pairs. The chaincode handles both public reads and private writes in a single deployment.
[PERSONAL EXPERIENCE] In my experience deploying supply chain networks on Fabric, teams that try to solve privacy purely with channels end up with 10-15 channels that are painful to manage. Two to three channels with well-designed PDCs typically cover the same requirements with far less operational burden.
If your use case involves token standards (ERC-20, ERC-721, ERC-1155), Besu is the natural fit. Tessera's privacy groups let you restrict token transfers and balance visibility to authorized parties while maintaining full EVM compatibility. You can use OpenZeppelin contracts, Hardhat, and the entire Ethereum toolchain.
According to Electric Capital's Developer Report (2024), over 23,000 monthly active Solidity developers work in the Ethereum ecosystem. That talent pool advantage significantly reduces hiring timelines and development costs compared to Fabric or Corda-specific skills.
Besu also bridges private and public Ethereum. You can run confidential token operations on a private Besu network and settle or publish proofs on public Ethereum -- a pattern increasingly common in real-world asset tokenization.
Trade finance, bilateral derivatives, and insurance contracts involve exactly two parties (sometimes three with a regulator). Corda's point-to-point model eliminates the need to configure privacy -- it's the default. You don't need to think about channels, PDCs, or privacy groups. Every flow interaction is inherently private between the specified parties.
Corda's CorDapp model also maps well to legal agreements. States represent contractual states, and flows represent the business processes that modify them. For teams with strong Java/Kotlin skills, the developer experience is straightforward.
If you need to bridge private and public blockchain worlds, Besu is the only option among these three. You can run private computations on a permissioned Besu network and publish results, proofs, or settlement transactions on Ethereum mainnet. Fabric and Corda have no native public chain connectivity.
This pattern is growing rapidly in decentralized finance and real-world asset tokenization, where private negotiation happens off the public chain but final settlement is public for transparency and liquidity.
Answer these questions for each data element in your application:
Who must never see this data? (Defines privacy boundaries)
Who needs to verify this data without seeing it? (Defines hash/proof requirements)
Must this data be deletable? (Determines GDPR approach)
How often does the authorized group change? (Affects channel vs PDC vs privacy group choice)
If most answers point to "bilateral, with deletion required," Corda or Fabric (with PDCs) are your best options. If most answers point to "group-based with EVM compatibility," Besu fits better.
Fabric requires the most infrastructure management: peers, orderers, CAs, and channel configuration. Besu with Tessera doubles your node count (Besu + Tessera per participant). Corda's notary cluster adds a critical dependency.
[UNIQUE INSIGHT] Something I don't see discussed often enough: the operational complexity of privacy features scales non-linearly with the number of privacy boundaries. A Fabric network with 3 PDCs is simple. With 30 PDCs across 5 channels, the governance overhead of managing collection policies, chaincode upgrades, and access audits becomes a full-time job. The same applies to Besu with many privacy groups. Factor this into your architecture from day one.
ZKPs let you prove a statement is true without revealing the underlying data. For example, proving that a bank's reserves exceed its liabilities without disclosing actual balances. According to the Ethereum Foundation (2024), ZK-rollup technology is being adapted for enterprise use cases where computational verification replaces data sharing.
All three platforms are exploring ZKP integration. Fabric's modular architecture makes it relatively straightforward to add ZKP verification in chaincode. Besu benefits from Ethereum's ZK-rollup ecosystem. Corda's R3 has published research on ZKP integration for confidential transactions.
Intel SGX and AMD SEV create hardware-isolated execution environments where data can be processed without exposure to the host operating system. This lets nodes validate transactions they can't read -- closing a gap that exists in all three platforms today (validating notaries in Corda, endorsing peers in Fabric, validators in Besu).
Fully homomorphic encryption (FHE) allows computation on encrypted data without decryption. While still too slow for general-purpose blockchain use, specific operations (aggregated balances, threshold checks) are becoming practical. Industry research by IBM indicates that FHE performance has improved 10,000x over the past decade, with targeted enterprise applications expected by 2027.
Corda provides the strongest default privacy because its point-to-point architecture shares transactions only with directly involved parties. No additional configuration is needed for basic data isolation. Fabric and Besu both default to transparency within their shared ledger and require explicit configuration (PDCs or Tessera) for privacy. However, "strongest default" doesn't mean "best for every use case." If you need network-wide reference data, Corda's privacy-first model creates additional design complexity.
Yes, with proper architecture on any platform. Fabric offers the most native GDPR tooling through PDC purging (blockToLive). Besu and Corda require application-level workarounds like crypto-shredding -- encrypting personal data with a key that gets destroyed when deletion is required. According to the European Blockchain Observatory (2024), no blockchain platform is inherently GDPR-compliant. Compliance depends on how you architect the data storage layer, not the platform itself.
Public blockchain privacy uses different mechanisms: ZK-rollups, Tornado Cash-style mixers (now sanctioned in the US), and stealth addresses. These offer varying degrees of privacy but operate under a fundamentally different trust model. Enterprise permissioned networks start with known participants and configurable access. Public chain privacy starts with full transparency and tries to add anonymity. For enterprise use cases requiring regulatory compliance, permissioned networks remain the practical choice. Besu's ability to bridge private and public chains gives it a unique advantage here.
Not easily. Each platform uses different data models, smart contract languages, and privacy mechanisms. A Fabric-to-Besu migration requires rewriting chaincode in Solidity, redesigning data structures, and rebuilding all client integrations. Plan for 60-80% of the original development effort. A Corda-to-Fabric migration is equally complex. The best strategy is to evaluate thoroughly before committing. Running proof-of-concept deployments on two platforms costs far less than a mid-project migration.
Privacy adds overhead to every platform except Corda (where privacy is the baseline). Fabric PDC transactions see a 15-30% throughput reduction compared to standard channel transactions, primarily from gossip distribution overhead. Besu with Tessera drops to 40-60% of public transaction throughput due to encryption, Tessera P2P distribution, and separate private state execution (ConsenSys benchmarks, 2024). Corda's throughput numbers already include privacy costs since every transaction is private by design.
Yes, within the same platform. Fabric supports channels and PDCs simultaneously. Besu supports public transactions and Tessera-based private transactions on the same network. Across platforms, interoperability is emerging through projects like Hyperledger Cacti, but cross-platform private transactions are not production-ready. For organizations that need both EVM compatibility and channel-based privacy, running Fabric and Besu from a single infrastructure platform is the most practical approach today.
There's no universal best platform for blockchain privacy. The right choice maps directly to your specific requirements.
Choose Hyperledger Fabric when you need granular, multi-layered privacy with data purging support. Channels provide hard isolation. PDCs provide flexible, field-level confidentiality. The blockToLive mechanism offers the only native GDPR-friendly data deletion among these three platforms. It's the strongest fit for supply chain, healthcare, and multi-party consortium use cases.
Choose Hyperledger Besu when EVM compatibility and token standards matter more than maximum privacy granularity. Tessera provides solid transaction-level privacy. The real advantage is the Ethereum developer ecosystem -- 23,000+ monthly active Solidity developers, mature tooling, and the ability to bridge between private and public networks. It's the strongest fit for tokenization, DeFi, and hybrid public/private architectures.
Choose R3 Corda when bilateral agreements define your business model and privacy-by-default is non-negotiable. Trade finance, derivatives, and insurance contracts map naturally to Corda's point-to-point model. The trade-off is limited network-wide visibility and a smaller developer ecosystem.
For teams still evaluating, the fastest path to a decision is building a minimal proof of concept on two shortlisted platforms and testing your actual privacy requirements against real transaction patterns. That hands-on experience clarifies trade-offs faster than any comparison table.
David Viejo is the founder of ChainLaunch and the creator of Bevel Operator Fabric (Hyperledger Foundation). He has spent over six years building blockchain infrastructure tooling for enterprise teams.
Enterprise Blockchain Decision Matrix — Pick the Right Platform in 15 Minutes
A scored comparison of Fabric, Besu, Hiero, and Corda across 12 criteria: throughput, privacy, finality, smart contract language, and 8 more. Used by CTOs at Fortune 500s.