Canton Network Privacy: How Sub-Transaction Privacy Actually Works
Canton's sub-transaction privacy is the architectural innovation that lets Goldman Sachs and JPMorgan settle assets on the same network without seeing each other's transactions. Here is how it works at the protocol level.
Privacy is the single most important feature separating the Canton Network from every other blockchain. Without sub-transaction privacy, Goldman Sachs would never share infrastructure with JPMorgan. DTCC would never settle tokenized securities on a network where competitors can see trade details. Banks would never move beyond private, siloed ledgers.
Canton solves this with sub-transaction privacy — a protocol-level privacy model that ensures each participant sees only the portions of a transaction relevant to them. This is not privacy added via encryption or zero-knowledge proofs. It is privacy built into the architecture itself.
The Problem: Why Other Blockchains Fail on Privacy
Public blockchains (Ethereum, Solana, Bitcoin) are transparent by default. Every node sees every transaction. For institutional finance, this is unacceptable — banks cannot expose proprietary trading strategies, client positions, or deal terms to competitors.
Private/permissioned blockchains (Hyperledger Fabric, R3 Corda) solve privacy by creating siloed networks. But silos destroy the core value proposition of blockchain: shared infrastructure and atomic composability. You cannot atomically settle a cross-institution trade on a chain where each institution has its own isolated ledger.
Canton threads the needle: shared infrastructure with selective privacy.
How Sub-Transaction Privacy Works
1. Daml Contracts Define Visibility
Every contract on Canton is a Daml template that explicitly names its parties: signatories (who authorized the contract), observers (who can see it), and controllers (who can exercise choices on it). A party not named on a contract cannot see it exists. This is not a bug — it is the core design.
2. Transactions Are Decomposed into Views
When a transaction is submitted to Canton, it is decomposed into views— each view contains only the information relevant to a specific party or set of parties. Party A sees View A. Party B sees View B. Neither sees the other's view. The transaction is atomic (it either fully succeeds or fully fails), but each party's visibility is limited to their authorized portion.
3. Mediators Validate Without Seeing
Mediators are the entities responsible for confirming that a transaction is valid — that all necessary parties have authorized it and that there are no conflicts. Critically, mediators do this without seeing the transaction contents. They work with cryptographic commitments and confirmations, not raw data.
This means even the network infrastructure operators do not have access to the transaction data passing through them. The mediator knows a transaction occurred and that it was valid. It does not know what the transaction was about.
4. Cross-Domain Privacy Boundaries
Canton's synchronization domains create additional privacy boundaries. A transaction on DTCC's domain is invisible to participants on a separate domain unless they are named parties to a cross-domain transaction. Even cross-domain atomic transactions preserve per-party visibility — each participant sees only their relevant views.
Canton Privacy vs. Other Approaches
| Approach | How It Works | Limitation |
|---|---|---|
| Canton (sub-txn) | Parties only receive their views | Requires Daml for contracts |
| ZK proofs (Zcash, Aztec) | Proves validity without data | Computationally expensive |
| Private channels (Fabric) | Separate ledgers per channel | No cross-channel atomicity |
| Encryption (general) | Data encrypted at rest/transit | Key management complexity |
| Mixers/tumblers | Obfuscates transaction trail | Regulatory non-compliant |
Selective Disclosure: Privacy with Regulatory Access
Canton's privacy model supports selective disclosure. Regulators, auditors, or compliance officers can be designated as observers on specific contracts, giving them visibility without exposing data to market competitors. This is the key difference between Canton privacy and privacy coins: Canton hides data from competitors, not from regulators.
This design aligns with regulatory frameworks like MiCA, which require both data protection and regulatory visibility. For more on Canton's regulatory compliance approach, see our MiCA whitepaper summary.
Why This Matters
Sub-transaction privacy is not a nice-to-have feature. It is the reason Canton exists. Without it, the entire value proposition of a shared institutional blockchain collapses. Banks would never share infrastructure if doing so meant exposing proprietary data to competitors.
Canton's privacy model enables a new category of financial infrastructure: shared but private. Multiple competing institutions can transact on the same network, benefit from shared liquidity and atomic composability, and maintain complete confidentiality of their proprietary data.
For the full technical specification, see our Canton Blockchain Protocol whitepaper summary. For practical implications, explore how privacy enables institutional tokenization and private DeFi on Canton.