Private vs Public Blockchain: How to Choose, and When You Shouldn’t Build on Either (2026)

Here’s the unfortunate truth about the private-versus-public blockchain conversation. By the time most teams get to it, they’ve already chosen wrong.

It usually plays out like this. An exec read something about blockchain. A vendor came in with a pitch deck. Someone somewhere said “we should do this on a private chain because public seems risky,” or the opposite, “we need to be decentralised, so it has to be public.” A POC gets funded. Three months later someone realises the thing they built doesn’t need a blockchain at all, or needs a completely different flavour of one than what they’re building.

That cycle is avoidable. The private-versus-public question isn’t actually the first question — or even the second. It’s the third, and everything else being right depends on getting the earlier ones right first.

So this piece does something different. It walks through the actual decision tree — do you need a blockchain at all, permissioned or permissionless, which platform, when to walk away — in the order a competent technical team would work through it. Including the parts of the answer that nobody selling blockchain consulting really wants to say out loud.

 The recommendations below are shaped by watching what works in production and what gets quietly killed twelve months after launch.

Do You Actually Need a Blockchain? (The Question That Kills 60% of Projects)

Most use cases that end up on a blockchain would have been better served by a well-designed distributed database with strong access controls, a signed audit log, and reasonable backup hygiene. Blockchain brings two things the database doesn’t. Decentralised trust. Tamper-evidence across parties that don’t fully trust each other.

If you don’t need either of those, you’re paying the blockchain tax for nothing. And blockchain has a tax. It’s slower, more expensive to run, harder to hire for, and significantly more complicated to change once deployed.

Here’s a clean four-part test. Blockchain is the right tool when:

• Multiple parties need to share state
• Those parties don’t fully trust each other, or a single intermediary
• A single source of truth is genuinely required
• The cost of disputes, reconciliation, or audit is high enough to justify the infrastructure

If any one of those four is missing, the honest answer is probably “use a database.” If two or more are missing, the honest answer is definitely “use a database.”

Concrete examples. Where blockchain wins this test:

• Interbank settlement between competing institutions that don’t use each other as intermediaries
• Supply-chain provenance tracking across suppliers-of-suppliers, where no single company sees the whole chain
• Asset tokenisation for fractional real estate or private securities, where compliance requires demonstrable ownership history
• Decentralised finance protocols where the whole point is open participation without a gatekeeper
• Digital identity attestations across administrative boundaries (a university issues a degree, a foreign employer verifies it, without either trusting a central registry)

Where it fails the test, but gets built anyway:

• Internal document management inside a single company — a database with signed storage does this at 2% of the cost
• Loyalty points for a single retailer — a database does this, and blockchain adds zero real decentralisation because the retailer controls the whole system anyway
• Audit trails for a regulated entity — a database with cryptographic chaining does this, and the auditor doesn’t care that it’s on a chain
• “Tokenised” internal workflow state — your BPM tool solves this, please use it

Every one of those is a real pattern. I’ve watched teams start them, gather executive support, burn six to ten months, and quietly rebuild on Postgres a year later after the consultants left. Nobody talks about those projects in case studies. There’s a reason for that.

If, after walking through those four questions honestly, your use case still needs a blockchain — good, you’re past the first filter. Most ideas that started with “we should explore blockchain” don’t get past it. The ones that do, get interesting. That’s when the private-versus-public question becomes the actual conversation.

The Real Distinction Isn’t Private vs Public — It’s Permissioned vs Permissionless

Quick terminology clean-up, because this is where half the confusion starts. “Public” and “private” are shorthand, and imprecise shorthand at that. The properties that actually drive architectural decisions are permissionless versus permissioned.

Permissionless: anyone can join, run a node, validate, transact. No gatekeeper. The chain trusts cryptography and economic incentives to keep participants honest. Ethereum, Bitcoin, Solana, Polygon PoS, Avalanche C-Chain. These are the canonical permissionless networks.

Permissioned: participants are identified and authorised to join the network. A governing body — a consortium of organisations, a single enterprise, sometimes a regulator — decides who’s in. The chain trusts cryptography plus institutional identity. Hyperledger Fabric, R3 Corda, Quorum. These are the canonical permissioned networks.

Then there are the sub-flavours that articles love to treat as separate categories but really aren’t:

• Consortium — a specific flavour of permissioned, governed jointly by a group of organisations. Most enterprise blockchain deployments are consortium networks, even when marketing calls them “private.”
• Hybrid — a permissioned core with a public-chain anchor for auditability. Not really its own architecture. More a deployment pattern that’s getting more common.

The public/private binary also leaks in practice. Polygon is permissionless at the base layer but supports permissioned configurations. Ethereum can be run as a private fork for a single consortium; several major enterprise deployments do exactly this. The real property isn’t which chain you use — it’s how you configure participation, validation, and data visibility within it.

For the rest of this article, we’ll keep using “private” and “public” because those are the words buyers actually search for. Just read them as “permissioned” and “permissionless” in your head. The distinction matters when it comes time to write requirements.

Public and Private Blockchain, Defined

Quick definitional pass for readers who landed here before the permissioned-vs-permissionless clean-up lands. Skip this section if you’re already clear on the basics.

What is a public blockchain?

A public blockchain is an open, permissionless network where anyone with an internet connection can run a node, validate transactions, and transact. There’s no central authority, no gatekeeper, no membership list. The ledger is globally visible — every transaction, every address, every smart contract call is on public record. Bitcoin is the canonical example. Ethereum is the canonical example for smart-contract-enabled public chains. Solana, Polygon PoS, and Avalanche sit in the same category even though their technical architectures differ.

The security model is economic. Validators are anyone willing to stake capital (proof of stake) or burn electricity (proof of work), and the protocol is designed so that attacking the network costs more than playing honestly. Trust is replaced by math and market forces, rather than by identity or legal agreement.

Benefits of a public blockchain

The reasons public chains are worth building on, when they fit:

• Genuinely open participation — no onboarding workflow, no KYC barrier at the protocol layer, no gatekeeper who can revoke access
• Transparency and auditability by default — the state of the chain is visible to anyone, which is sometimes a bug but often a feature
• Censorship resistance — no single entity can unilaterally stop a transaction from being included
• Network effects and liquidity — public chains (especially Ethereum and its L2s) have deep ecosystems of developers, tools, and capital you can plug into
• Interoperability with the broader crypto ecosystem — stablecoins, bridges, DeFi primitives, NFT infrastructure all live on public chains
• Immutability of settled transactions — once confirmed, a transaction cannot be rolled back by any operator or administrator

Drawbacks of a public blockchain

The costs, honestly stated:

• Throughput is lower than what a database or permissioned chain can deliver — even Solana or modern L2s sit below what enterprise infrastructure regularly achieves
• Transaction costs are denominated in the chain’s native token, which makes them market-exposed; gas spikes are not hypothetical
• Privacy has to be layered on rather than configured — ZK proofs and off-chain computation are doable but expensive in engineering time
• Regulatory posture toward public chains shifts, and it shifts differently across jurisdictions — that uncertainty is real, not marketing
• Finality is probabilistic on many public chains rather than instant, which matters for settlement workflows with strict SLAs
• Compliance with data-protection regimes like GDPR’s right to erasure is architecturally awkward on an immutable ledger

What is a private blockchain?

A private blockchain — more precisely, a permissioned blockchain — is a network where participation is controlled. A governing body, whether that’s a single organisation, a consortium of organisations, or a regulatory authority, decides who can run a node, who can validate, and who can read the data. Identity sits at the protocol layer; membership is explicit.

Hyperledger Fabric, R3 Corda, and Quorum are the canonical examples. What they share isn’t a specific technology so much as a governance model: trust is bootstrapped from institutional identity and legal agreements among named participants, rather than from economic incentives among anonymous ones. In most real deployments, a “private” blockchain is actually a consortium — multiple organisations sharing governance, rather than one company running a chain by itself.

Benefits of a private blockchain

Why enterprise buyers reach for private chains:

• High throughput and low latency — permissioned consensus with a small validator set can deliver sub-second finality and thousands of TPS
• Configurable data visibility — channels, private transactions, and point-to-point sharing let different participants see different data subsets without cryptographic workarounds
• Predictable costs — operational expenses rather than transaction fees, not exposed to token market volatility
• Regulatory fit for identified participants — KYC and AML compliance can be baked into the network layer, which makes working with regulated entities much easier
• Governance flexibility — the consortium can upgrade the protocol, change rules, and resolve disputes without requiring global consensus
• Data-protection compliance is easier — correcting or redacting data is architecturally possible when governance permits it

Drawbacks of a private blockchain

The trade-offs, which are often understated in enterprise blockchain marketing:

• Security is only as strong as the validator set — if 51% of consortium members collude or are compromised, history can be rewritten
• Network effects are limited to the consortium — you can’t plug into the broader ecosystem of tooling, liquidity, and composability that public chains provide
• Operational overhead is real — running the infrastructure, managing membership, coordinating upgrades, handling disputes all takes sustained effort
• Vendor and consortium lock-in — leaving a Fabric consortium or migrating off Corda isn’t trivial once you’ve committed
• The governance problem is often harder than the technology problem — deciding who gets to change what rule, and when, sinks more consortium projects than any technical issue
• The honest question of whether you needed a blockchain at all (see the opening section) applies with extra force to private chains — it’s easier to accidentally build a very expensive distributed database

Four Decision Dimensions That Matter More Than the Feature Table

The standard side-by-side comparison table you see in most blockchain articles is close to useless for actual decisions. “Public has transparency, private has privacy” doesn’t help anyone architect anything. The questions that actually drive design choices are these four.

Who can participate?

The openness of the participation layer. Permissionless networks allow anyone with an internet connection and a wallet to join and transact — no identity check, no gatekeeper, no onboarding workflow. Permissioned networks gate participation through KYC, membership agreements, or governance votes.

For use cases where participants are regulated entities — banks, licensed brokers, healthcare providers, government agencies — permissioned is often required for compliance reasons alone. Your regulator wants to know who’s on the network, and “anyone on the internet” isn’t an acceptable answer when patient data or settlement instructions are on the wire.

For use cases where the whole point is open participation — consumer DeFi, open NFT marketplaces, censorship-resistant applications, cross-border remittance — permissionless is the point. Gate-keeping undermines the product.

This question alone resolves maybe 60% of private-versus-public debates. If you know who your users are going to be, and you need to verify their identity before they touch the system, you’re building permissioned. If you don’t know, and you don’t want to know, you’re building permissionless.

Who validates transactions?

The consensus layer. This is where the architectural consequences get concrete.

Permissionless chains use economic-security consensus. Proof of work (Bitcoin). Proof of stake (Ethereum post-Merge, Solana, Polygon). Delegated proof of stake variants. The idea is that validators are anyone willing to put capital at risk, and the protocol makes attacking the network more expensive than playing by the rules.

Permissioned chains use institutional consensus. Practical Byzantine Fault Tolerance (PBFT) variants. Raft. Istanbul BFT. The idea is that validators are specific, named organisations who’ve agreed to participate, and the protocol just needs to keep them in sync even if a minority goes rogue or goes offline.

Concrete downstream effects:

• Permissioned consensus is much faster. Finality in milliseconds to a few seconds, compared to ~12-second Ethereum blocks or Bitcoin’s ~60 minutes of economic finality.
• Permissioned consensus is dramatically cheaper per transaction. You’re paying infrastructure costs, not paying gas.
• Permissioned consensus is only as trustworthy as the set of validating institutions. If 51% of your consortium decides to rewrite history, they can. Economic security is replaced by institutional reputation and legal agreements.

That last point is why permissioned consensus is fine for a settlement network among regulated banks (they’re under enough legal and reputational constraints that collusion is unlikely) and bad for a decentralised oracle system (the whole point is avoiding exactly this kind of collusion risk).

Who can see the data?

The visibility layer. On a permissionless public chain, transaction history is globally visible by default. Every address, every amount, every smart contract call — all public record. Privacy has to be layered on top through zero-knowledge proofs, commit-reveal schemes, or off-chain computation. Doable, but non-trivial, and expensive in both compute and engineering time.

On a permissioned chain, data visibility is configurable by design. Hyperledger Fabric has “channels,” which are essentially sub-networks where specific organisations see specific data. Corda goes further — data is shared point-to-point between participants, not replicated to everyone. Quorum has private transactions. Each of these lets different participants see different subsets of the data, without cryptographic gymnastics.

For enterprise use cases with genuine confidentiality requirements — trading strategies, patient records, supplier pricing — permissioned chains are significantly easier to deploy. Not because privacy is impossible on public chains. Because the engineering budget you’d spend on ZK circuits and privacy overlays is better spent on just using a chain that supports selective visibility natively.

Who pays to run it?

The economic layer, which almost nobody thinks about until the second year of operation.

Public chains charge transaction fees in the chain’s native token. ETH on Ethereum, MATIC on Polygon, SOL on Solana. Someone running a DApp pays per transaction, and those costs can spike unpredictably — see every NFT mint that ever pushed Ethereum gas to $200-per-transaction, briefly. Your ops cost is usage-linked and market-exposed.

Permissioned chains are paid for by consortium members directly. Infrastructure costs — servers, ops, monitoring — rather than transaction fees. More predictable. Less exposed to whatever the market is doing with the native token.

Over long time horizons and high transaction volumes, permissioned is usually cheaper. Over low volumes, the fixed infrastructure cost of a permissioned network can make public chains more economical — especially once L2s like Arbitrum and Base dropped transaction costs to fractions of a cent.

The Platforms That Actually Matter in 2026

This section covers the platforms that realistically end up on an enterprise shortlist. There are hundreds of L1s and L2s by now. Most of them don’t matter for your decision. These do.

Ethereum (permissionless)

The default for anything needing open, programmable smart contracts. Post-Merge, post-multiple L2 rollups (Optimism, Arbitrum, Base, zkSync, Scroll), Ethereum in 2026 is an ecosystem more than a single chain.

For enterprise buyers, the realistic consideration is usually Ethereum-compatible L2s rather than mainnet itself. Much cheaper, faster finality, still benefits from Ethereum’s security model for settlement. Mainnet is where you put things that need maximum decentralisation and can afford $1 to $5 per transaction. L2s are where most actual application activity lives now.

Strengths: largest developer ecosystem by a wide margin, most mature tooling, deepest liquidity, wide regulatory familiarity. Weaknesses: the L2 landscape is still fragmenting, bridging between L2s is an unsolved UX problem, and “Ethereum” as a purchasing decision now requires you to also pick an L2. Read our work on Ethereum development for the current state of play.

Polygon (permissionless, Ethereum-compatible)

The default enterprise-facing permissionless option. EVM-compatible, low fees, real enterprise deployments — Starbucks Odyssey before it wound down, Nike’s .Swoosh before that wound down, Reddit collectibles, various supply-chain POCs. Polygon’s broader suite now includes Polygon zkEVM and the Polygon CDK for app-specific chains.

Strengths: cheapest way to deploy Ethereum-compatible contracts at scale, good developer experience, active enterprise sales motion. Weaknesses: a lot of the brand-name enterprise partnerships haven’t survived; the token economics have been complicated; the chain has had security incidents. Polygon development is where most of our mid-market clients end up when they want permissionless with enterprise-friendly economics.

Solana (permissionless)

High throughput — theoretical 65,000 TPS, practical several thousand — very low cost, sub-second finality. Used for consumer applications, high-frequency DeFi, NFT marketplaces, real-time payments. Solana’s Rust-based development stack rather than Solidity is a real consideration if your team is already fluent in EVM.

Enterprise adoption is growing but historically limited by the chain’s outage history — multiple multi-hour halts between 2022 and 2023, largely resolved but still in institutional memory. Anyone evaluating Solana for enterprise in 2026 has probably already had to answer the question of what a Solana halt means for their SLA, and the answer shapes whether it’s viable for their use case. See Solana development for the practical considerations.

Hyperledger Fabric (permissioned)

The most widely deployed enterprise blockchain. IBM-originated, now under the Linux Foundation’s Hyperledger Project. Pluggable consensus, private data channels, chaincode written in Go, JavaScript, or Java rather than smart contracts per se.

Genuinely enterprise in every decision it’s made. Channels let different organisations see different data subsets. Membership Service Provider gives you identity. The pluggable consensus means you can pick PBFT or Raft depending on your trust model. The canonical choice for consortium networks, especially where IBM is already in the account.

Strengths: most mature permissioned chain, real deployment footprint, extensive documentation, wide vendor support. Weaknesses: operationally heavy, steep learning curve for teams coming from Ethereum, the overall consortium blockchain momentum has slowed since 2022. Still the default for banking and supply chain consortium projects. Our Hyperledger Fabric practice covers the implementation detail.

R3 Corda (permissioned, specialised)

Built specifically for financial services. Worth calling out that Corda isn’t strictly a blockchain in the traditional sense — data is shared point-to-point between participants, not replicated to every node on a global ledger. This is a feature, not a bug, for regulated financial workflows: you don’t want counterparty trading data visible to every other participant.

Designed around the primitives financial services actually uses — notaries, contracts in Kotlin or Java, flows rather than smart contracts. Very strong in foreign exchange, derivatives, syndicated loans, and interbank settlement. Narrower applicability than Fabric — you won’t see Corda in supply chain or healthcare — but very strong in its niche.

Quorum, Besu, and other Ethereum-derived permissioned chains

Quorum was JP Morgan’s fork of Ethereum for permissioned deployment. It’s now under ConsenSys and its strategic future has been uncertain for a couple of years — evaluate the current state before committing. Hyperledger Besu remains a solid Ethereum-client choice for permissioned networks, with IBFT2 consensus. Private Geth networks are still around.

The appeal of this category: you get Ethereum tooling (Solidity, Truffle or Hardhat, MetaMask-compatible wallets) with permissioned characteristics. The pitch is “Ethereum developers on a private chain.” The reality is more mixed — you’re running less-battle-tested permissioned consensus, with a smaller community than Fabric on one side and Ethereum on the other.

Cosmos, Polkadot, and the app-chain approach

The emerging middle ground, and genuinely interesting for enterprise in 2026. Cosmos zones and Polkadot parachains let a consortium or a single organisation run their own sovereign chain while still interoperating with a broader network through IBC (Cosmos) or XCM (Polkadot).

This is where hybrid models actually start to make sense. You get permissioned-chain control — your own validator set, your own governance, your own data visibility rules — with permissionless-ecosystem connectivity when you need it. The Inter-Blockchain Communication protocol (Cosmos) and XCM (Polkadot) are mature enough in 2026 that cross-chain interop isn’t the research problem it was five years ago. For consortia that want sovereignty without isolation, the app-chain route is worth serious consideration. Still earlier in enterprise adoption than Fabric, but catching up.

Platforms at a Glance

One reference artefact. Don’t treat it as the decision — treat it as the cheat sheet you come back to while working through the four decision dimensions above.

Platform	Permission	Realistic TPS	Finality	Contract language	Best for / watch out
Ethereum mainnet	Permissionless	~15	~12s (economic)	Solidity, Vyper	Max decentralisation, deepest ecosystem. Cost and throughput — use L2s.
Ethereum L2 (Arbitrum, Base)	Permissionless	~2,000+	Seconds to minutes	Solidity	Practical home for most dApps in 2026. Bridging UX still messy.
Polygon PoS	Permissionless	~7,000	~2s	Solidity	Enterprise-friendly cost. Past security incidents; watch governance.
Solana	Permissionless	~3,000–4,000	<1s	Rust	Speed and cost. Outage history matters for SLA-bound use cases.
Hyperledger Fabric	Permissioned	~1,000–3,000	~1s	Go, JS, Java	Default consortium choice. Operationally heavy.
R3 Corda	Permissioned	~600+	Sub-second	Kotlin, Java	Financial services specialist. Narrow but deep.
Cosmos app-chain	Either	~10,000	~6s	CosmWasm (Rust)	Sovereign chain with interop. Still maturing for enterprise.

One caveat on this table: throughput numbers in particular are what platforms reliably sustain in production, not what they claim in marketing. Theoretical maximums differ substantially — Solana advertises 65,000 TPS, Fabric has published 20,000+ TPS benchmarks in controlled settings. Neither number is what you’ll see on the network you actually deploy on.

Mapping Use Cases to the Right Model

Six use cases, with honest recommendations. Not a vendor list — practitioner reads.

Interbank settlement among regulated banks

Permissioned. Almost certainly Corda or Fabric. The participants are identified regulated entities, confidentiality of trading data is non-negotiable, settlement finality needs to be institutional-grade, and the regulator wants to see the whole system operating under named-participant governance. This is where permissioned was designed to win and it does.

Public-facing tokenised real estate marketplace

Permissionless. Ethereum L2 or Polygon. The whole product is “anyone can buy a fractional share,” which means open participation is the feature. A permissioned chain would defeat the point. Smart contract auditability is a customer trust feature, not a liability. Compliance (KYC for buyers) happens at the application layer, not the chain layer.

Supply-chain provenance across multi-tier suppliers

Permissioned consortium (Fabric) is the common choice, and it’s usually the right one for the first implementation. But the more sophisticated play in 2026 is hybrid — permissioned chain for the transactional detail, with periodic anchoring to a public chain (Ethereum or Polygon) for independent auditability. That gives participating organisations the privacy and throughput of permissioned, plus a tamper-evident public anchor that external auditors or customers can verify. Worth considering from day one rather than bolting on later. See our blockchain document management work for related patterns.

Digital identity and verifiable credentials

Depends entirely on who the issuer is and how public the use needs to be. For corporate or government-issued identity (employee credentials, professional licences), permissioned makes sense — the issuer is authoritative, verification happens against known identity anchors, and data privacy matters. For self-sovereign identity where individuals control their own credentials and anyone can verify, permissionless is architecturally natural. Don’t let anyone sell you a one-size-fits-all answer here.

DeFi protocol or DEX

Permissionless, with basically no other option. A permissioned DeFi protocol is a contradiction in terms. If you’re building something that needs to interoperate with the existing DeFi ecosystem, Ethereum L2 or an EVM-compatible chain is the practical default. DeFi development work we’ve done consistently lands here.

Internal document management with audit requirements

Go back to the four-part test. Seriously. If the documents are controlled by a single organisation and the auditor is the only external party, a properly-designed database with cryptographic chaining of records will meet every actual requirement at a small fraction of the cost. Blockchain here is almost always a solution looking for a problem. If someone on the team really wants to use blockchain for this reason, talk them into using a properly-architected Postgres first and see if the project still looks attractive.

When Blockchain Is the Wrong Tool Regardless of Which Type

Nobody in blockchain wants to write this section. It’s worth writing anyway, because overclaiming is endemic to this space and the long-term credibility play is honesty. Here are the scenarios where blockchain — private or public — fails the test and shouldn’t be your answer:

• One party controls all the data anyway. A database with a signed audit log is cheaper and does the same thing.
• A trusted intermediary already exists, works fine, and isn’t charging rents that would justify disintermediation. Blockchain’s pitch is avoiding the intermediary. No intermediary problem, no blockchain pitch.
• Performance requirements are genuinely high-frequency — tens of thousands of transactions per second sustained. Even the fastest blockchains aren’t in this league yet for anything beyond narrow benchmarks. If you’re building a real-time trading engine or a payment switch, use specialised infrastructure.
• Data privacy requirements are incompatible with the chain’s visibility model and you haven’t budgeted for the privacy overlay. ZK proofs aren’t free. Channels and private transactions have their own trade-offs. Figure this out at scoping, not at deployment.
• Regulatory requirements demand specific data-residency or right-to-be-forgotten guarantees that blockchain architecturally makes hard. GDPR’s right to erasure sits awkwardly on an immutable ledger. Solvable, but requires careful architecture from the start.
• The stated goal is “we want to do something with blockchain.” If the project is reverse-engineered from the desire to use the technology, the outcome is usually what it sounds like. Run, don’t walk.

The sophisticated move isn’t reaching for blockchain because it’s in the roadmap deck. It’s picking the simplest architecture that meets the actual requirement. Sometimes that’s a public chain. Sometimes it’s a permissioned one. Often it’s a well-designed database. The decision belongs to the requirements, not the technology shopping list.

Market Data Signals Strong Public Blockchain Adoption for Tokenization

One place where the private-vs-public debate is getting quietly resolved in public is asset tokenization — the category covering tokenised treasuries, real-world assets (RWAs), stablecoins, and security tokens. The numbers are worth looking at, because they point to where enterprise money is actually landing rather than where the glossy case studies say it should.

A recent summary by InvestaX, a Singapore-licensed tokenization platform operator, pulls the data together. As of May 2024, roughly 60% of tokenized treasury products were running on Ethereum (per The Block), 87% of locked RWA token value sat on Ethereum (per DefiLlama), and six of the seven major RWA protocols deployed on Ethereum (per RWA.xyz). Grayscale’s report “Public Blockchains and the Tokenization Revolution” makes the same argument: banks have explored private infrastructure largely because of regulatory constraints, but asset managers have preferred public chains or hybrid setups.

The overall blockchain market, for context, is projected to grow from around $44 billion in 2025 to roughly $746 billion by 2032 (Fortune Business Insights), a compound annual growth rate in the high 50s. A meaningful share of that growth is tokenization.

The reasons for the tilt toward public chains in this specific use case are interoperability (RWA tokens that sit alongside stablecoins, DeFi collateral, and liquidity pools are more valuable than isolated ones), network effects (the best developers, the deepest tooling, and the most capital are on public chains), and regulatory clarity beginning to catch up in major jurisdictions for tokenized securities on public infrastructure.

That doesn’t make public chains automatically right for every tokenization project. A bank that needs to tokenize its internal trading book, with counterparties who are exclusively other regulated institutions, has a perfectly good reason to use Corda or Fabric. But for asset managers looking to issue tokens that will be traded, held in DeFi protocols, or used as collateral across the broader digital-asset ecosystem, the data is telling a clear story about where the action is.

Read this as one data point in your platform decision, not as a directive. The four-question test at the top of this article still applies — if your tokenization use case doesn’t actually need the interoperability a public chain offers, a permissioned deployment can still be the right answer. Numbers like these matter at the margin; they don’t override the underlying architectural fit.

How to Actually Decide: A Four-Step Framework

Pulling the pieces together. If you’re working through this now for a real project, here’s the order:

1. Run the four-question blockchain test. Multiple parties sharing state? Partial trust? Single source of truth required? High cost of disputes? If any of these fails, the answer is don’t build on blockchain. Try a properly designed database first.
2. Pick permissioned or permissionless based on participation. Who participates? Do they have existing identity? Is open participation a product feature or a compliance problem? This question resolves most of the private-versus-public debate on its own.
3. Narrow the platform by operating constraints. Throughput, finality, governance, cost, developer stack, regulatory fit, existing team skills. This is where Ethereum, Solana, Polygon, Fabric, Corda, and Cosmos actually differ in ways that matter.
4. Prototype honestly. Build the same thing on the two most plausible platforms for your use case. Measure, don’t pitch-deck. Most teams skip this and regret it — sometimes at significant cost. A two-week spike saves six months of the wrong deployment.

The common failure mode is skipping step 1 (under pressure from “the board wants blockchain”) and skipping step 4 (under pressure from “we already picked the platform”). Both shortcuts produce projects that look like they’re going to work right up until they don’t.

Conclusion

The private-versus-public blockchain decision is framed wrong in most articles, and that framing is a decent share of why these projects go sideways. The real decision tree has “should we build on a blockchain at all” at the top, permissioned-versus-permissionless in the middle, and platform selection at the bottom — with the question of whether blockchain is the wrong tool regardless sitting quietly in the background the whole way through.

Get the first question right and the rest gets much easier. Most use cases that pass the four-part test have a fairly obvious answer on permissioned versus permissionless once you know who participates and who validates. Most platform shortlists collapse to two real options once you filter by throughput, finality, and existing team skills. Prototype before you commit, and most of the rest of the risk gets written out of the project.

If you’re working through this now — particularly if you’re in the awkward period between “we think blockchain might help” and “we’re ready to scope the build” — that’s the conversation where outside help genuinely pays back its fee. We’ve done seven years of this across both sides of the private-public line; we’ll tell you honestly which side your problem lives on, and whether it belongs on a chain at all. Get in touch and we’ll talk through what you’re actually trying to build.