Canton's Solution: Three Pillars

How Canton achieves privacy without sacrificing integrity

Canton resolves the privacy-integrity tradeoff through three architectural pillars that work together to provide both strong privacy guarantees and blockchain-grade integrity.

Pillar 1: Sub-Transaction Privacy

Canton’s core innovation is sub-transaction privacy. This works at two levels:

1. Transaction isolation: Different transactions are kept completely separate—unrelated parties don’t even know other transactions exist
2. View decomposition: Within a single transaction, different parties see only their relevant portions

When a transaction involves multiple parties, Canton splits it into views based on stakeholder relationships, encrypts each view for its recipients, and has the synchronizer deliver only the views each participant is entitled to. Each participant validates and confirms based on their own view — the synchronizer never sees unencrypted transaction content.

This isn’t just hiding data—it’s providing mathematically enforced boundaries on information flow. For a detailed walkthrough of how views are decomposed, what each party sees in a concrete example, and privacy design patterns for Daml applications, see Privacy Model Explained.

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

Then the transaction is valid. Charlie’s validator doesn’t need to see it, verify it, or even know it exists.

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

This separation of concerns means:

• 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

Together, they create a system where:

1. Each party receives only their view
2. Each party validates only their view
3. The synchronizer never sees any views
4. 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.