ComparisonDistributed Ledger Technology

Public vs permissioned blockchain: choosing a network model for enterprise systems

Public versus permissioned is really a choice about who governs the network, who may write and validate, and who can see what. Public networks give the widest independent verification and the least control; permissioned networks give control over admission and visibility at the cost of running governance yourselves. Many enterprise designs land in between: private data and processing, with proofs anchored on a public network. This page compares the models criterion by criterion.

Reviewed 6 min read

On this page
  1. What public, private and permissioned actually mean
  2. Network models compared criterion by criterion
  3. Governance and admission decide more than the technology does
  4. Confidentiality, finality and fees as design inputs
  5. Anchoring private records on a public network, step by step
  6. Where a managed permissioned network fits in the comparison
  7. Matching the network model to your constraints
  8. Questions and answers
  9. Sources

What public, private and permissioned actually mean

The words are used loosely. These working definitions keep the comparison honest.

Permissionless
Anyone can read the ledger and submit transactions, and block publishing is open to anyone who meets the protocol's rules, without authorization from an operator1.
Permissioned
Those who publish blocks must be authorized by some authority, centralized or decentralized; read and transaction access may be open or restricted1.
Public, council-governed
Open for anyone to use and read, while the nodes reaching consensus are run by vetted organizations under a governance body. Hedera is an example: its council members run nodes, have equal voting rights and serve term limits2.
Consortium or private
A permissioned network whose members, and often whose readers, are a defined group of organizations, typically run on software such as Hyperledger Fabric.
Hybrid or anchored
Records and processing stay in a private system, while periodic proofs of them are written to a public network for independent timestamping and integrity checks.

Network models compared criterion by criterion

CriterionPublic permissionlessPublic, council-governedConsortium permissionedPrivate records, public anchoring
Who decides protocol changesOpen community processes and node operatorsA defined governing body with published rulesConsortium members under their own agreementYour organization for the private side; the public network's governance for anchoring
Who may join as a validatorAnyone meeting protocol rulesApproved organizationsMembers admitted by the consortiumNot applicable to the private side
Default visibility of transactionsPublic to everyonePublic to everyoneMembers only, with finer controls availablePrivate; only hashes are public
Finality modelVaries by protocol, from probabilistic to checkpoint-based7Depends on the network; Hedera reports aBFT consensus within seconds3Deterministic on Fabric's ordering service6Inherits the public network's finality for the proofs
Cost modelMarket-driven fees in a native tokenPublished fee schedule; on Hedera set in USD, paid in HBAR4Infrastructure and operations shared by membersPrivate infrastructure plus modest anchoring fees
Independent verification by outsidersStrongestStrongOnly if outsiders are granted accessStrong for integrity and timing, not for content
Exit and portabilityHistory remains public; moving state needs migration or bridgesAs for public networksDepends on the consortium agreement and data export rightsSimplest: private records are yours, proofs stay public

Cells describe typical properties of each model, not guarantees of any product. Network-specific facts are cited in the sections below; check current documentation before relying on them.

Governance and admission decide more than the technology does

On a public permissionless network, nobody you can contract with controls upgrades or who validates. That is the point: verification does not depend on any organization's goodwill. The trade-off is that you accept the community's decisions on protocol changes and fee markets, and you design around them.

Council-governed public networks sit between the extremes. Hedera's council members run the network's nodes and approve technology updates, under a permissioned node model and a published LLC agreement2. For an enterprise, that offers a named governing body without having to build one. In a consortium, by contrast, the members are the governance. Fabric, for example, identifies each organization through certificates issued by its certificate authority and a membership service provider definition6, so admission is a business decision recorded in configuration.

Confidentiality, finality and fees as design inputs

Public networks expose every transaction, so confidentiality comes from what you choose to write: identifiers, hashes and signed status events rather than documents or personal data. Permissioned platforms offer finer tools. In Fabric, channels keep entire ledgers separate for a set of members, and private data collections share data peer-to-peer with authorized organizations while every peer on the channel records only a hash of it5.

Finality matters when a record triggers a payment, a release of goods or a legal effect. Hedera describes its hashgraph consensus as asynchronous Byzantine fault tolerant, with the order of a transaction known with certainty within seconds3. Ethereum's proof-of-stake finalizes checkpoints once validators holding at least two-thirds of staked ETH vote for them, and reverting a finalized block would cost at least a third of all staked ETH7. Fabric's ordering service produces deterministic blocks that cannot fork6.

Fee predictability is a practical concern for budgeting high-volume event logging. Hedera publishes its fee schedule in USD and charges in HBAR at the live exchange rate4; on networks with market-driven fees, cost per write can change with demand.

Anchoring private records on a public network, step by step

write signed recordbatch of hashesbuild Merkle rootsubmit rootconsensus receiptrecord and proofverify root and time01Participantsystem02Private store03Anchoringservice04Public network05Auditor
  1. Participant system

    The application where the business event happens.

  2. Private store

    A database or permissioned ledger holding the full records.

  3. Anchoring service

    Batches record hashes into a single root and submits it.

  4. Public network

    Orders and timestamps the root; anyone can read it.

  5. Auditor

    Checks a record against the public proof without trusting the operator.

  1. Participant system to Private storewrite signed record
  2. Private store to Anchoring servicebatch of hashes
  3. Anchoring service to Anchoring servicebuild Merkle root
  4. Anchoring service to Public networksubmit root
  5. Public network to Anchoring serviceconsensus receipt
  6. Auditor to Private storerecord and proof
  7. Auditor to Public networkverify root and time
Conceptual sequence for a hybrid design. It shows the pattern, not a particular product or deployment.

Where a managed permissioned network fits in the comparison

A further option is a managed permissioned network built on public-network technology and able to interoperate with it, such as Hedera HashSphere. It suits institutions that need private participation rules but want a path to public assets and services. Placement of specific workloads between HashSphere and Hedera mainnet is covered in detail on the HashSphere placement guide.

Matching the network model to your constraints

  • If

    Outsiders such as customers, the public or future counterparties must verify records without permission.

    Then

    Use a public network, writing only proofs and non-sensitive references.

    Only a public ledger lets anyone verify without being admitted first.

  • If

    A defined group of organizations must share confidential transaction details and enforce admission.

    Then

    Use a consortium permissioned network, and draft the governance agreement before the technical design.

    Confidentiality controls work only if membership and roles are settled.

  • If

    You need confidentiality and external verifiability, but no consortium is ready to form.

    Then

    Keep records private and anchor their hashes on a public network.

    You gain independent timestamping and integrity without disclosing content or recruiting members.

  • If

    Regulators or risk committees require a named, accountable network governor.

    Then

    Favor a council-governed public network or a managed permissioned environment.

    They offer an identifiable governing body without your firm carrying that role alone.

Questions and answers

What are the common pitfalls in consortium blockchain governance?

Unclear cost sharing, voting rules that let one founder block changes, no agreed process for admitting competitors, and no exit terms for data. Projects also stall when members run nodes in name only. Write a rulebook covering admission, upgrades, disputes, fees and exit, and test it with a hypothetical departure before go-live.

Can we move from a permissioned network to a public one later?

Partly. Business logic and record formats can be designed to be network-neutral, and historic records can be proven on a public network by anchoring their hashes. Moving live assets or tokens usually needs a migration or a bridge, with its own legal and security review, so plan identifiers and data formats with that possibility in mind.

Do we need to run our own nodes on a public network?

Usually not. On most public networks, applications submit transactions through hosted services or SDKs and read state from mirror or archive services. Running your own read infrastructure can help with independence and data retention. Running a consensus node on a council-governed network depends on its governance rules rather than on your choice alone.

Is a permissioned ledger more secure than a public one?

Not inherently. A permissioned ledger reduces exposure by limiting who can connect and read, but its security depends on a small set of operators and their key management. A public ledger is exposed to anyone, yet its integrity rests on many independent validators. Assess both against the threats that matter to your use case.

Sources

  1. NIST IR 8202: Blockchain Technology Overview — National Institute of Standards and Technology · checked 10 October 2026
  2. Hedera Council — Hedera Council · checked 10 October 2026
  3. Hashgraph consensus algorithm — Hedera documentation · checked 10 October 2026
  4. Mainnet fees — Hedera documentation · checked 10 October 2026
  5. Private data — Hyperledger Fabric documentation · checked 10 October 2026
  6. The ordering service — Hyperledger Fabric documentation · checked 10 October 2026
  7. Proof-of-stake (PoS) — ethereum.org · checked 10 October 2026

More in Distributed Ledger Technology

Back to Distributed Ledger Technology

Next step

Bring your participant list and we will map it to a network model

Send the organizations involved, what each must see and who must verify records from outside. We will set out which network models fit, the governance each one requires and the trade-offs to take to your risk committee.

Compare network models