Canton resolves the privacy-integrity tradeoff through three architectural pillars that work together to provide both strong privacy guarantees and blockchain-grade integrity.Documentation Index
Fetch the complete documentation index at: https://docs.canton.network/llms.txt
Use this file to discover all available pages before exploring further.
Pillar 1: Sub-Transaction Privacy
Canton’s core innovation is sub-transaction privacy. This works at two levels:- Transaction isolation: Different transactions are kept completely separate—unrelated parties don’t even know other transactions exist
- View decomposition: Within a single transaction, different parties see only their relevant portions
How Views Work
When a transaction involves multiple parties, Canton doesn’t send the entire transaction to everyone. Instead:- Decomposition: The transaction is split into views based on stakeholder relationships
- Encryption: Each view is encrypted for its specific recipients
- Distribution: The synchronizer delivers only entitled views to each participant
- Validation: Each participant validates their view independently
- Confirmation: Participants confirm based on their view alone
What Each Party Sees
| Party | Sees | Doesn’t See |
|---|---|---|
| Alice | Her payment to Bob | Bob’s payment to Charlie; Charlie’s identity |
| Bob | Both payments (involved in both) | Nothing hidden |
| Charlie | His receipt from Bob | Alice’s involvement; original source |
| Synchronizer | Encrypted messages only | Any transaction content |
Pillar 2: Proof of Stakeholder Consensus
Traditional blockchains require all validators to verify all transactions. Canton uses a different approach: only the stakeholders in a transaction need to confirm it.Why This Works
Consider: why does a validator need to verify a transaction they’re not part of? In traditional blockchains, validators verify everything to prevent double-spends and ensure rules are followed. But if only Alice and Bob are affected by a transaction, only Alice and Bob need to verify it. As long as:- Alice’s validator confirms Alice authorized the transaction
- Bob’s validator confirms Bob is receiving what he’s supposed to
- Both agree the transaction is valid
Integrity Without Global Visibility
This approach maintains integrity because:- Double-spend prevention: Alice’s validator tracks Alice’s contracts; can’t spend what doesn’t exist; and in the example case of reputable tokens, the issuer’s approval is required for issuance.
- Authorization enforcement: Only parties declared as controllers can exercise choices
- Consistency: The synchronizer ensures all parties see a consistent order of events
- Atomicity: Either all involved parties confirm, or the transaction is rejected
Pillar 3: Synchronization Without Visibility
The synchronizer (sequencer + mediator nodes) synchronizes transaction ordering and confirmation without seeing transaction content.What the Synchronizer Does
| Function | Description |
|---|---|
| Ordering | Assigns timestamps and total order to transactions and events |
| Distribution | Routes encrypted views to entitled participants |
| Mediation | Collects confirmations and declares outcomes |
| Consistency | Ensures all participants see the same ordering |
What the Synchronizer Cannot Do
| Limitation | Guarantee |
|---|---|
| Read content | Only sees encrypted views |
| Identify end users | Knows parties for routing, but not the humans/systems behind them |
| Modify transactions | Can only pass through or reject |
| Store state | No persistent transaction data |
The Trust Model
The synchronizer’s limited capability is a feature, not a limitation:- You don’t need to trust the synchronizer with your data—it can’t read it
- You do trust the synchronizer for ordering and availability
- The synchronizer can’t cheat because it can’t see what it’s synchronizing
- Privacy is enforced cryptographically, not by policy
- Synchronizer operators cannot extract transaction intelligence
- Adding more synchronizer operators doesn’t expand data exposure
How the Pillars Work Together
The three pillars are interdependent:| Pillar | Enables |
|---|---|
| Sub-transaction privacy | Views that can be validated independently |
| Proof of stakeholder | Consensus without global visibility |
| Synchronization without visibility | Ordering without data exposure |
- Each party receives only their view
- Each party validates only their view
- The synchronizer never sees any views
- The transaction commits atomically if all stakeholders confirm
Real-World Impact
This architecture enables use cases not feasible on traditional blockchains:Confidential Multi-Party Workflows
Multiple organizations can share a workflow where each sees only their part:Privacy-Preserving Settlement
Trading parties settle without observers seeing prices:- Buyer sees: asset received, payment made
- Seller sees: asset transferred, payment received
- Market: cannot see price or parties
Regulatory Compliance
Meet data protection requirements while maintaining shared truth:- Data stays with entitled parties
- Audit trails exist for those with audit rights
- Cross-border data flows are minimized
Next Steps
Use Cases
See concrete examples of Canton in action.
Core Concepts
Learn about parties, validators, and synchronizers.
Architecture Deep Dive
Understand how components work together technically.
Privacy Model
Explore the privacy guarantees in detail.