Quorum is a permissioned version of Ethereum for enterprises: it runs Solidity contracts and standard Ethereum tooling, but only approved nodes can join, consensus is a fast BFT protocol instead of proof of stake, and transactions can be kept private between selected parties. If you are starting a new project today, the practical question is less "how do I use GoQuorum" and more "how do I build a permissioned Ethereum network, which now usually means Hyperledger Besu".
A short history that matters for your decision
Quorum began as JPMorgan's fork of the Go Ethereum client, adding privacy and permissioning for financial use cases. ConsenSys acquired it in 2020 and maintained it as GoQuorum alongside Hyperledger Besu, its Java-based Ethereum client that also supports permissioned networks. ConsenSys has since deprecated GoQuorum and recommends Besu for new permissioned Ethereum networks, and Besu itself is maintained as an open-source project under the Linux Foundation Decentralized Trust (the successor to Hyperledger). Check the Besu documentation for current support status and migration guidance before committing.
So when a vendor or old blog post says "Quorum development", treat it as shorthand for enterprise Ethereum. Existing GoQuorum networks still exist and need maintenance and migration plans; new ones should rarely start on GoQuorum.
Core building blocks
| Component | Options | What to know |
|---|---|---|
| Client | Hyperledger Besu (recommended for new networks); GoQuorum (legacy) | Both execute EVM bytecode, so Solidity contracts port between them |
| Consensus | QBFT, IBFT 2.0, Clique; Raft on GoQuorum | QBFT is the usual recommendation for production: immediate finality, tolerates fewer than one third faulty validators |
| Permissioning | Node and account allowlists, local or contract-based | Decide who governs membership changes, and how |
| Privacy | Tessera private transaction manager; separate networks or channels per group; off-chain data with on-chain hashes | Confirm the current support status of built-in privacy features before designing around them |
| Tooling | Hardhat, Foundry, ethers.js, web3 libraries, block explorers | Standard Ethereum tooling works, which is Quorum's biggest advantage |
Visibility into a private network needs its own explorer, since public explorers cannot see it. The companion guide to the Quorum explorer covers options for that.
Privacy: the part to design most carefully
Original Quorum's selling point was private transactions, first handled by a component called Constellation and later by its successor, Tessera: the payload is encrypted and shared only with named participants through a private transaction manager, while a hash goes on the shared chain. This works, but it has costs. Private state can diverge between nodes, private contracts cannot easily interact with public ones, and the feature set has seen deprecations over time. Many teams now prefer simpler designs:
- Separate small networks for groups that must not see each other's data.
- Encrypted payloads or hashes on-chain, with documents held off-chain.
- Zero-knowledge proofs for specific facts that must be verified without being revealed.
If privacy between counterparties on every transaction is your central requirement, compare with Corda, which shares data point-to-point by design.
Planning a permissioned Ethereum network
- Confirm you need a shared ledger. If one organization controls all writes, a database with audit logging is simpler.
- Define governance. Who runs validators, who approves new members, who can upgrade contracts, and how disputes are handled. Write it down legally, not just technically.
- Choose validator count and placement. BFT consensus needs at least four validators to tolerate one fault; spread them across organizations and regions.
- Design the privacy model using the options above.
- Develop and test contracts with the same rigor as on public Ethereum, including audits.
- Build operations: monitoring, key management with HSMs, backups, node upgrade procedures and an explorer.
- For existing GoQuorum networks, plan migration to Besu: test contract compatibility, consensus migration, and private-state handling in a staging environment first.
Cost and effort
As a rough assumption-based estimate, a proof of concept with four Besu validators, QBFT and a couple of contracts can be stood up in a few weeks by two engineers. A production consortium network is mostly governance and operations: onboarding members, legal agreements, security review and 24/7 support. That typically takes months and has ongoing costs that outlast the build. More about this model is in the guides to private blockchain development and enterprise blockchain solutions.
When to choose Quorum-style networks
Permissioned Ethereum fits consortia that want Solidity, existing Ethereum skills and the option of later connecting to public Ethereum or tokenized-asset ecosystems. It is a weaker fit when participants need strong per-transaction privacy by default (consider Corda) or modular channel-based isolation (consider Hyperledger Fabric). Increasingly, institutions also evaluate public layer 2s or privacy-focused rollups as alternatives to running their own network.
Frequently asked questions
Is GoQuorum still supported?
ConsenSys has deprecated GoQuorum and points users to Hyperledger Besu. Existing networks should check the official documentation for current support dates and plan migration.
Can I use MetaMask and Hardhat with Quorum or Besu?
Yes. Both expose standard Ethereum JSON-RPC, so wallets, libraries and development frameworks work once pointed at your network's endpoint and chain ID.
Does a permissioned network need gas fees?
Gas still meters computation, but networks commonly set the gas price to zero so users don't need a token. Gas limits remain important to prevent runaway transactions.
What is QBFT?
QBFT is a Byzantine fault-tolerant consensus protocol for permissioned Ethereum. Validators take turns proposing blocks and finalize them with a supermajority vote, so there are no forks or reorganizations.