HashSphere
A shared network with defined participants.
HashSphere is a private network built on Hedera technology for institutions that need control over who participates, where nodes run and how the network is governed. ColdAI works on HashSphere deployments as a delivery partner. We test whether a permissioned network suits the workload, design how each participant connects and help the founding institutions agree governance they can live with. Service terms, availability and interoperability are confirmed with the provider for every engagement.
The opportunity
Start with a decision
worth improving.
A group of institutions needs a shared transaction environment with controlled participation. The design must explain who operates the network, who can join and how applications interact with it.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Define participation
Document the organizations, roles and access requirements. Review the selected service offering and deployment options with the provider before making assumptions about availability or operating responsibilities.
Connect applications
Map the business transactions and data boundaries to the network interface. Design account, signing and reconciliation flows that fit each participant's internal controls.
Operate together
Agree monitoring, change management and incident ownership across participants. Test continuity and integration failure scenarios before expanding the workflow or network membership.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Permissioned-network suitability assessment
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Participant and application architecture
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Governance and operational requirements
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
Explore the practice
Further capabilities
and implementation detail.
What HashSphere is
HashSphere is Hedera's permissioned, enterprise-grade environment for regulated institutions. It is a managed Hedera network with KYC-gated participation, customer-controlled stablecoin issuance, and seamless interoperability with the public Hedera mainnet — giving banks, payment providers, and public-sector clients the operational, privacy, and compliance posture they need without abandoning Hedera's economics, throughput, or finality.
ColdAI's HashSphere service
Tenant design & onboarding
Design your HashSphere tenant — participants, KYC policy, governance, and the bridge to public Hedera — and onboard your counterparties.
Customer-controlled stablecoins
Issue and operate stablecoins or tokenised deposits inside your HashSphere environment using Stablecoin Studio.
Mainnet bridging
Bridge selected flows from HashSphere to public Hedera for settlement, anchoring, or interoperability with public ecosystems.
Operations & SLAs
Run your HashSphere environment end-to-end — monitoring, on-call, change management, and reporting against enterprise SLAs.
Where HashSphere fits
- Bank-led tokenised deposit and stablecoin programmes
- Cross-border settlement consortia
- Public-sector and central-bank deployments
- Regulated capital-markets infrastructure
- Industry consortia that need permissioned DLT
Stand up a HashSphere environment
Engage ColdAI to design, deliver, and operate your HashSphere tenant — with public Hedera interoperability where you need it.
Contact our Hedera teamIn depth
Go deeper on HashSphere decisions
The two questions risk committees ask first: should this workload run on a private network at all, and who will be able to see our transactions once it does?
- 01ComparisonHashSphere or Hedera Mainnet: Where Should a Workload Run?Decide whether a workload belongs on Hedera mainnet, a permissioned HashSphere network or both, using ten criteria, hybrid patterns and a scoring worksheet.
- 02ArchitectureConfidentiality on a Permissioned Ledger: Who Sees WhatA layer-by-layer model of what members, node operators and public mainnet can see on a permissioned Hedera network, with GDPR and key-custody design choices.
What the provider describes, and what we confirm
Hashgraph, the company that offers HashSphere, describes it as an isolated network running hashgraph consensus with aBFT security, available as a managed network service or self-hosted1. Its published material says institutions choose their validator model, node count and node size, and can restrict node operation to a specific country or cloud provider, which matters wherever data-residency rules apply1. The network is EVM-compatible, so Solidity contracts and standard EVM tooling carry over, and Stablecoin Studio is listed among the Hedera tools available to HashSphere users1.
On confidentiality, the provider describes on-chain transaction confidentiality, private transfers and atomic delivery-versus-payment and payment-versus-payment settlement built on zero-knowledge proofs1. On reach, it describes native interoperability with the public Hedera network through CLPR, a protocol that avoids a conventional bridge1. ColdAI's own CLPRouter builds on CLPR and has not yet reached mainnet2, so we treat cross-network flows as something to test with the provider, not something to assume.
Our working rule is simple. Anything the business case depends on, such as a privacy feature, a node location or a service level, is confirmed in writing with the provider before the design relies on it. Admission controls, including the KYC-gated participation described on this page, are agreed with the provider and the founding members rather than taken as a default.
Suitability test for a permissioned Hedera network
Work through these before comparing products. A workload that fails most of them is usually better served by public mainnet, a conventional shared database or no ledger at all; the distributed ledger hub covers that wider question.
Participant architecture, from governance down to the nodes
Each institution joins with its own applications and key custody, while the shared layers are governed together. Decisions at the top constrain every layer below them.
- Governance and membership
Admission rules, voting, cost sharing, change approval and exit terms agreed by the founding members.
- Participant applications
Each member's payment, treasury or registry systems that create and read transactions through the network interface.
- Signing and key custody
Hardware security modules or custodians under each member's control, so no shared party can sign on a member's behalf.
- Identity and admission
Onboarding checks and account permissions that decide who may hold which assets and submit which transactions.
- Consensus nodes
Nodes run by the provider or by members, in the locations and clouds the governance agreement permits.
- Mainnet interoperability
Selected flows or proofs that cross to public Hedera under rules agreed in advance.
Three ways a founding group can run the network
Governance is the decision founding members most often postpone and most often regret postponing. These are the main operating models; hybrids are common.
| Question | One institution operates | Members operate jointly | Provider-managed service |
|---|---|---|---|
| Who admits new members | The operating institution, under published criteria | A membership committee with agreed voting thresholds | The members decide; the provider carries out onboarding under contract |
| Who runs consensus nodes | The operator, possibly in its own data centres | Each member, or an agreed subset of members | The provider, in locations fixed by the service agreement |
| Main strength | Fast decisions and one accountable party | No member depends on a competitor's infrastructure | The lightest operational load for members |
| Main weakness | Other members depend on a supplier or competitor | Slow change and uneven operational maturity across members | Concentration on one supplier, so exit terms carry more weight |
| Typical fit (hypothetical) | A bank running a network for its corporate clients | Peer banks settling obligations with each other | A public body, or a consortium with no natural operator |
| Settle in writing first | Neutrality commitments and limits on the operator's data access | Cost sharing, upgrade cadence and what happens when a member leaves | Service levels, data location, incident reporting and exit assistance |
A provider-managed network in which some members also run nodes is a frequent compromise. Confirm which operating models the provider supports in your jurisdiction before choosing.
How we take a HashSphere programme from question to live network
The sequence below covers the services on this page: suitability assessment, tenant and participant design, settlement-asset issuance where it is in scope, mainnet connectivity and ongoing operations.
Test the case against public mainnet
Compare what the workload needs with what public Hedera already offers, using the placement framework. Many candidates stop here, and that is a useful result.
Agree the founding terms
Facilitate the governance decisions: membership, operating model, cost sharing and exit. They become the brief for the conversation with the provider.
Confirm the service with the provider
Check node locations, confidentiality features, service levels and interoperability options against the requirements, and record every assumption the design rests on.
Design each participant's connection
Specify accounts, signing, admission checks and reconciliation for every member, fitted to its internal controls, and decide which data stays off the ledger; the confidentiality model guides that choice.
Build, onboard and rehearse
Integrate member systems, issue any settlement asset with Stablecoin Studio where it is in scope, onboard counterparties and rehearse failures such as a node outage or a compromised member key.
Operate or hand over
Run monitoring, on-call, change management and reporting against the agreed service levels, or hand the environment to the members' own teams with runbooks.
Regulated buyers: outsourcing rules travel with the network
Frequently asked questions
Is ColdAI the provider of HashSphere?
No. HashSphere is offered by Hashgraph. ColdAI is a delivery partner: we assess suitability, design the participant and governance architecture, integrate members' systems and can operate the environment under a retained engagement. Commercial terms for the network itself, its service levels and feature availability are agreed with the provider, and we confirm them with the provider before any design depends on them.
Can a single institution run a HashSphere network on its own?
The provider describes managed and self-hosted options and lets institutions choose their validator model, so a single operator is possible in principle. The real question is whether other participants will accept depending on that operator. Clients of the operator often do; competitors often do not, and a jointly governed or provider-managed model meets less resistance. Confirm the supported operating models with the provider.
What do you need from us to assess HashSphere suitability?
A description of the workload and the institutions that would take part, the regulatory requirements each participant works under, such as residency, outsourcing and data protection, and the systems that would connect. With that we compare the workload against public Hedera, run the suitability test on this page and list the open questions for the provider. The written recommendation may be not to build a permissioned network.
Can a HashSphere network carry stablecoins or tokenised deposits?
This page describes customer-controlled stablecoin issuance, and the provider lists Stablecoin Studio among the tools available to HashSphere users. Whether to issue a stablecoin or tokenise deposits is a separate legal and balance-sheet decision, covered in tokenised deposits compared with stablecoins. The network supplies the ledger; licences, reserves and redemption remain the issuer's responsibility.
What happens when a member wants to leave the network?
That should be decided before anyone joins. Founding terms should say how a leaving member's assets are redeemed or moved, whether it keeps the ledger history it was entitled to see, how its nodes and keys are decommissioned and who absorbs its share of costs. Departure is also when the confidentiality design is tested, because a former member may retain data it could read while it was a participant.
Can applications built for public Hedera run on HashSphere?
The provider describes HashSphere as EVM-compatible, with support for Solidity and standard EVM tooling, so contract code is often portable. Integration details still differ: network endpoints, account creation and admission, fee arrangements, mirror and reporting services, and any confidentiality features that public mainnet lacks. Plan a porting review instead of assuming that redeploying the contracts is enough.
Sources
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- An identified group of participants
- Provider and deployment requirements
- A shared governance decision process