Public vs Private Blockchain
Who has to verify decides the chain
One vendor says public for the transparency, the other says permissioned for the compliance, and both are mostly describing their own stack rather than your problem.
Ask us which one fitsWhy the two vendors disagree
Public and private describe who may read and write. Decentralised describes who could stop you. They are not the same axis, and a permissioned network where one company runs every node is centralised no matter which consensus algorithm sits underneath — which is the ambiguity most of these pitches live inside.
The question that settles it is short: name the people who must believe this record. If all of them are parties you already have signed contracts with, a permissioned network or a plain database will do the job. If they include customers, token holders or a regulator you have never met, only a public chain proves anything.
Where it bites
Where the two genuinely diverge
Not a feature table. These are the places where the choice reappears later as a migration, a legal problem, or a support ticket you cannot close.
Who can read your commercial terms
Every public transfer is readable on Etherscan, including counterparty and amount. Two customers on different pricing can work out each other's deal by afternoon.
Privacy that actually holds
Fabric channels and private data collections keep a payload between named members. The usual public-chain answer is to store a hash and keep the data off it.
Erasure and personal data
GDPR's right to erasure has no clean answer on an immutable ledger. Put a customer's name on a public chain and you cannot take it back.
What your users have to become
A public chain expects your users to hold a wallet and gas. ERC-4337 paymasters can hide both, but that is a build, not a checkbox.
Who pays when nothing happens
Public chains charge per transaction and nothing at rest. A permissioned network charges nothing per transaction and never stops charging for node uptime.
Changing the code later
Public contracts are immutable unless a proxy pattern was designed in from day one. Upgrading Fabric chaincode is easy in code and needs every member org to endorse it.
Losing a key
A lost private key on a public chain is final. A permissioned network's membership authority reissues the certificate, which is most of why banks like the model.
Finding someone to audit it
Independent audit firms compete for EVM contract work. Getting equivalent scrutiny on Go chaincode running inside your own network means a far shorter list of candidates.
When a member walks away
A consortium chain depends on other members keeping nodes up. When one quits, you inherit their validator or lose the quorum that made it a consortium.
The trade-offs
Four dimensions that decide it later
Both options work. These are the four places where a decision made this month shows up as a cost next year.
- COST OF CHANGE
- Harder in code, easier in people
- Redeploying a public contract needs a proxy you designed in advance. Changing chaincode is straightforward until four legal departments have to endorse the same version, which is where the months actually go.
- TIME TO LAUNCH
- Public ships considerably sooner
- A token with a simple dApp runs 3–5 weeks, and an audited production dApp 10–14. Standing up a permissioned network starts around 8–16 weeks before any of your business logic exists.
- WHO MAINTAINS IT
- A developer, or a whole team
- On a public chain the network's uptime is someone else's problem and Solidity hiring is easy. A permissioned network makes you responsible for the nodes and the pager, which is a standing DevOps commitment.
- WHAT BREAKS FIRST
- Fees on one, the consortium on the other
- Public chains fail during congestion, when a fee spike prices out your smallest transactions. Permissioned networks fail socially: partners quietly stop running nodes and you are left operating a slow database alone.
So which one should you pick?
Most people arriving at this page should use a public chain, usually a low-fee one. A good number should use neither — hashes anchored from your existing database buy the audit trail without a network to run. Permissioned earns its place in a narrower set of cases than it is sold for.
Choose a public blockchain if…
- People outside your contracts must verify the record without asking you first.
- The product involves a token, wallets, or settlement between strangers.
- You want an existing explorer, wallet standard and audit market on day one.
- Nobody on your team wants to be paged about validator uptime.
Choose a private or permissioned chain if…
- Every participant is a named organisation with a contract already signed.
- Amounts or counterparties would expose your commercial terms to a competitor.
- A regulator requires data residency or a known identity behind every writing node.
- Your volume and per-transaction economics make public chain fees genuinely unworkable.
Frequently Asked
Questions
Common questions about picking a chain, keeping data private, and what a permissioned network costs to run.
Often, yes. If your company runs every node, approves every member and can rewrite state by agreeing with itself, you have a slower Postgres with a consensus algorithm attached. It becomes something else the moment a second organisation you cannot overrule runs a node and endorses transactions. That is the test we apply in discovery: name the other node operators. If you cannot name them, we usually recommend a normal database with signed, append-only audit logs, plus hashes anchored to a public chain when independent verification genuinely matters.
Partially, and not by encrypting it and hoping. The workable pattern keeps the data in your own database and writes only a hash on-chain, so anyone can prove a record has not changed without reading it. Amounts, addresses and timing still leak, so the shape of your business stays visible even when the content does not. Zero-knowledge tooling hides more, at real complexity and a smaller pool of engineers who can maintain it. If the metadata itself is the secret, that is a legitimate reason to look at a permissioned network.
Two things decide it: where your users are, and what a single transaction is worth. High-value, low-frequency settlement can justify a high-credibility mainnet, where fees buy the strongest security assumptions available. Consumer volume nearly always belongs on a low-fee, high-throughput chain, because one congestion spike that prices out a small transaction kills a product faster than any latency problem. We also check wallet availability in your users' region and whether independent auditors already work with that chain's tooling, since an unaudited contract holding funds is the most expensive saving in this business.
Usually true, and rarely the right reason to pick one. A permissioned network confirms quickly because a small set of known validators agree and there is no fee market to bid into. But if throughput were your only problem, a replicated database would beat both options comfortably and cost less to operate. Speed becomes a real argument only when you already need a multi-party ledger for another reason and public chain economics will not carry your volume. Ask any vendor leading with throughput what they would say if you proposed Postgres instead.
A token with a simple dApp on a public chain ships in roughly 3–5 weeks. A production dApp with audited contracts, a backend and an admin panel runs 10–14 weeks, with the audit adding 2–4. A permissioned network typically starts at 8–16 weeks for the network itself, before your business logic. Running costs invert: public chains bill per transaction and nothing at rest, while permissioned networks bill nothing per transaction and never stop billing for nodes and monitoring. We scope both honestly and quote to your budget.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.