> ## Documentation Index
> Fetch the complete documentation index at: https://cantonfoundation-landing-margin.mintlify.site/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

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](/overview/learn/privacy-model).

## 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.

```mermaid theme={null}
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

| 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                                    |

```mermaid theme={null}
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:

| 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:

```mermaid theme={null}
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

<CardGroup cols={2}>
  <Card title="Use Cases" icon="building" href="/overview/understand/use-cases">
    See concrete examples of Canton in action.
  </Card>

  <Card title="Core Concepts" icon="book" href="/overview/understand/core-concepts">
    Learn about parties, validators, and synchronizers.
  </Card>

  <Card title="Architecture Deep Dive" icon="diagram-project" href="/overview/learn/architecture">
    Understand how components work together technically.
  </Card>

  <Card title="Privacy Model" icon="lock" href="/overview/learn/privacy-model">
    Explore the privacy guarantees in detail.
  </Card>
</CardGroup>