ArchitectureHashSphere
Who sees what on a permissioned ledger: a confidentiality model for HashSphere
Permissioned does not mean private. On a Hedera-powered permissioned network, what other members, node operators, the provider and public mainnet observers can see depends on decisions at several layers: admission, operations, participant visibility, payload design, key custody and interoperability. This page walks through each layer, shows where personal-data rules bite and lists the leaks to test for before a risk committee signs off.
On this page
- The question a risk committee asks before any other
- Map of the parties around a permissioned ledger
- Admission and operators: the first two layers
- Visibility by data element and audience
- Choosing how sensitive data appears on the ledger
- Keys decide who can actually read, and interoperability adds an audience
- Personal data on a ledger that cannot forget
- Where confidentiality designs leak
- Questions and answers
- Sources
The question a risk committee asks before any other
When a bank or public body considers a shared ledger, the first objection is rarely about throughput. It is: who else will see our transactions? The honest answer is that it depends on choices at several layers, and permissioning settles only the first of them.
The model below treats confidentiality as a stack, where each layer has its own audience and its own control. HashSphere-specific capabilities are taken from the provider's published description, which mentions on-chain transaction confidentiality, private transfers and zero-knowledge proofs for delivery-versus-payment and payment-versus-payment settlement1. Confirm their scope for your deployment with the provider before a design relies on them.
Map of the parties around a permissioned ledger
The ledger sits at the centre, and every other party sees a different slice of it.
- Permissioned ledger
Shared transaction history replicated across the consensus nodes.
- Participant institutions
See their own transactions plus whatever the visibility rules expose about others.
- Node operators, provider
Run the infrastructure and can observe any data that reaches the nodes unencrypted.
- Off-ledger data store
Holds documents and personal data, while the ledger keeps only salted digests or pointers.
- Key custody
HSMs or custodians whose keys decide who can decrypt each payload.
- Public mainnet anchor
Receives digests or selected transfers, never raw data, when interoperability is used.
- Supervisor or auditor
Gets scoped read access through extracts or view keys rather than a node of its own.
Admission and operators: the first two layers
Admission. Vetting who may hold an account and submit transactions, which the hub describes as KYC-gated participation, keeps unknown parties out. It does not limit what admitted members learn about each other, and it does not stop a vetted member misusing what it sees. Treat admission as a precondition for the other layers, not as a confidentiality control in its own right.
Operators. Consensus nodes must process transactions in order to order them. Unless a payload is encrypted or replaced by a proof before submission, assume the node operators and the provider can read it. The provider says node operation can be restricted to a specific country or cloud provider1, which helps with residency, but location is not the same as access. Ask who at the operator can reach node data, under what logging, and how that is evidenced to members.
Visibility by data element and audience
A starting assumption for design reviews. Replace each cell with what the provider confirms and what your design enforces.
| Data element | Counterparties | Other members | Node operators and provider | Public mainnet observers |
|---|---|---|---|---|
| That a transaction occurred | Yes | Assume yes, including timing and frequency, unless the rules hide it | Yes | Only if a digest or transfer is published |
| Amounts and balances | Yes | Hidden only if confidential transfers are used; confirm availability | Readable unless confidential transfers or encryption apply | Only if an asset moves to mainnet |
| Account identities | Yes, through onboarding records | Account identifiers at least; legal names depend on the directory design | Account identifiers; legal names only if the operator also runs onboarding | No |
| Payload content | Yes, if they hold the key | No, if encrypted to the counterparties only | No, if encrypted before submission | No |
| Off-ledger documents | Through the store's own access controls | No, unless granted | No, unless they also host the store | No |
Metadata such as timing, frequency and size can reveal business relationships even when content is hidden. Test what a curious member could infer, not only what it can read.
Choosing how sensitive data appears on the ledger
- If
Counterparties need to prove later that a document existed unchanged.
ThenStore the document off-ledger and write a salted or keyed digest to the ledger.
The digest proves integrity, and deleting the salt or key later breaks the link to the person or document.
- If
Only the two parties to a transaction should read its terms.
ThenEncrypt the payload to their keys before submission.
Nodes and other members then see ciphertext, although encrypted personal data is still personal data2.
- If
A value must be checked without being revealed, such as a sufficient balance at settlement.
ThenUse the network's confidential-transfer or zero-knowledge features, if the provider confirms them for your use.
Proof-based designs hide amounts from everyone but the parties, but depend on provider tooling and specialist review.
- If
The data is personal and serves no settlement or integrity purpose on the ledger.
ThenKeep it out of the ledger entirely.
Data that was never written creates no erasure problem.
Keys decide who can actually read, and interoperability adds an audience
Encryption moves the access question to key custody. If each member holds its own keys in a hardware security module or with a custodian, only that member and its chosen counterparties can decrypt its payloads. If a shared service holds keys for convenience, that service becomes the real gatekeeper and belongs in your threat model and contracts. Plan rotation, revocation when a member leaves and recovery when a key is lost, because each one changes who can read historic data.
When a workload anchors to public mainnet, publish digests or proofs, not data. When assets move to mainnet, expect the transfer to be visible through mirror nodes like any other mainnet transaction3. Decide flow by flow which facts become public, and record each decision for the risk committee; the placement framework helps decide which flows should cross at all.
Personal data on a ledger that cannot forget
Where confidentiality designs leak
Metadata inference
Early signalMembers can map who trades with whom from timing and volume alone.
MitigationBatch submissions, use confidential transfers where confirmed, and test inference during design reviews.
Unsalted digests
Early signalDigests of predictable values such as account numbers or names.
MitigationUse salted or keyed hashes with the secrets held off-ledger, as the EDPB guidelines recommend2.
Operator over-access
Early signalOperator staff can query node data without logging that members can see.
MitigationContract for access logging, residency and audit rights, and encrypt payloads before submission.
Departing member keeps history
Early signalA member leaves with a full copy of everything it was entitled to read.
MitigationMinimise what each member can decrypt, and cover retention and deletion in the exit terms.
Supervisor access widens every view
Early signalA regulator is offered a full node, so the design adds broad read paths.
MitigationGrant scoped extracts or per-entity view keys instead of network-wide access.
Questions and answers
Is a permissioned ledger the same as a private ledger?
No. Permissioned describes who may join and transact. Private, in the sense most people mean, describes who can see data. A permissioned network can still expose every member's transactions to every other member and to node operators. Confidentiality comes from visibility rules, encryption, confidential-transfer features and off-ledger storage layered on top of admission controls.
Can a regulator see everything on a permissioned network?
Only if the design grants that access. Supervisors normally need the activity of the entities they supervise, not the whole network. Scoped extracts, per-entity view keys or reports from each member's own systems usually meet that need without creating a single read path to everything. Agree supervisory access in the governance terms so it is not improvised during an inspection.
What happens to our data if we leave the network?
Data already replicated stays replicated: other nodes keep the ledger history, including your past transactions, to the extent the design exposed them. What you control is what was readable in the first place and what happens to keys and off-ledger stores at exit. Exit terms should cover asset redemption or transfer, deletion of off-ledger data others hold and revocation of shared keys.
Do hashes written to the ledger count as personal data?
They can. The EDPB's consultation guidelines say a salted or keyed hash of personal data is still personal data, although deleting the salt or key can make it unlinkable, and that unsalted hashes are generally insufficient on a public blockchain. Treat digests as personal data in your records of processing, and keep salts and keys off-ledger under deletion control.
Sources
- HashSphere: private networks built on Hedera technology — Hashgraph · checked 10 October 2026
- Guidelines 02/2025 on processing of personal data through blockchain technologies (version for public consultation, adopted 8 April 2025; a final version has since been published) — European Data Protection Board · checked 10 October 2026
- Mirror nodes — Hedera documentation · checked 10 October 2026
- Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex · checked 10 October 2026