Canton’s Solution: Three Pillars

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.

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

How Views Work

When a transaction involves multiple parties, Canton doesn’t send the entire transaction to everyone. Instead:

1. Decomposition: The transaction is split into views based on stakeholder relationships
2. Encryption: Each view is encrypted for its specific recipients
3. Distribution: The synchronizer delivers only entitled views to each participant
4. Validation: Each participant validates their view independently
5. Confirmation: Participants confirm based on their view alone

flowchart LR
    subgraph TX[Transaction]
        direction TB
        A1[Alice → Bob]
        A2[Bob → Charlie]
    end

    TX --> DECOMP[Decompose]

    DECOMP --> VA[Alice's View<br>Sees: Alice → Bob]
    DECOMP --> VB[Bob's View<br>Sees: Both]
    DECOMP --> VC[Charlie's View<br>Sees: Bob → Charlie]

In this example, a single atomic transaction moves value from Alice to Bob to Charlie. But Alice never learns about Charlie, and Charlie never learns about Alice.

What Each Party Sees

This isn’t just hiding data—it’s providing mathematically enforced boundaries on information flow.

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.

sequenceDiagram
    participant Alice as Alice's Validator
    participant Sync as Synchronizer
    participant Bob as Bob's Validator

    Alice->>Sync: Submit encrypted transaction
    Sync->>Sync: Order and timestamp
    Sync->>Alice: Deliver Alice's view
    Sync->>Bob: Deliver Bob's view
    Alice->>Sync: Confirmation
    Bob->>Sync: Confirmation
    Sync->>Alice: Commit
    Sync->>Bob: Commit

    Note over Alice,Bob: Only involved parties<br/>participate in consensus

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

What the Synchronizer Cannot Do

flowchart TB
    subgraph Participants
        PA[Participant A<br>Stores contracts for parties A hosts]
        PB[Participant B<br>Stores contracts for parties B hosts]
    end

    subgraph Synchronizer
        SEQ[Sequencer<br>Orders encrypted messages]
        MED[Mediator<br>Collects confirmations]
    end

    PA <--> SEQ
    PB <--> SEQ
    SEQ <--> MED

    Note1[Synchronizer sees:<br>- Encrypted blobs<br>- Timestamps<br>- Confirmation results]
    Note2[Participants store:<br>- Decrypted contract data<br>- Only for their parties]

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:

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:

flowchart LR
    Bank[Bank] --> |sees loan terms| Workflow
    Borrower[Borrower] --> |sees their obligations| Workflow
    Auditor[Auditor] --> |sees compliance data| Workflow

    Workflow[Loan Agreement]

    Note[Each party sees different<br/>aspects of the same contract]

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

Mirrored from Canton Network official documentation (CC-BY-4.0) by CC Privacy Club for learning purposes.