Component overview


A Canton domain consists of three entities:

  1. Sequencers

  2. Mediators

  3. Topology manager

We call these the domain entities. The high-level communication channels between the domain entities are depicted below.

Canton Domain Entities Diagram
Figure 1. Canton Domain Entities Diagram

In general, every domain entity can run in a separate trust domain (i.e., can be operated by an independent organization). In practice, we assume that all domain entities are run by a single organization, and that the domain entities belong to a single trust domain.

Furthermore, each participant node runs in its own trust domain. Additionally, the participant may outsource a part of its identity management infrastructure, for example to a certificate authority. We assume that the participant trusts this infrastructure, that is, that the participant and its identity management belong to the same trust domain. Some participant nodes can be designated as VIP nodes, meaning that they are operated by trusted parties. Such nodes are important for the VIP confirmation policy.

The generic term member will refer to either a domain entity or a participant node.



The sequencer provides a global total-order multicast where messages are uniquely time-stamped and the global ordering is derived from the timestamps. Instead of delivering a single message, the sequencer provides message batching, that is, a list of individual messages are submitted. All these messages get the timestamp of the batch they are contained in. Each message may have a different set of recipients; the messages in each recipient’s batch are in the same order as in the sent batch.


The sequencer provides the recipients with a cryptographic proof of authenticity for every message batch it delivers, including evidence on the order of batches.

Sender and Recipient Privacy:

The recipients do not learn the identity of the submitting participant. A recipient only learns the identities of recipients on a particular message from a batch if it is itself a recipient of that message.


The mediator’s purpose is to compute the final result for a confirmation request and distribute it to the participants, ensuring that transactions are atomically committed across participants, while preserving the participants’ privacy, by not revealing their identities to each other. At a high level, the mediator:

  1. Collects confirmation responses from participants,

  2. Validates them according to the Canton protocol,

  3. Computes the conclusions (approve / reject / timed out) according to the confirmation policy, and

  4. Sends the result message.

Additionally, for auditability, the mediator persists every received message (containing informee information or confirmation responses) in long term storage and allows an auditor to retrieve messages from this storage.

Topology Manager

The topology manager allows participants to join and leave the Canton domain, and to register, revoke and rotate public keys.

It knows the parties hosted by a given participant. It defines the trust level of each participant. The trust level is either ordinary or VIP. A VIP trust level indicates that the participant is trusted to act honestly. A canonical example is a participant run by a trusted market operator.

Participant-internal Canton Components

Canton uses the Daml-on-X architecture, to promote code reuse. In this architecture, the participant node is broken down into a set of services, all but one of which are reused among ledger implementations. This ledger-specific service is called the Ledger Synchronization Service (LSS), which Canton implements using its protocol. This implementation is further broken down into multiple components. We now describe the interface and properties of each component. The following figure shows the interaction between the different components and the relation to the existing Ledger API’s command and event services.

Participant-internal Canton Components
Figure 2. Participant-internal Canton Components


This is the central component of LSS within Canton. We describe the main tasks below.

  • Submission and Segregation: A Daml transaction has a tree-like structure. The ledger privacy model defines which parts of a transaction are visible to which party, and thus participant. Each recipient obtains only the subtransaction (projection) it is entitled to see; other parts of the transaction are never shared with the participant, not even in an encrypted form. Furthermore, depending on the confirmation policy, some informees are marked as confirmers. In addition to distributing the transaction projections among participants, the submitter informs the mediator about the informees and confirmers of the transaction.

  • Validity and Confirmations Responses: Each informee of a requested transaction performs local checks on the validity of its visible subtransaction. The informees check that their provided projection conforms to the Daml semantics, and the ledger authorization model. Additionally, they check whether the request conflicts with an earlier request that is accepted or is not yet decided. Based on this, they send their responses (one for each of their views), together with the informee information for their projection, to the mediator. When the other participants or domain entities do not behave according to the protocol (for example, not sending timely confirmation responses, or sending malformed requests), the transaction processing component raises alarms.

  • Confirmation Result Processing. Based on the result message from the mediator, the transaction component commits or aborts the requested transaction.

Sequencer Client

The sequencer client handles the connection to the sequencer, ensures in-order delivery and stores the cryptographic proofs of authenticity for the messages from the sequencer.

Identity Client

The identity client handles the messages coming from the domain topology manager, and verifies the validity of the received identity information changes (for example, the validity of public key delegation


A DAML application refers to an application developed using the DAML programming language.

In DAML programming, every action within the system is treated as an asynchronous operation, and contention is considered a natural and expected occurrence. However, managing contention is essential to ensure optimal application performance. The goal is not to eliminate contention entirely but rather to handle it gracefully and reduce its impact.

Designing a DAML application involves understanding the sources of contention and employing various techniques to manage it and enhance performance. These techniques include bundling or batching business logic to increase transaction throughput, maximizing parallelism through sharding, and avoiding large sets of observers that can hinder parallelism.

When designing a DAML application, it is important to identify areas of contention, split contracts across natural lines to reduce contention, partition contracts along logical divisions, and minimize the number of partitions accessed in each transaction. Additionally, leveraging contention-free representations whenever possible can be beneficial.

DAML, being a functional programming language, follows functional programming principles, which contribute to safer and more secure smart contract development. Embracing functional programming practices is recommended when building DAML applications.

The DAML SDK provides developers with tools and libraries that simplify the development of multi-party applications. It includes features for defining the application’s schema and implementing off-ledger code that can utilize the Canton APIs.

The diagram below shows the components often used in a Daml deployment. High availability is achieved via either active-active (HTTP JSON API Service, sequencer) or active-passive (participant node, mediator) clustering. Node scaling is achieved via horizontal scaling with participant nodes requiring sharding across participants.

DAML components
Figure 3. DAML components


a collection refers to a feature or area within the workspace of an application where files containing Daml models, triggers, automation, and UI assets can be uploaded and managed. The collection acts as a centralized repository for these files, making it convenient to deploy and redeploy them across multiple ledgers. It provides a structured way to organize and store the necessary components of the application.

By utilizing the workspace collection, users can easily deploy files into a ledger by either clicking the "Deploy to…​" button or by directly dragging and dropping the file into a ledger. This streamlined process simplifies the deployment of assets and promotes efficient management of the application’s resources.

Additionally, the workspace may include pre-built sample applications that are fully functional. These applications can be deployed to their own dedicated ledgers with a single click, further enhancing the ease and speed of deployment for users.