ConsenSys Quorum for Enterprise: Permissioned Networks, Privacy and When to Use One

If you're evaluating ConsenSys Quorum for a new network, start with this: most of what's been written about it describes software that's been retired. The GoQuorum repository is archived, and its README states that ConsenSys no longer actively maintains or supports it and doesn't recommend it for new projects. Tessera, the private transaction manager that gave Quorum its privacy story, is deprecated as well. Besu, the other client that sat under the Quorum brand, removed its Tessera integration and its contract-based permissioning in release 25.6.0.

Permissioned EVM networks are still a reasonable tool for some problems. What's changed is the stack you'd build one with, and where privacy comes from. Here's how we see it now, as engineers who run production consensus infrastructure but have not deployed a Quorum network for a client.

What Quorum was, and what's left of it

Quorum started at J.P. Morgan as a fork of go-ethereum with two additions enterprises asked for: private transactions and consensus protocols that don't need mining. ConsenSys acquired it in 2020 and marketed "ConsenSys Quorum" as a family that included GoQuorum and Hyperledger Besu, the Java Ethereum client ConsenSys had built and contributed to Hyperledger.

Today the two halves have gone different ways. GoQuorum is read-only, kept for historical reference. Besu is alive and still developed in the open under LF Decentralized Trust (the successor to the Hyperledger Foundation), and it remains a mainstream Ethereum client. For private networks it supports the QBFT and IBFT 2.0 consensus protocols, plus local node and account permissioning configured on each node. It dropped Clique, and as of 25.6.0 it no longer ships Tessera privacy or on-chain permissioning contracts.

So "should we use Quorum?" really means "should we run a permissioned network on Besu, and how will we handle privacy?" Those are the two questions worth answering.

How Quorum privacy worked, and why it was retired

Tessera's model was clever. When you sent a private transaction, the payload was encrypted and sent peer to peer only to the Tessera nodes of the participants you named. The chain itself recorded a hash in place of the payload. Every node agreed on the public state, but each participant also kept a private state that only it and its counterparties could compute. Privacy groups let a fixed set of members share private state over time.

In practice it was hard to live with. Every member ran an extra service with its own database and keys. Private state was only as consistent as the participants made it, and non-participants had no way to validate it. Losing a Tessera node's data meant losing private state that no other node outside the group could give back to you. When the Besu maintainers announced the sunset in September 2024, their stated reason was that these features hadn't kept pace with the rest of the Ethereum ecosystem and that application-layer alternatives existed.

The alternative they pointed to has since become Paladin, an LF Decentralized Trust project created by Kaleido. It's a runtime for privacy-preserving contracts on any EVM chain, with options ranging from zero-knowledge tokens to private EVM execution among a defined group. Our view: moving privacy into the application layer is the right direction, because it stops tying confidentiality to one client implementation. It's also a younger codebase than Tessera was, so budget for the testing and the maintenance relationship a newer dependency needs.

There's an older and duller option that often beats both. Don't put the confidential data on the ledger at all. Keep it in each party's systems, put signed hashes and state changes on chain, and share the underlying records directly with whoever is entitled to see them. That's the model behind Blokstorage, where files never go on chain and only proof records do. A surprising number of "we need private transactions" requirements turn out to be "we need proof that we both saw the same document."

Consensus and permissioning in practice

QBFT is the protocol we'd pick for a new Besu network. It's a Byzantine fault tolerant protocol with immediate finality: once a block is committed, it won't be reorganised. With n validators it tolerates f faulty or malicious ones where n is at least 3f + 1, so four validators survive one failure and seven survive two. Besu's documentation recommends at least four nodes in production. IBFT 2.0 is still supported, but we see no reason to start a fresh network on it.

Raft deserves a mention because older Quorum material leans on it. Raft was available in GoQuorum and is crash fault tolerant, not Byzantine fault tolerant: it assumes nodes may stop but won't lie. That's fine inside one company and a poor fit for a consortium, which is the only setting where you'd want a ledger in the first place. It went away with GoQuorum.

Validators are added and removed by validator vote, so membership changes are governed by the same supermajority that produces blocks. That's a governance decision as much as a technical one. Write down in the consortium agreement who may propose a new validator and what happens if a member stops running its node.

Permissioning in current Besu is local. Each node has a configuration file listing which nodes and accounts it will accept, and those rules apply to that node only. Network-wide rules therefore depend on every member deploying the same config. Our advice is to keep the allowlists in version control and roll them out through the same pipeline at every member, with a check that alerts when one node's config drifts. For anything more complex, Besu supports plugins.

Besu, Fabric, or a public chain

Besu makes sense when you want the EVM: Solidity contracts, standard Ethereum tooling, wallets that already understand your transactions, and the option to move contracts to a public network later. You get controlled membership and fast finality in exchange for running the network yourselves.

Hyperledger Fabric, also under LF Decentralized Trust, is a different design. Chaincode is written in general-purpose languages such as Go or Java, and privacy is built into the architecture through channels and private data collections. If confidentiality between members is the central requirement and nobody needs EVM compatibility, Fabric deserves a serious look. The cost is a smaller developer pool and less shared tooling.

A public chain or an Ethereum L2 removes the operations burden and lets outsiders verify the record without joining anything. That's often the right answer when the assets or counterparties already live on public networks. You give up control of governance and pay fees. You also have to assume that anything you write is visible to everyone, so privacy has to come from the application layer or from keeping data off chain.

Our rough default: proof-only use cases anchor hashes to a public chain; regulated groups of known institutions with genuinely private shared state look at Fabric or at Besu with application-layer privacy; anything touching public assets starts on a public chain or L2. Teams in finance will find more on that last case on our fintech page.

Operations are the real cost

Running a consensus network day to day is where permissioned projects quietly fail, and it's the part we know best. Through EOS Support, RORO has operated a Top-21 block producer on Vaulta since 2023. Vaulta isn't an EVM consortium chain, but the operational shape rhymes: a known set of producers, finality that depends on a supermajority of them, and nobody who can make a change alone.

The work that transfers looks like this. Validators need to be spread across organisations and cloud regions, because four validators in one data centre is one validator with extra steps. Signing keys should be separated from the hosts that run the node, and rotated through the same validator voting that governs membership. Monitoring has to catch missed rounds and disk growth before they become an outage, and someone has to be on call when it fires.

Upgrades are the hardest part. A protocol change on a BFT network needs enough validators upgraded before the activation block, which means coordinating schedules across companies with different change-control processes. On Vaulta, EOS Support has done that kind of coordination with exchanges and other producers during network upgrades, and it's the most time-consuming work in the role. Plan for it in the consortium agreement, not after the first missed upgrade.

If you're already on GoQuorum, the migration question is pressing. GoQuorum's own README describes its QBFT as interoperable with Besu, which is what makes a gradual swap of validators plausible. Private state held through Tessera is a separate and harder problem. Inventory it first, because it determines how painful the move will be.

A decision checklist

• Do several organisations need to write to a shared record that none of them should control alone? If not, use a database.
• Do you need the EVM specifically, or would Fabric's model fit better?
• What actually has to be private, and could it stay off chain with only hashes on the ledger?
• If you need on-chain privacy, are you comfortable depending on an application-layer framework such as Paladin?
• Who runs at least four validators, in which organisations and regions, and who pays for them?
• How are validator keys stored and rotated, and how is membership governed?
• Who coordinates upgrades, and what happens when a member falls behind?
• If you're on GoQuorum today, how much Tessera private state do you hold?

Answer those and the platform choice usually becomes obvious. More of our thinking on network design is on our blockchain networks page.

If you're planning a permissioned network or moving off GoQuorum, talk to us about the operations side before you commit to a stack.