Canton Global Synchronizer: Architecture and Implications

Overview

The Global Synchronizer is a fundamental component of the Canton Network architecture that ensures ordering, consensus, and privacy across all participants in a synchronization domain. Understanding its role and implications is critical for institutional deployments of Canton-based systems like CantonDefi.

What is the Global Synchronizer?

Core Concept

The Global Synchronizer (also called a Domain) is Canton's consensus and ordering service that:

Orders all transactions within a synchronization domain
Enforces sequencing of contract operations across participants
Coordinates the two-phase commit protocol for atomic transactions
Maintains privacy by only seeing encrypted transaction data
Provides finality guarantees for committed transactions

┌─────────────────────────────────────────────────────┐
│          Canton Synchronization Domain               │
│                                                       │
│  ┌──────────────┐    ┌──────────────┐               │
│  │ Participant  │    │ Participant  │               │
│  │   Node A     │    │   Node B     │               │
│  │  (Vault A)   │    │  (Vault B)   │               │
│  └──────┬───────┘    └──────┬───────┘               │
│         │                   │                        │
│         │  Encrypted Txs    │                        │
│         └─────────┬─────────┘                        │
│                   │                                  │
│         ┌─────────▼──────────┐                       │
│         │ Global Synchronizer│                       │
│         │                    │                       │
│         │ • Ordering         │                       │
│         │ • Sequencing       │                       │
│         │ • 2PC Coordination │                       │
│         │ • Privacy-Preserving│                      │
│         └────────────────────┘                       │
└─────────────────────────────────────────────────────┘

Key Characteristics

Privacy-Preserving:

The synchronizer never sees the plaintext content of Daml contracts
Only sees encrypted transaction envelopes and metadata
Cannot read strategy details, allocations, or sensitive vault data

Trust Model:

Participants trust the synchronizer for:
- Ordering: Transactions are sequenced fairly
- Liveness: The system remains available
- Non-equivocation: The synchronizer provides a single consistent view
Participants DO NOT trust the synchronizer for:
- Confidentiality: Data is encrypted end-to-end
- Authorization: Enforced by Daml runtime on participant nodes

Byzantine Fault Tolerance:

Canton supports multiple synchronizer implementations:
- Simple ordering service: Single-node (dev/testing)
- BFT consensus: Byzantine Fault Tolerant (production)
- Ethereum-based: Uses Ethereum for ordering (experimental)

Architectural Implications for CantonDefi

1. Transaction Ordering and Atomicity

The global synchronizer is what enables Canton's atomic multi-party transactions that are critical for Flow B (approval workflows) and Flow C (cross-chain coordination).

daml

-- This transaction is atomic because the synchronizer coordinates all participants
choice ApproveProposal : ContractId ExecutionIntent
  with approver : Party
  controller approver
  do
    -- All of these happen atomically:
    -- 1. Fetch proposal
    proposal <- fetch proposalCid

    -- 2. Verify quorum (may involve multiple parties)
    let updatedApprovers = approver :: proposal.approvers
    assertMsg "Quorum not met" (length updatedApprovers >= proposal.quorumRequired)

    -- 3. Archive old proposal
    archive proposalCid

    -- 4. Create ExecutionIntent
    create ExecutionIntent with ...

Implication: The synchronizer guarantees that either ALL of these operations succeed atomically, or NONE of them do. This is enforced by the two-phase commit protocol.

2. Two-Phase Commit Protocol

Canton uses a sophisticated 2PC protocol coordinated by the global synchronizer:

Phase 1: PREPARE
┌─────────────┐         ┌─────────────┐
│ Participant │         │ Participant │
│     A       │         │     B       │
└──────┬──────┘         └──────┬──────┘
       │                       │
       │  Encrypted Request    │
       └──────────┬────────────┘
                  │
         ┌────────▼────────┐
         │  Synchronizer   │
         │  • Assign seq # │
         │  • Broadcast    │
         └────────┬────────┘
                  │
       ┌──────────┴────────────┐
       │                       │
       ▼                       ▼
  [Validate]              [Validate]
  [Prepare]               [Prepare]
       │                       │
       └──────────┬────────────┘
                  │
         ┌────────▼────────┐
         │  Synchronizer   │
         │  Collect votes  │
         └────────┬────────┘

Phase 2: COMMIT
         ┌────────▼────────┐
         │  Synchronizer   │
         │  Broadcast      │
         │  commit/abort   │
         └────────┬────────┘
       ┌──────────┴────────────┐
       │                       │
       ▼                       ▼
   [Commit]                [Commit]
   [Apply]                 [Apply]

Implication for CantonDefi:

When creating an ExecutionIntent after approval quorum is met, the synchronizer ensures all approvers see the exact same final state
If ANY participant rejects (e.g., due to policy violation), the ENTIRE transaction is aborted
This prevents scenarios where:
- Intent is created but approvals are lost
- Partial approvals are recorded
- Nonce conflicts occur

3. Sequence Numbers and Ordering

The synchronizer assigns monotonically increasing sequence numbers to all transactions:

typescript

Transaction 1: seq=1000 → Create VaultPolicy
Transaction 2: seq=1001 → Create RebalanceProposal
Transaction 3: seq=1002 → Approve (1 of 3)
Transaction 4: seq=1003 → Approve (2 of 3)
Transaction 5: seq=1004 → Approve (3 of 3) → Create ExecutionIntent

Implication: This strict ordering enables:

Deterministic replay for audit purposes
Consistent nonce management across all participants
Race condition prevention when multiple proposals are created concurrently

4. Privacy Model and the Synchronizer

The synchronizer operates on encrypted transaction trees without seeing plaintext:

Participant View (Plaintext):
┌──────────────────────────────────┐
│ RebalanceProposal                │
│   proposedAllocations:           │
│     - Aave USDC: 40%             │
│     - Uniswap ETH: 35%           │
│     - Curve 3pool: 25%           │
│   riskScore: 0.72                │
│   expectedAPY: 8.3%              │
└──────────────────────────────────┘
              │ encrypt
              ▼
Synchronizer View (Encrypted):
┌──────────────────────────────────┐
│ Transaction Envelope             │
│   submitter: hash(PartyA)        │
│   payload: 0x8a7c... [encrypted] │
│   witnesses: [PartyB, PartyC]    │
│   seq: 1002                      │
└──────────────────────────────────┘

Implication for CantonDefi:

Strategy confidentiality: The synchronizer operator (e.g., the Canton Network Foundation) cannot see your vault strategies, allocations, or risk scores
Regulatory compliance: Even though transactions flow through a shared synchronizer, data privacy is cryptographically guaranteed
Multi-tenant security: Multiple institutions can share the same synchronizer without information leakage

5. Finality and Confirmation

The synchronizer provides two levels of finality:

Local Finality:

Transaction has been sequenced by the synchronizer
Assigned a sequence number
Fast (milliseconds to seconds)

Global Finality:

All participants have committed the transaction
Irreversible (barring synchronizer compromise)
Depends on synchronizer's consensus mechanism

typescript

// Listening for finality in CantonDefi
async function waitForIntentFinality(
  intentCid: ContractId
): Promise<ExecutionIntent> {
  // Wait for local finality (fast)
  const localFinal = await canton.ledger.getContractById(intentCid);

  // Wait for global finality (may require multiple rounds)
  const globalFinal = await canton.ledger.waitForGlobalCommit(intentCid);

  return globalFinal;
}

Implication:

The Relayer should wait for global finality before submitting intents to public chains
Premature submission on local finality risks intent being aborted if global consensus fails
This adds latency (typically 1-5 seconds) but ensures correctness

6. Canton Network's Global Synchronizer

The Canton Network (production network) operates a globally shared synchronizer that connects:

Financial institutions
Regulators (as observer parties)
Service providers (like Stratos)
Technology vendors

┌─────────────────────────────────────────────────┐
│     Canton Network (Production)                  │
│                                                   │
│  ┌─────────────┐  ┌──────────────┐              │
│  │  Bank A     │  │  Regulator   │              │
│  │  Participant│  │  Observer    │              │
│  └──────┬──────┘  └──────┬───────┘              │
│         │                │                       │
│  ┌──────┴────────┐  ┌────┴────────┐             │
│  │  CantonDefi   │  │  Other App  │             │
│  │  Vault        │  │  (Trade Fin)│             │
│  └──────┬────────┘  └────┬────────┘             │
│         │                │                       │
│         └────────┬───────┘                       │
│                  │                               │
│    ┌─────────────▼──────────────┐                │
│    │ Canton Network Synchronizer│                │
│    │ • BFT consensus            │                │
│    │ • Operated by Foundation   │                │
│    │ • High availability (99.9%)│                │
│    │ • Privacy-preserving       │                │
│    └────────────────────────────┘                │
└─────────────────────────────────────────────────┘

Implication for CantonDefi:

Network effects: Your vault can potentially interact with other Canton applications (e.g., tokenization platforms, lending protocols)
Regulatory acceptance: Regulators can observe transactions they're entitled to without compromising privacy
Infrastructure cost: You pay for synchronizer usage (transaction fees) but don't operate it
Dependency risk: Your vault's liveness depends on Canton Network's availability

7. Cross-Domain Transactions

Canton supports multiple synchronization domains with cross-domain workflows:

┌─────────────────┐         ┌─────────────────┐
│   Domain A      │         │   Domain B      │
│   (US Region)   │         │   (EU Region)   │
│                 │         │                 │
│  Participant X  │         │  Participant Y  │
│  ┌──────────┐   │         │  ┌──────────┐   │
│  │ Vault US │   │         │  │ Vault EU │   │
│  └─────┬────┘   │         │  └─────┬────┘   │
│        │        │         │        │        │
│  ┌─────▼─────┐  │         │  ┌─────▼─────┐  │
│  │ Sync A    │  │         │  │ Sync B    │  │
│  └───────────┘  │         │  └───────────┘  │
└─────────────────┘         └─────────────────┘
         │                           │
         └───────────┬───────────────┘
                     │
              Cross-Domain Tx
        (Atomic across both domains)

This is what enables Flow C (atomic cross-chain coordination) in CantonDefi:

daml

-- This transaction spans MULTIPLE synchronization domains
choice ExecuteMultiChain : (ContractId ExecutionIntent, ContractId ExecutionIntent)
  controller proposer
  do
    -- Intent for US Vault (Domain A)
    intentUS <- create ExecutionIntent with
      vaultId = "vault-us-001"
      ...

    -- Intent for EU Vault (Domain B)
    intentEU <- create ExecutionIntent with
      vaultId = "vault-eu-001"
      ...

    -- Canton guarantees BOTH or NEITHER
    return (intentUS, intentEU)

Implication:

The reference to "truly global workflow composition across multiple synchronization domains" in section 3.4 refers to this capability
Canton's cross-domain protocol uses commit messages exchanged between synchronizers
Adds additional latency but provides stronger atomicity guarantees than application-level coordination

Performance and Scalability Implications

Throughput Limits

The global synchronizer has finite throughput:

Typical Production Synchronizer:

Transactions per second: 100-1,000 TPS (depends on BFT implementation)
Latency (local finality): 50-500ms
Latency (global finality): 200ms-5s

Implication for CantonDefi:

High-frequency trading strategies are not suitable
Rebalancing every minute = ~1,440 transactions per day (well within limits)
Batch approvals when possible to reduce transaction count

Scalability Through Sharding

Canton supports horizontal scaling via multiple domains:

Institution's Architecture:

Domain 1: High-frequency vaults (dedicated synchronizer)
Domain 2: Compliance & audit (shared synchronizer)
Domain 3: Cross-institutional operations (Canton Network)

Implication: Large institutions may operate private synchronizers for internal workflows, and only use the global Canton Network synchronizer for cross-institutional operations.

Operational Considerations

1. Synchronizer Availability

Risk: If the global synchronizer is unavailable, ALL participants in that domain are blocked.

Mitigations:

Canton Network operates with high-availability BFT consensus (99.9%+ uptime)
Implement circuit breakers in your relayer to handle synchronizer outages
Design Daml workflows to be timeout-tolerant

daml

-- Example: Intent with explicit timeout
template ExecutionIntent
  with
    ...
    createdAt: Time
    maxAge: RelTime
  where
    signatory issuer

    -- Intent can be archived if too old
    choice ExpireIntent : ()
      controller issuer
      do
        now <- getTime
        assertMsg "Intent not expired"
          (addRelTime createdAt maxAge < now)
        return ()

2. Synchronizer Costs

Canton Network charges per-transaction fees:

Typical Fee Structure:

Base fee: $0.01-0.10 per transaction
Storage fee: $0.001 per KB per month
Cross-domain fee: 2x base fee

Implication for CantonDefi:

A vault executing 100 rebalances/day = $1-10/day in synchronizer fees
Optimize transaction frequency vs. fee cost
Consider batching operations (e.g., approve multiple proposals in one transaction)

3. Monitoring and Observability

You should monitor the synchronizer's health:

typescript

// Example monitoring metrics
const metrics = {
  syncLatency: new Histogram({
    name: 'canton_sync_latency_ms',
    help: 'Time from submission to local finality'
  }),

  syncErrors: new Counter({
    name: 'canton_sync_errors_total',
    help: 'Failed submissions to synchronizer',
    labelNames: ['error_type']
  })
};

async function submitWithMonitoring(command: Command): Promise<void> {
  const start = Date.now();

  try {
    await canton.ledger.submit(command);
    metrics.syncLatency.observe(Date.now() - start);
  } catch (error) {
    metrics.syncErrors.inc({
      error_type: error.code
    });
    throw error;
  }
}

4. Disaster Recovery

Scenario: Global synchronizer suffers catastrophic failure.

Canton's Guarantees:

All committed transactions are durably persisted on participant nodes
Participants can export their view of the ledger
New synchronizer can be bootstrapped with state migration

Implication: Your vault's state (policies, approvals, intents) is NOT lost even if the synchronizer fails permanently. However, new transactions are blocked until a new synchronizer is operational.

Security Implications

1. Synchronizer Compromise

Threat: Malicious synchronizer operator attempts to:

Read transaction contents
Reorder transactions maliciously
Fork the ledger (equivocation)

Canton's Mitigations:

Encryption: Synchronizer cannot read plaintext (confidentiality preserved)
Participant validation: Each participant independently validates transaction logic
BFT consensus: Requires compromising >1/3 of consensus nodes
Audit logs: All participants maintain complete, signed logs

Remaining Risk:

Synchronizer can delay or censor specific transactions (liveness attack)
Synchronizer can halt entirely (denial of service)

CantonDefi Mitigations:

Implement timeout and alert mechanisms for stuck transactions
Consider multi-domain deployment for critical operations
Maintain emergency procedures for synchronizer migration

2. Transaction Reordering

Risk: Synchronizer reorders transactions to benefit certain parties (e.g., frontrunning).

Canton's Mitigations:

Fairness policies: Synchronizer must follow documented ordering rules
Transparent sequencing: Sequence numbers are visible to all participants
Post-hoc auditability: Any reordering is detectable

CantonDefi Consideration:

For price-sensitive operations, use price oracles with staleness checks
Include maximum slippage parameters in ExecutionIntents
Monitor for unusual sequencing patterns

Comparison to Other Consensus Models

Feature	Canton Global Synchronizer	Ethereum (Public)	Hyperledger Fabric
Privacy	High (encrypted transactions)	None (public)	High (channel-based)
Throughput	100-1,000 TPS	15-30 TPS	3,000+ TPS
Finality	0.2-5s (BFT)	12 minutes (probabilistic)	<1s (CFT)
Atomicity	Multi-party, cross-domain	Single-chain only	Single-channel only
Trust Model	Trust for ordering only	Trustless (PoW/PoS)	Trust consortium
Cost	Per-transaction fees	Gas fees (volatile)	Hosting costs

Why Canton for CantonDefi:

Privacy: Strategies remain confidential while on public-chain execution is transparent
Atomicity: Multi-party approvals and cross-domain workflows work seamlessly
Compliance: Regulators can be observers without compromising privacy

Summary: Key Takeaways for CantonDefi

The global synchronizer is the trust anchor for Canton-based systems:

It guarantees ordering → Enables deterministic execution and audit trails
It coordinates consensus → Enables atomic multi-party workflows (Flow B)
It preserves privacy → Strategies stay confidential on Canton
It provides finality → Relayer can safely submit to public chains
It's a dependency → Your vault's liveness depends on synchronizer availability

Design Principles:

✅ Trust the synchronizer for ordering, not for confidentiality
✅ Wait for global finality before submitting to public chains
✅ Monitor synchronizer latency and availability
✅ Design for timeout and retry on synchronizer delays
✅ Consider multi-domain architecture for large-scale deployments

Next Steps:

Read Daml Contracts to understand how contracts interact with the synchronizer
Review Relayer Design to see how the relayer waits for finality
Explore Threat Model for synchronizer-related security considerations

Canton Global Synchronizer: Architecture and Implications ​

Overview ​

What is the Global Synchronizer? ​

Core Concept ​

Key Characteristics ​

Architectural Implications for CantonDefi ​

1. Transaction Ordering and Atomicity ​

2. Two-Phase Commit Protocol ​

3. Sequence Numbers and Ordering ​

4. Privacy Model and the Synchronizer ​

5. Finality and Confirmation ​

6. Canton Network's Global Synchronizer ​

7. Cross-Domain Transactions ​

Performance and Scalability Implications ​

Throughput Limits ​

Scalability Through Sharding ​

Operational Considerations ​

1. Synchronizer Availability ​

2. Synchronizer Costs ​

3. Monitoring and Observability ​

4. Disaster Recovery ​

Security Implications ​

1. Synchronizer Compromise ​

2. Transaction Reordering ​

Comparison to Other Consensus Models ​

Summary: Key Takeaways for CantonDefi ​

Canton Global Synchronizer: Architecture and Implications

Overview

What is the Global Synchronizer?

Core Concept

Key Characteristics

Architectural Implications for CantonDefi

1. Transaction Ordering and Atomicity

2. Two-Phase Commit Protocol

3. Sequence Numbers and Ordering

4. Privacy Model and the Synchronizer

5. Finality and Confirmation

6. Canton Network's Global Synchronizer

7. Cross-Domain Transactions

Performance and Scalability Implications

Throughput Limits

Scalability Through Sharding

Operational Considerations

1. Synchronizer Availability

2. Synchronizer Costs

3. Monitoring and Observability

4. Disaster Recovery

Security Implications

1. Synchronizer Compromise

2. Transaction Reordering

Comparison to Other Consensus Models

Summary: Key Takeaways for CantonDefi