> 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.10/getting-started/canton-component-overview.md). # Canton Component Overview ## Domains 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. ### Sequencer #### Ordering 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 — a list of individual messages are submitted, and all messages in a batch receive the same timestamp. Each message may have a different set of recipients. #### Evidence The sequencer provides recipients with a cryptographic proof of authenticity for every message batch it delivers, including evidence on the order of batches. #### Sender and Recipient Privacy 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. ### Mediator The mediator computes the final result for a confirmation request and distributes it to participants, ensuring that transactions are atomically committed across participants while preserving privacy. 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 4. Sends the result message Additionally, for auditability, the mediator persists every received message in long-term storage. ### Topology Manager The topology manager allows participants to join and leave the Canton domain, and to register, revoke, and rotate public keys. It tracks the parties **hosted** by a given participant and defines the **trust level** of each participant (ordinary or VIP). ## Participant-Internal Canton Components Canton uses the Daml-on-X architecture to promote code reuse. The participant node is broken down into a set of services, with the Canton-specific service being the Ledger Synchronization Service (LSS). ![Participant-internal Canton Components](https://docs.daml.com/_images/canton-participant-components.svg) ### Transactions This is the central component of LSS within Canton. **Submission and Segregation:** 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 encrypted form. The submitter also informs the mediator about the informees and confirmers of the transaction. **Validity and Confirmation Responses:** Each informee of a requested transaction performs local checks on the validity of its visible subtransaction, confirming that it conforms to Daml semantics and the ledger authorization model. **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 messages from the sequencer. ### Identity Client The identity client handles messages coming from the domain topology manager and verifies the validity of received identity information changes. ## Applications A DAML application is an application developed using the DAML programming language. DAML applications treat every action as an asynchronous operation, and contention is considered a natural and expected occurrence. Key design considerations include: * Bundling or batching business logic to increase transaction throughput * Maximizing parallelism through sharding * Avoiding large sets of observers that can hinder parallelism * Splitting contracts across natural lines to reduce contention The diagram below shows the components often used in a DAML deployment. High availability is achieved via active-active (HTTP JSON API Service, sequencer) or active-passive (participant node, mediator) clustering. ![DAML components](/files/c70d60ce205cc8a0534e1d8a0b18afb15d10798a) ## Collections A collection is a workspace area within Catalyst where files containing Daml models, triggers, automation, and UI assets can be uploaded and managed. Collections act as a centralized repository, making it convenient to deploy and redeploy these files across multiple ledgers. ## Validators A validator in the Canton network is a specialized node responsible for validating transactions. Validators operate as part of a broader network that may include both standard validators and super validators. Super validators have additional responsibilities, such as dictating network policies and approving the addition of new validators. As a participant in the network, validators can earn Canton coins as rewards for their services. These tokens can be used to pay for network services, transfer within the network, or manage traffic costs via the integrated wallet. Validators can also register custom names using the Canton Name Server (CNS) or Amulet Name Server (ANS). --- # 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.10/getting-started/canton-component-overview.md?ask= ``` 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.