ComparisonHashSphere
HashSphere or public Hedera mainnet: deciding where a workload runs
Choosing between public Hedera mainnet and a permissioned HashSphere network is a decision about one workload, not about Hedera in general. This page compares the two environments on ten criteria, shows hybrid patterns that keep transactions private while anchoring proofs publicly, and gives a weighted worksheet to fill in with your own team. HashSphere specifics come from the provider's published material and should be confirmed with the provider.
On this page
- Start with the workload's properties, not the network
- The two environments and the patterns between them
- Ten criteria for placing a workload on Hedera
- Hybrid patterns that keep both options open
- A weighted scoring worksheet for your team
- Placement rules for common situations
- Three hypothetical placements
- Questions to put to the provider before committing
- Questions and answers
- Sources
Start with the workload's properties, not the network
Placement debates go wrong when they compare networks in the abstract. A workload has a handful of non-negotiable properties, and those decide the answer. Openness: unknown parties must be able to verify, hold or trade something. Confidentiality: amounts, counterparties or positions stay with those entitled to see them. Control: a defined group decides who joins, where infrastructure runs and when software changes. Reach: the asset must interact with wallets, tokens and services already on a public network.
This page assumes a distributed ledger already fits. The general comparison of network categories belongs to the distributed ledger hub; the question here is narrower. For an institution already looking at Hedera, which Hedera environment should this particular workload use, or should it use both?
The two environments and the patterns between them
- Public Hedera mainnet
- An open network where anyone can create an account, governed by a council of organisations4. Fees are set in US dollars and charged in HBAR at a live exchange rate1, and transaction and record data flow to mirror nodes that anyone can run or query2.
- Permissioned HashSphere network
- A private network built on Hedera technology that runs as an isolated network with hashgraph consensus, offered as a managed service or self-hosted, with participation, validator model and node locations defined by the institutions involved3. The hub describes participation as KYC-gated; confirm admission controls with the provider.
- Hybrid placement
- A design in which some steps of a workload run privately and others on mainnet, for example private settlement with public proofs, or issuance in one environment and distribution in the other.
- Anchoring
- Publishing a digest of private activity to a public ledger, so outsiders can later verify that a record existed unchanged at a point in time without seeing its content.
Ten criteria for placing a workload on Hedera
| Criterion | Public Hedera mainnet | Permissioned HashSphere network | Hybrid |
|---|---|---|---|
| Participant identity | Pseudonymous accounts; anyone may join | Participation defined by the institutions; admission controls agreed with the provider | Identified participants on the private side, open access for the public step |
| Transaction visibility | Transaction and record data are public through mirror nodes | Provider describes on-chain transaction confidentiality and private transfers; confirm the scope | Details stay private; only digests or selected transfers become public |
| Data residency | Node locations follow the public network's operators, not your choice | Node operation can be restricted to a country or cloud provider | Residency-sensitive data stays on the private side |
| Operating responsibility | The network runs the ledger; you run applications, keys and integration | You, a member or the provider run nodes, monitoring and upgrades | Both sets of duties, plus the link between them |
| Fee model | Published per-transaction fees set in US dollars and paid in HBAR | Agreed commercially; confirm how transactions, nodes and support are charged | Both, plus any interoperability costs |
| Consensus and finality | Hashgraph consensus with aBFT security across the public node set | Hashgraph consensus with aBFT security inside an isolated network with fewer operators | Each step inherits the finality of the environment it runs in |
| Governance | Council governance you can observe but not direct | Your founding group governs admission, operations and change | Two governance regimes to align, including who may pause the link |
| Reach | Direct access to public wallets, tokens and services | Limited to members unless flows cross to mainnet | Public reach for the steps that need it |
| Interoperability | Native to the public ecosystem | Provider describes native interoperability with mainnet through CLPR; verify options and maturity | Depends on that interoperability path working under stress |
| Exit and portability | No operator to exit; your exposure is to the public network's evolution | Exit terms with the provider and members matter; EVM compatibility eases moving contracts | Exit must cover both environments and any in-flight transfers |
HashSphere entries summarise the provider's published description3 and must be confirmed for your deployment. Mainnet entries summarise Hedera documentation12.
Hybrid patterns that keep both options open
Private transactions, public proofs. Settlement runs on the permissioned network, and a digest of each batch is written to a topic on the public Consensus Service. Outsiders can later check that a record existed unchanged without seeing it. Publication is one-way and nothing of value crosses networks, which makes this the simplest hybrid.
Issue privately, distribute publicly. An asset is created and administered among identified institutions, then selected units move to mainnet so public wallets can hold them. This depends on the interoperability path the provider supports, which it describes as CLPR3. ColdAI's own CLPRouter builds on that protocol and is not yet live on mainnet, so treat cross-network asset movement as something to prove in testing with the provider.
Public issuance, private servicing. The token lives on mainnet for reach, while sensitive servicing data, such as investor records, stays in a permissioned environment or off-ledger. For many workloads this removes the need for a private network altogether.
A weighted scoring worksheet for your team
Fill this in with business, risk, legal and technology leads together. The arguments the numbers force into the open matter more than the numbers.
List the criteria that matter
Start from the ten criteria above, drop any that do not apply and add workload-specific ones such as availability of a settlement asset.
Weight each criterion
Give each a weight from one to five, agreed across the group. Disagreement about a weight usually reveals a requirement nobody has written down.
Score each option
Score mainnet, a permissioned network and the most plausible hybrid from one to five on every criterion, noting the evidence behind each score.
Apply knock-outs before totals
Any criterion a regulator or the board treats as mandatory overrides the weighted total. A high score cannot buy back a failed residency requirement.
Total and sanity-check
Multiply, add up and compare. If the winner surprises the room, revisit the weights, not the scores.
Record open provider questions
Every score that depends on an unconfirmed HashSphere capability becomes a question for the provider, answered before the decision is final.
Placement rules for common situations
- If
Unknown parties must verify, hold or trade the asset, and transparency is part of its value.
ThenRun it on public mainnet, with personal and commercial data kept off-ledger.
A permissioned network would remove the openness the workload exists to provide.
- If
All participants are identified institutions and transaction details are commercially sensitive.
ThenRun it on a permissioned HashSphere network, once the confidentiality features are confirmed with the provider.
Control over admission and visibility is the requirement, and public reach adds little.
- If
Supervisors require you to know who operates the infrastructure and where it runs.
ThenFavour a permissioned network with node locations fixed in the governance agreement.
Public mainnet node locations are not yours to choose.
- If
Most activity is private, but outsiders need to verify integrity later.
ThenUse a hybrid: private processing with digests anchored on mainnet.
One-way anchoring gives public verifiability without moving data or assets across networks.
- If
No one is willing to operate or govern a private network.
ThenUse mainnet with off-ledger confidentiality, or reconsider whether a ledger is needed at all.
A private network without a committed operator becomes orphaned.
Three hypothetical placements
Questions to put to the provider before committing
Questions and answers
Is a permissioned network still worth calling a distributed ledger?
Yes, if several organisations write to it, each can verify the shared history and no single member can rewrite it alone. Those properties survive permissioning; what changes is who may join and who sees what. If one institution writes everything and the others only read, the ledger adds little over a well-controlled database.
Can we start on a private network and move to mainnet later?
Contract code written for the EVM is often portable, since the provider describes HashSphere as EVM-compatible. Moving live assets and their history is harder: holders, keys, admission rules and records must move together, and regulated assets may need fresh approvals. If a later move is likely, keep identifiers portable and test the interoperability path early.
Who runs the nodes on a HashSphere network?
That depends on the operating model you agree. The provider describes a managed network service and a self-hosted option, with the validator model, node count and node locations chosen by the institutions involved. Members, a single operating institution or the provider may run nodes, and the choice belongs in the founding governance terms alongside who monitors, upgrades and handles incidents.
Does putting a workload on mainnet make our data public?
Transactions on mainnet are visible through mirror nodes, but your design decides what a transaction contains. Personal data and commercial terms can stay off-ledger, with only references, digests or token movements on the public network. For many workloads that is enough. The detailed visibility model is on who sees what on a permissioned ledger.
Sources
- Mainnet fees — Hedera documentation · checked 10 October 2026
- Mirror nodes — Hedera documentation · checked 10 October 2026
- HashSphere: private networks built on Hedera technology — Hashgraph · checked 10 October 2026
- Our Hedera Hashgraph Practice: why Hedera, and why ColdAI — ColdAI