> For the complete documentation index, see [llms.txt](https://docs.catalyx.solutions/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-1.11/introduction-to-canton-network.md).

# Introduction to Canton Network

## Canton Network Overview

The [Canton Network](https://www.canton.network/) is the first privacy-enabled interoperable blockchain network, designed for regulated, real-world assets. Blockchain applications in the Canton Network can use the Global Synchronizer to enable atomic transactions across sovereign blockchains, without sacrificing privacy or control.

The Canton network is composed of nodes known as **Validators** that achieve consensus through **Synchronizers**. Validator nodes are responsible for storing contract data and executing smart contract code. The synchronizers, in turn, distribute encrypted messages and facilitate transaction coordination.

Transaction data is only distributed on a **need-to-know basis** to maintain confidentiality. This is the key delta to other chains: In most other chains, all state and transactions get replicated to all nodes/validators. In Canton, state and transactions get distributed only to nodes/validators that are specified in the smart contracts.

## Core Components of the Canton Network

<details>

<summary>The Global Synchronizer</summary>

The [Global Synchronizer](https://www.canton.network/global-synchronizer) is a decentralized and transparently governed interoperability service for the Canton Network.

The Global Synchronizer is a decentrally operated service, using a 2/3 majority Byzantine Fault Tolerant ([BFT](https://docs.sync.global/glossary.html#term-BFT)) consensus protocol for message ordering and confirmation, and BFT majority voting on governance changes.

Its infrastructure is operated by independently acting organizations, called Super Validators, that run components of the decentralized infrastructure, and coordinate activities via an on-chain governance application. Its open source code is maintained in [Splice](https://github.com/hyperledger-labs/splice).

The [Global Synchronizer Foundation (“GSF”)](https://sync.global/) has been created in partnership with the Linux Foundation to coordinate the governance of the Global Synchronizer and lead efforts to grow the Global Synchronizer ecosystem. The GSF provides transparency into Super Validator governance and operations. The GSF also operates a Super Validator node, and takes part in governance votes on behalf of its members.

</details>

<details>

<summary>Synchronizers (previously Domains)</summary>

Canton is a network composed of multiple [synchronizers](https://docs.digitalasset.com/overview/3.4/explanations/canton/synchronizers.html), each operating under its own rules, governance, and set of participants. Each synchronizer functions as an independent sub-network that participates in the wider Canton Network.

In a composed solution, each synchronizer is a sub-network. A [Validator Node](https://docs.sync.global/validator_operator/index.html) (previously Participant nodes) connects to one or more synchronizers, enabling transactions that span domains.

<figure><img src="/files/WSLy7s2AWu68bQ0qoQ3G" alt=""><figcaption></figcaption></figure>

A Canton Domain consists of three entities: Sequencers, Mediators, and a Topology Manager. These are collectively called the **domain entities**.

![Canton Domain Entities Diagram](https://docs.daml.com/_images/canton-domain-diagram.svg)

In general, every domain entity can run in a separate trust domain (i.e., can be operated by an independent organization). In practice, all domain entities are typically run by a single organization. Each participant node runs in its own trust domain.

The generic term **member** refers to either a domain entity or a participant node.

</details>

<details>

<summary>Super Validators</summary>

[Super Validators](https://www.canton.network/blog/what-is-a-validator-on-the-canton-network) form the backbone of the [Global Synchronizer](https://www.canton.network/global-synchronizer)’s decentralized interoperability and synchronization infrastructure. They ensure the integrity, security, and operational reliability of the Global Synchronizer by:

* Running the core infrastructure of the Global Synchronizer
* Sequencing transactions across the network
* Validating Canton Coin transactions
* Participating in network governance and decision-making

</details>

<details>

<summary>Validators (previously Participants)</summary>

[Validators](https://docs.sync.global/validator_operator/index.html) work within the broader Canton Network—a “network of networks” where each node stores only the data it needs, and interacts with other Validators via [synchronizers](https://docs.digitalasset.com/overview/3.4/explanations/canton/synchronizers.html). Validators typically connect to one or more synchronizers (which might be run as centralized or decentralized services) to receive and confirm encrypted messages.

The primary roles of a Validator in the Global Synchronizer ecosystem are to:

* Validate transactions
* Record activity
* Facilitate network connectivity for users and applications
* Coordinate upgrades and migrations

</details>

<details>

<summary>Parties</summary>

In Canton, [parties](https://docs.digitalasset.com/integrate/devnet/canton-network-overview/index.html#parties) are the core on-ledger identities, and are the wallet addresses, similar to an address or Externally Owned Account (EOA) on other blockchains. They are central to how permissions and privacy are managed within the network.

Parties come in two forms, internal and external. An [internal party](https://docs.digitalasset.com/overview/3.4/explanations/canton/external-party.html) is created on the validator node, it gives a validator node submission rights and therefore holds its key on the validator node. Transactions are signed using the Validators own internal keys for signing (and thereby the validator operator has full control of everything that happens on the party).

[External parties](https://docs.digitalasset.com/overview/3.4/explanations/canton/external-party.html) are similar to how node interactions happens on other networks and therefore Externally Owned Accounts. In this case the signing key can be held externally and a signature is required alongside the transaction to authorize the action.

</details>

<details>

<summary>Canton Coin</summary>

Canton Network’s native token, [Canton Coin](https://www.digitalasset.com/hubfs/Canton%20Network%20Files/Documents%20\(whitepapers%2c%20etc...\)/Canton%20Coin_%20A%20Canton-Network-native%20payment%20application.pdf), is a utility token launched as part of the Global Synchronizer. It facilitate the transfer of value, provide incentives, and serve as payment for infrastructure costs.

The Canton Coin application employs a burn-mint equilibrium mechanism, aiming to stabilize the conversion rate of Canton Coin around the intrinsic value it provides to network users:

* Fee Burning: Users pay fees (denominated in USD but paid by burning Canton Coin) when they initiate Canton Coin transfers or when they create a traffic balance. Instead of paying these fees to a central authority, the coins are burned—i.e., removed from circulation.
* Minting Rewards: Validators (as well as Super Validators and application providers) can mint new Canton Coins in return for their “utility” contributions:
  * Infrastructure Operation: Super Validators operating synchronizer nodes earn minting rights by contributing to the synchronization service.
  * Application Services: Application providers can earn rewards any time they facilitate a transaction.
  * Usage: When a Validator uses the network, that Validator earns “minting rights” proportional to the fees they burn, which the network treats as a proxy for the activity generated by that node.
  * Liveness Incentives: Validators are rewarded for uptime and for being ready to serve transaction traffic. If a Validator does not use all its minting allowance via direct activity, a portion is allocated as a “liveness” bonus.
* Dynamic Equilibrium: The system is designed so that, over the long term, the total amount of coins burned (which reflects actual network utility) roughly balances the coins minted (subject to a predetermined maximum allowed minting curve). When usage is high, more coins are burned, tending to increase the token’s conversion rate; when usage is lower, supply increases until balance is restored.

</details>

Please refer to [Digital Assets' documentation](https://docs.digitalasset.com/overview/3.5/overview/index.html) to learn more about the core elements of the Canton Network.

***

## Concepts & Glossary

This section defines the key business and technical terms used throughout the CatalyX Blockchain Manager and Canton integration. Use it as the first reference when encountering unfamiliar terminology.

<details>

<summary>Business Concepts</summary>

| **Term**                        | **Definition**                                                                                                                                         |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Canton Network**              | A privacy-first blockchain network built on Daml, designed for regulated financial applications.                                                       |
| **Participant**                 | An organisation connected to the Canton network that can host parties and submit transactions.                                                         |
| **Domain**                      | The synchronisation layer of Canton — mediates transactions between participants.                                                                      |
| **Sync Domain**                 | Coordinates transaction sequencing. A **Private Sync Domain** is isolated within an organisation; the **Global Sync Domain** is publicly reachable.    |
| **Party**                       | A logical entity within Canton that can own contracts and be a signatory or observer.                                                                  |
| **DAR file**                    | Daml Archive — a compiled package of Daml smart contract code, uploaded to a participant.                                                              |
| **Validator**                   | A Canton node that validates and sequences transactions. A **Bridge Validator** is connected to both a private sync domain and the global sync domain. |
| **Super Validator**             | A special Canton participant node that participates in network governance, permissioning, and topology management on the global sync domain.           |
| **Splice**                      | The open-source governance and reward infrastructure for the Canton Network.                                                                           |
| **CatalyX**                     | IntellectEU's suite of blockchain infrastructure products built on Canton and other protocols.                                                         |
| **CAT-BM**                      | CatalyX Blockchain Manager, IntellectEU’s platform for deploying and operating Canton and other DLT infrastructure.                                    |
| **CPM**                         | CatalyX Package Manager, the application registry ("Canton App Store") for discovering, publishing, and downloading Canton applications.               |
| **GSF /** **Canton Foundation** | Global Synchronizer Foundation that governs the Global Sync Domain on Canton.                                                                          |

</details>

<details>

<summary>Technical Concepts</summary>

| **Term**                             | **Definition**                                                                                                   |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
| **Ledger API**                       | The gRPC API exposed by Canton participant nodes for submitting and reading transactions.                        |
| **Admin API**                        | The API for managing participant configuration, parties, and packages.                                           |
| **Topology**                         | The configuration of domains, participants, and their relationships on the network.                              |
| **PQS (Participant Query Store)**    | A queryable off-ledger store for Canton contract data.                                                           |
| **KMS driver**                       | Canton integration module that delegates key operations to external KMS/HSM (AWS KMS, GCP KMS, HashiCorp Vault). |
| **WaaS**                             | Wallet-as-a-Service (e.g. Dfns), external key custody and signing service supported by CAT-BM.                   |
| **ArgoCD**                           | GitOps continuous-delivery tool used to synchronise desired state from Git into the Kubernetes cluster.          |
| **Helm chart**                       | Kubernetes packaging format used to deploy Canton components.                                                    |
| **CRD (Custom Resource Definition)** | Kubernetes extension used by the CAT-BM Canton Operator to manage node lifecycle.                                |
| **CAT-BM Canton Operator**           | Custom Kubernetes Operator that watches CRDs and reconciles Canton component state.                              |
| **Round**                            | 10-minute cycle on Canton Network governing minting and distribution of Canton Coins.                            |

</details>

***

## Learn more about Canton Network <a href="#learn-more-about-canton" id="learn-more-about-canton"></a>

| **Resource**                                                                                                    | **Purpose**                                              |
| --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
| [Canton Network](https://canton.network/)                                                                       | Official Canton Network site                             |
| [Canton Network Whitepaper](https://www.digitalasset.com/hubfs/Canton/Canton%20Network%20-%20White%20Paper.pdf) | Official Canton Network Whitepaper                       |
| [Global Synchronizer Foundation](https://sync.global/)                                                          | GSF governance, committees, and network information      |
| [Digital Asset docs](https://docs.digitalasset.com/)                                                            | Canton / Daml technical documentation from Digital Asset |
| [Daml documentation](https://docs.daml.com/)                                                                    | Daml language and SDK reference                          |
| [Splice on GitHub](https://github.com/hyperledger-labs/splice)                                                  | Open-source Splice repository                            |
| [CIPs](https://github.com/canton-foundation/cips)                                                               | Canton Improvement Proposals                             |

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-1.11/introduction-to-canton-network.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
