> ## Documentation Index
> Fetch the complete documentation index at: https://cantonfoundation-generated-references-canton-protobuf-histo.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Core Concepts

> Essential building blocks of Canton Network: parties, validators, synchronizers, and smart contracts

Understanding Canton requires grasping four fundamental concepts: **parties**, **validator** node, **synchronizers**, and **templates** (smart contracts). This page introduces each and explains how they work together.

## Parties

A **party** is an on-ledger identity in Canton—analogous to an address or account on other blockchains, but with explicit authorization semantics.

### Party Identifier Format

```
alice::1220f2fe29866fd6a0009ecc8a64ccdc09f1958bd0f801166baaee469d1251b2eb72
└┬┘  └─────────────────────────────────────────┘
name                                fingerprint (hash of public key)
```

### What Parties Do

| Capability | Description |
| - | - |
| **Sign** | Authorize contract creation (as signatory) |
| **Act** | Execute choices on contracts (as controller) |
| **See** | Observe contracts and transactions (as stakeholder) |
| **Validate** | Confirm transactions affecting their contracts |

### Local vs. External Parties

| Type | Keys Held By | Use Case |
| - | - | - |
| **Local Party** | Validator | Simpler; validator signs on party's behalf. Good for automation. |
| **External Party** | External system | User wallets; requires explicit signing workflow |

<Note>
  Unlike Ethereum addresses, parties create state on validators and have costs associated with creation. Design your party structure deliberately—don't create parties unnecessarily.
</Note>

### Party Roles in Contracts

Parties interact with contracts in three roles:

```haskell theme={"theme":{"light":"github-light","dark":"github-dark"}}
template Asset
  with
    issuer : Party   -- Will be signatory
    owner : Party    -- Will be observer and controller
    auditor : Party  -- Will be observer
  where
    signatory issuer        -- Must authorize creation; always sees contract
    observer owner, auditor -- Can see contract

    choice ChangeOwner : ContractId Asset
      with newOwner : Party
      controller owner      -- Only owner can exercise this choice
      do create this with owner = newOwner
```

| Role | Can Create | Can See | Can Act |
| - | - | - | - |
| **Signatory** | Must authorize | Always | If also controller |
| **Observer** | No | Yes | If also controller |
| **Controller** | No | When exercising | Yes (specific choice) |

<Note>
  **Stakeholder** = signatories + observers. Stakeholders are all parties who can see a contract. Validators store contracts for their hosted parties when those parties are stakeholders.
</Note>

## Validators (Participant Nodes)

A **validator** hosts parties, stores their contract data, and participates in the Canton protocol. A validator contains a participant node (the Daml execution engine) plus a validator process.

### What Validators Do

| Function | Description |
| - | - |
| **Host parties** | Store contracts for their hosted parties |
| **Execute Daml** | Run smart contract logic |
| **Validate transactions** | Verify authorization and correctness |
| **Expose APIs** | Provide Ledger API for applications |

### Validator Architecture

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart TB
    subgraph Validator[Validator Node]
        PART[Participant<br>Daml execution engine]
        DB[(Ledger Store<br>Party contracts)]
        API[Ledger API<br>gRPC / JSON]
    end

    App[Your Application] --> API
    API --> PART
    PART --> DB
    PART <--> SYNC[Synchronizer]
```

### Key Characteristics

* Each validator maintains a **localized, private view** of the ledger (called the *Active Contract Set*)
* Validators only store contracts where their hosted parties are stakeholders
* Multiple parties can be hosted on a single validator
* Validators can connect to multiple synchronizers
* A party can be hosted on multiple validators

<Warning>
  Your hosting validator sees all your data. Choose your validator carefully—this is a trust relationship.
</Warning>

## Synchronizers

A **synchronizer** coordinates transaction ordering and consensus without seeing transaction content. It consists of two components:

### Sequencer

The sequencer orders and distributes messages:

| Function | Description |
| - | - |
| **Order** | Assign timestamps and total ordering |
| **Distribute** | Route encrypted messages to recipients |
| **Consistency** | Ensure all participants see same order |

The sequencer **does not**:

* Decrypt messages
* See transaction content
* Permanently store transaction data (though it may cache it)
* Know which end users are involved (though it routes based on party information)

### Mediator

The mediator facilitates the consensus protocol that confirms the transaction:

| Function | Description |
| - | - |
| **Collect** | Gather confirmations from participants |
| **Aggregate** | Determine if consensus threshold is met |
| **Declare** | Announce transaction outcome (commit/reject) |

The mediator **does not**:

* See transaction content
* Know what's being confirmed
* Store confirmation details

### The Global Synchronizer

The **Global Synchronizer** is the public synchronizer for Canton Network:

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart TB
    subgraph GS[Global Synchronizer]
        subgraph SVs[Super Validators]
            SV1[SV 1]
            SV2[SV 2]
            SV3[SV N]
        end
        SEQ[Distributed Sequencer]
        MED[Distributed Mediator]
    end

    V1[Validator A] <--> SEQ
    V2[Validator B] <--> SEQ
    V3[Validator C] <--> SEQ
    SEQ <--> MED
```

* Operated by **Super Validators** (major institutions)
* Decentralized—no single operator controls it
* Uses **Canton Coin (CC)** to purchase traffic to pay transaction fees
* Governed by the **Canton Foundation**

## Smart Contracts (Templates)

Smart contracts in Canton are defined using **Daml**, a purpose-built language for multi-party workflows. A Daml **template** typically defines:

* **Data**: What information the contract holds
* **Parties**: Who can see and act on the contract
* **Choices**: What actions are possible

### Template Structure

```haskell theme={"theme":{"light":"github-light","dark":"github-dark"}}
template Token
  with
    -- Data fields
    owner : Party
    issuer : Party
    amount : Decimal
  where
    -- Authorization
    signatory issuer
    observer owner

    -- Actions
    choice ChangeOwner : ContractId Token
      with
        newOwner : Party
      controller owner
      do
        create this with owner = newOwner
```

### Contracts Are Immutable

Unlike Solidity contracts with mutable state, Daml contracts (template instances) are immutable. They can only be `created` or `archived`.

| Solidity | Daml |
| - | - |
| Modify state in place | Archive old contract, create new one |
| `balances[addr] = newValue` | `create Token with owner = newOwner` |
| State history implicit | State history explicit via contracts |

This immutability is key to Canton's privacy and integrity guarantees.

### Choices: Consuming vs. Non-Consuming

| Type | Effect | Use Case |
| - | - | - |
| **Consuming** | Archives the contract | State transitions, transfers |
| **Non-consuming** | Contract remains active | Queries, read operations, events for listening clients |

```haskell theme={"theme":{"light":"github-light","dark":"github-dark"}}
-- Consuming: archives the contract
choice ChangeOwner : ContractId Token
  controller owner
  do create this with owner = newOwner

-- Non-consuming: contract stays active
nonconsuming choice GetBalance : Decimal
  controller owner
  do return amount
```

## How Components Work Together

A complete transaction flow involves all four concepts:

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
sequenceDiagram
    participant App as Application
    participant VA as Validator A<br>(hosts Alice)
    participant Sync as Synchronizer
    participant VB as Validator B<br>(hosts Bob)

    Note over App,VB: 1. Alice transfers token to Bob

    App->>VA: Submit command
    VA->>VA: Execute Daml, create views
    VA->>Sync: Submit encrypted transaction
    Sync->>Sync: Order, timestamp
    Sync->>VA: Deliver Alice's view
    Sync->>VB: Deliver Bob's view
    VA->>Sync: Confirmation
    VB->>Sync: Confirmation
    Sync->>VA: Commit
    Sync->>VB: Commit
```

| Step | Component | Action |
| - | - | - |
| 1 | **Application** | Submits command via Ledger API |
| 2 | **Validator A** | Executes Daml, creates transaction views |
| 3 | **Synchronizer** | Orders, distributes encrypted views |
| 4 | **Validators** | Validate their respective views |
| 5 | **Synchronizer** | Collects confirmations, declares commit |
| 6 | **Validators** | Store committed contracts |

## Summary Table

| Concept | What It Is | Key Property |
| - | - | - |
| **Party** | On-ledger identity | Has explicit authorization roles |
| **Validator** | Node hosting parties | Stores only hosted parties' data |
| **Synchronizer** | Coordination layer | Orders without seeing content |
| **Template** | Smart contract definition | Defines data, parties, and choices |
| **Contract** | Template instance | Immutable; changes create new contracts |

## Next Steps

<CardGroup cols={2}>
  <Card title="Architecture Deep Dive" icon="diagram-project" href="/overview/learn/architecture">
    See how components work together technically.
  </Card>

  <Card title="Global Synchronizer" icon="globe" href="/overview/understand/global-synchronizer">
    Learn about the public coordination layer.
  </Card>

  <Card title="Privacy Model" icon="lock" href="/overview/learn/privacy-model">
    Understand sub-transaction privacy in detail.
  </Card>

  <Card title="Start Building" icon="code" href="/appdev/get-started/choose-your-path">
    Begin developing on Canton.
  </Card>
</CardGroup>