> 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-2.0/architecture/high-level-architecture.md).

# High-Level Architecture

CAT-BM separates a **management plane** (i.e. the components CatalyX ships) from the **Canton stack** those components create and operate.

<div data-with-frame="true"><figure><img src="/files/2sfDNYN0Hoa2TKsLj2oz" alt=""><figcaption><p>High Level Architecture</p></figcaption></figure></div>

## Components

<table><thead><tr><th width="230">Component</th><th>Functional responsibilities</th><th width="180">Interfaces</th></tr></thead><tbody><tr><td>CAT-BM Canton console</td><td>User interface for the Canton infrastructure and application operator.</td><td>Web UI</td></tr><tr><td>CAT-BM Canton API</td><td>Backend API for the user interface and third-party integrations.</td><td>REST API</td></tr><tr><td>CAT-BM Canton operator</td><td>Kubernetes operator for Canton deployment operations.</td><td>Kubernetes custom resource definitions for Canton infrastructure</td></tr><tr><td>Canton nodes</td><td>Canton DLT infrastructure.</td><td>gRPC API, REST API</td></tr><tr><td>Identity provider UI</td><td>User management UI.</td><td>Web UI</td></tr><tr><td>Identity provider API</td><td>API for OIDC-based authentication.</td><td>REST API</td></tr><tr><td>Identity provider database</td><td>Stores users and RBAC configuration.</td><td>ODBC</td></tr></tbody></table>

***

## The management plane

Three components make up the CatalyX management plane. They are installed together by a single Helm chart.

### Operator

The operator watches `Validator` resources and reconciles each one into the workloads that make up a working validator. For a single `Validator` it will:

1. Provision the OIDC clients, scopes, and wallet user in the identity provider (when managed authentication is enabled).
2. Create the participant and validator-app databases and schemas.
3. Create one child `Application` resource per component.

Each `Application` is then reconciled into a Kubernetes `Deployment`, a `Service`, and — for components that are externally reachable — a Traefik `IngressRoute`.

```
Validator                      user-managed entry point
  └─ Application × 4–6         operator-managed, one per component
       └─ Deployment + Service + IngressRoute
```

{% hint style="warning" %}
`Application` resources are an operator implementation detail. Never create, edit, or delete them by hand — the operator owns them and will revert manual changes on the next reconcile. All configuration flows through the `Validator` resource.
{% endhint %}

The components created for a validator are:

| Component        | Always created    | Purpose                                  |
| ---------------- | ----------------- | ---------------------------------------- |
| `participant`    | Yes               | The Canton participant node              |
| `validator`      | Yes               | The validator app (Splice backend)       |
| `wallet-ui`      | Yes               | Canton Wallet web UI                     |
| `cns-ui`         | Yes               | Canton Name Service web UI               |
| `pqs`            | Only when enabled | Participant Query Store                  |
| `wallet-gateway` | Only when enabled | Wallet Gateway, for external key custody |

### API

The API is a stateless service that does two jobs:

* **Reads** validator and application state from the Kubernetes custom resources. It never writes them.
* **Proxies** privileged Canton operations — the Ledger API, the participant Admin API, the Scan API, and the validator app's admin API — so operators and integrations do not need direct network access to the nodes.

It also hosts the WebSocket endpoint that backs the interactive Canton console, and publishes an OpenAPI description of itself.

### Console

The console is a single-page application that talks only to the API. It never talks to Kubernetes or to Canton directly, which means the permissions a console user needs are API permissions, not cluster permissions.

***

## The Canton stack

Everything the operator creates for a validator sits in the Canton stack:

* **`participant`** — the Canton participant node. Owns its own PostgreSQL database. Exposes the Ledger API, the Admin API, a JSON API, and a metrics endpoint.
* **`validator`** — the validator app. Owns its own PostgreSQL database and connects to the network's sequencer, sponsoring Super Validator, and Scan services.
* **`wallet-ui`** and **`cns-ui`** — static web applications served behind the ingress, authenticating against the identity provider.
* **`pqs`** — optional. Streams the ledger into a queryable PostgreSQL store.
* **`wallet-gateway`** — optional. Delegates party signing to an external Wallet-as-a-Service provider.

## Ingress

All external traffic enters through Traefik over HTTPS. The console, the API, and each externally reachable validator component are exposed on their own hostnames or path prefixes derived from the base hostname configured at install time.


---

# 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, and the optional `goal` query parameter:

```
GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/architecture/high-level-architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.