> 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/release-notes.md).

# Release Notes

Product updates and release notes for CAT-BM 2.0 for Canton.

CAT-BM Version 2.0 is a **complete rewrite succeeding the 1.x line**: a new operator, a new REST API, and a rebuilt web UI.

{% hint style="danger" %}
**2.0 is not an in-place upgrade from 1.x.** Install it fresh. Contact IntellectEU support before planning a migration from an existing 1.10 or 1.11 deployment.
{% endhint %}

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td>Version 2.0.0</td><td><a href="#version-2.0.0">#version-2.0.0</a></td></tr><tr><td>Version 2.0.1</td><td><a href="#version-2.0.1">#version-2.0.1</a></td></tr><tr><td>Version 2.0.2</td><td><a href="#version-2.0.2">#version-2.0.2</a></td></tr></tbody></table>

***

## Version 2.0.2

**Released 16 October 2026**

The second patch release on the 2.0 line. It adds **sandbox mode**, which creates a DevNet validator from a name only, **BitGo** as a second Wallet Gateway signing provider, and **advanced configuration for the Participant Query Store**. It also raises the participant and validator app resource defaults, returns RFC 9457 problem details for every API error, and patches a further set of dependency vulnerabilities. Full patch details can be found in the expandable table below.

{% hint style="warning" %}
**Upgrading from 2.0.1**

* Check node capacity

The new defaults request 14Gi of memory for the participant and 8Gi for the validator app, per validator. Both pods restart on the first reconcile after the upgrade. If your nodes cannot fit that, set `spec.participant.resources` / `jvm` and `spec.validator.resources` / `jvm` on the `Validator` before you upgrade.

* Check `image.tag`

If your values file does not set `image.tag`, images now come from the chart's `appVersion` instead of `latest`.

* Review `spec.overrides.*.extraEnv`

2.0.1 ignored these entries. They now take effect on upgrade, and an entry with the same name as an operator-set variable overrides it.

* Leave `operator.database.host` empty on shared clusters

When it is set, the operator ignores each `Validator`'s own `spec.database`, except `pqsDatabase`. Set it only if every validator should use the operator database.

* Apply the updated CRDs

`spec.walletGateway.bitgo`, the new `spec.pqs` fields, and the changed `status.managedAuth` fields all require the regenerated CRDs — see [Platform Installation](/catalyx-blockchain-manager/canton-network/version-2.0/installation-instructions-canton/platform-installation.md#upgrading).

* Check PQS on a Postgres without TLS

PQS connects with `tlsMode: Require` by default. A Postgres without TLS needs `spec.pqs.postgres.tlsMode: Disable`.

* Remove leftover CPM users

The operator no longer manages `<validator-name>-cpm-user` or its `<validator-name>-cpm-user-credentials` Secret. You can delete any that 2.0.1 created. Users now sign in to CPM with their own identity.
{% endhint %}

<details>

<summary>Sandbox mode</summary>

An optional platform mode, turned on with `api.sandbox.enabled: true`, in which a signed-in user creates a **DevNet** validator by entering a **name** only. The party hint and the PQS fields are optional. The API then serves `POST /api/v1/validators`, and the UI shows a create form with no network fields.

On create, the API gets an onboarding token from the sponsor SV and stores it as Secret `<validator-name>-onboarding-secret`, reads the Splice version and the migration ID from Scan, and creates the `Validator` with managed Keycloak and an owner label set to the caller's identity. Each user sees only the validators and applications they own, and can create one validator. The UI has no validator edit action in sandbox mode.

Sandbox validators have no `spec.database`. The new operator-level database (`operator.database.*`) gives the operator a host and credentials, and the operator generates the database names itself. See [Platform Installation](/catalyx-blockchain-manager/canton-network/version-2.0/installation-instructions-canton/platform-installation.md#sandbox-mode-values).

</details>

<details>

<summary>Wallet Gateway</summary>

* **BitGo signing provider.** Wallet Gateway can now hold keys with BitGo as well as DFNS, one or both at a time. The `Validator` gains a `spec.walletGateway.bitgo` block, the API serves `GET`/`PUT /api/v1/validators/{name}/wallet-gateway/providers/bitgo`, and the **Signing Providers** sub-tab shows a BitGo card and configuration dialog next to DFNS. As with DFNS, settings saved from the UI or the API take precedence over the `Validator` fields.
* **Allocate party.** A custodian can answer a signing request with `pending`, which leaves the wallet `initialized`. The new **Allocate party** action (and `POST /api/v1/validators/{name}/wallet-gateway/wallets/allocate`) checks with the provider again and allocates the party once it has signed.
* **Provider list.** `GET /api/v1/validators/{name}/wallet-gateway/providers` lists the signing providers and whether each is enabled.
* **Input checks.** The API checks the party hint, party ID, and provider on create, and returns a clear error for an unsupported provider or when Wallet Gateway is disabled for the validator.
* **Wallet Gateway image.** The examples now use Wallet Gateway `v1.11.3` (was `v1.8.1`).
* **Fixes.** The Refresh action and the Configured badge work correctly, a provider dialog refuses to clear a stored setting instead of reporting it as saved, the provider filter lists provider names only, and required fields are announced to assistive technology. The Wallet Gateway screens were reworded, and a provider's state now reads "enabled" or "disabled".

See [Wallet Gateway](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/wallet-gateway.md).

</details>

<details>

<summary>PQS advanced configuration</summary>

`spec.pqs` now covers most PQS options: stream (`ledgerStop`, `datasource`), filters, JSON encoding, connection and retry tuning, logging, and the `extraArgs` / `extraEnv` escape hatches. All new fields are optional, so a validator that sets none of them runs PQS exactly as before. The exception is `postgres.tlsMode`, which defaults to `Require`.

When authentication is enabled, PQS also gets its token audience from `spec.auth.targetAudience`. Secret values can be passed by reference through `extraEnv`, so the `Validator`, the API, and the UI show only the reference. The **Specification** tab shows every PQS option set on the `Validator`. See [Participant Query Store](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/participant-query-store.md#advanced-configuration).

</details>

<details>

<summary>Operator</summary>

* **Resource defaults.** The participant now defaults to requests `2` CPU / `14Gi`, limits `10` / `14Gi`, heap `10240m`; the validator app to requests `2` / `8Gi`, limits `10` / `8Gi`, heap `6144m`. `Validator` resources that set their own `resources` or `jvm` keep their values. See [Validator CRD Reference](/catalyx-blockchain-manager/canton-network/version-2.0/validator-crd.md).
* **`spec.overrides.<component>.extraEnv` is applied.** 2.0.1 ignored these entries.
* **Participant external URL.** The participant `Application` now reports its JSON Ledger API route, `https://ledger-<validator-name>.<baseHostname>`, as its external URL.
* **CPM identity.** The operator no longer creates a CPM Keycloak user or ledger user. It provisions only the `<validator-name>-cpm-ui` OIDC client, and `status.managedAuth` reports it as `cpmUiClientId`.

</details>

<details>

<summary>REST API</summary>

* **Problem details for every error.** All error responses now use the RFC 9457 problem details format, including errors raised before a request reaches an endpoint. See [API Reference](/catalyx-blockchain-manager/canton-network/version-2.0/support-and-resources/api-reference.md#errors).
* **DAR uploads.** The upload limit is raised from 1 MiB to 10 MiB, and can be changed with `api.upload.maxFileSize` / `api.upload.maxRequestSize`. A file that is not a valid DAR now returns `422` instead of `502`.
* **Hosted Parties performance.** The hosted parties query is narrower, and the UI loads hosted parties only when you open the Parties tab.
* **Validator name check.** The API checks the length and format of validator names.

</details>

<details>

<summary>Web UI</summary>

* An unknown validator sub-path no longer causes a redirect loop.
* DAR search now matches a literal substring.

</details>

<details>

<summary>Helm and operations</summary>

* **`image.tag`** now defaults to empty, so each image uses the chart's `appVersion`. It previously defaulted to `latest`.
* **New values:** `api.sandbox.*`, `operator.database.*`, and `api.upload.maxFileSize` / `api.upload.maxRequestSize` (both `10MB`).
* **Removed:** the unused API client secret left over from the 2.0.1 authentication change.
* The `catalyx-canton-validator` chart renders the new PQS and BitGo fields.

</details>

<details>

<summary>Security</summary>

A third pass of dependency updates — including Log4j, Apache Commons Lang, Netty, Tomcat, and Jackson — across the API, operator, and CRDs, plus hardened log sanitisation.

</details>

<details>

<summary>Artifacts</summary>

| Artifact                                                           | Version  |
| ------------------------------------------------------------------ | -------- |
| `catalyx-console` image (multi-arch `linux/amd64`, `linux/arm64`)  | `v2.0.2` |
| `catalyx-operator` image (multi-arch `linux/amd64`, `linux/arm64`) | `v2.0.2` |
| `catalyx-ui` image (multi-arch `linux/amd64`, `linux/arm64`)       | `v2.0.2` |
| `catalyx-canton` Helm chart                                        | 2.0.2    |
| `catalyx-canton-validator` Helm chart                              | 2.0.2    |

</details>

{% hint style="info" %}
**Known limitations.** Sandbox mode is DevNet only. In sandbox mode, validators without an owner label — for example ones applied with `kubectl` — are hidden from every user, and there is no admin view. Wallet Gateway still does not sign transactions.
{% endhint %}

***

## Version 2.0.1

**Released 4 September 2026**

The first patch release on the 2.0 line. It ships the **Wallet Gateway** and **external party re-hosting**, simplifies how the API authenticates to validators, and patches a set of dependency vulnerabilities. Full patch details can be found in the expandable table below.

{% hint style="warning" %}
**Upgrading from 2.0.0**

* Remove the API's Keycloak client configuration

Drop `api.keycloak.*` and `operator.keycloak.apiClientId` from your values file. The `catalyx-api` Keycloak client, its service account, and every per-validator `<validator-name>-ledger-api` optional scope can be deleted from the realm. If you provisioned the API client secret through External Secrets Operator, remove that remote secret reference — the ExternalSecret template no longer exists.

* Check for `/balances` consumers

`GET /api/v1/validators/{name}/balances` is gone. Nothing in the UI calls it; any external caller needs to query the network's Scan API directly.

* Apply the updated CRDs

`spec.walletGateway`, the new `spec.kms.azure` fields, the per-component `replicas` fields, and the new status fields all require the regenerated CRDs. Apply them before upgrading — see [Platform Installation](/catalyx-blockchain-manager/canton-network/version-2.0/installation-instructions-canton/platform-installation.md#upgrading).

* Enable the Wallet Gateway only if you need it

It stays off unless you set `spec.walletGateway.enabled: true`, and it needs a DFNS organisation and credentials plus two extra databases. Existing validators are unaffected.
{% endhint %}

<details>

<summary>Wallet gateway</summary>

A new optional component, enabled per validator with `spec.walletGateway.enabled`. It holds a party's private key with an external custodian — DFNS today. The operator deploys a dedicated instance for the validator, with its own Keycloak client, ingress routes, and separate store and signing databases.

The UI gains a **Wallet Gateway** tab in the Ledger group, for browsing and creating wallets and for the signing provider's settings. Signing provider settings can now be changed from the UI or the API; the `spec.walletGateway.dfns` fields on the `Validator` resource act as a fallback, so existing resources keep working. See [Wallet Gateway](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/wallet-gateway.md).

{% hint style="info" %}
The Wallet Gateway does **not** sign transactions yet. External party onboarding is unchanged.
{% endhint %}

</details>

<details>

<summary>Multi-host external parties</summary>

A party can now be hosted on **several participants**, including participants operated by other organisations, so it survives the loss of any single validator.

* The external party onboarding wizard gained a **Hosting** step: name additional hosting participants as confirming or observing, set the confirmation threshold, and optionally make the local validator observation-only.
* A new **Hosting Proposals** sub-tab on the Parties tab lists proposals naming this participant, with an **Approve** action. Local and remote co-hosts follow the identical path — nothing is transferred between operators.
* An advisory participant lookup warns when a named participant UID is not present on the synchronizer.
* The **Hosted Parties** sub-tab shows each party's hosts, their permissions, and its confirmation threshold, with a permission filter.

See [External & Multi-Host Parties](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/external-and-multi-host-parties.md).

</details>

<details>

<summary>Validator authentication</summary>

The API no longer has a Keycloak client of its own. It authenticates to each validator as that validator's backend confidential client, `<validator-name>-validator-backend` — the same identity the validator app, PQS, and Wallet Gateway already use — and caches tokens per validator.

The following are removed, and are no longer read if set:

* Helm values `api.keycloak.clientId`, `api.keycloak.credentialsSecretRef`, `api.keycloak.externalSecret.remoteSecretRef`, and `operator.keycloak.apiClientId`
* Environment variables `KEYCLOAK_API_CLIENT_ID` and `KEYCLOAK_API_CLIENT_SECRET`
* The `catalyx-api` Keycloak client, its service account, and the per-validator optional scope `<validator-name>-ledger-api`
* The `catalyx-api-keycloak` ExternalSecret template

</details>

<details>

<summary>Azure KMS</summary>

`spec.kms.azure` now mirrors the Azure KMS driver's configuration. New fields: `credentialType` (`default`, `environment`, or `managedIdentity`), `auditNodeId`, `kekRsaKeySizeBits`, and six strict-mode checks — `requirePinnedKeyVersion`, `validateKeySpec`, `requireKeyOps`, `rejectExportableKeys`, `hardenGeneratedKeys`, and `requireStrongKek`.

Leaving `credentialType` unset keeps the previous requirement for a service principal client secret, so existing resources authenticate exactly as before. See [Key Management Service (KMS)](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/kms-integration.md).

</details>

<details>

<summary>Helm and operations</summary>

* **Pod disruption budgets** for the operator, API, and UI deployments.
* **Per-component replicas.** Each validator component accepts a `replicas` field. `0` scales the component down without deleting it. See [Validator CRD Reference](/catalyx-blockchain-manager/canton-network/version-2.0/validator-crd.md).
* **Ordered startup.** The validator app is held back until the participant reports `Ready`.
* **Keycloak provisioning**: access token lifespan set to 30 minutes, `allowOrigins` configured, and the `openid` scope handled explicitly.

</details>

<details>

<summary>Web UI</summary>

* The **Balances** tab is removed, together with the `GET /api/v1/validators/{name}/balances` endpoint.
* A new **Wallet Gateway** tab in the Ledger group, and a new **Package Manager** tab in a new Integrations group. The detail view now has 14 tabs.
* The Parties tab was reworked.

</details>

<details>

<summary>Security</summary>

Spring Boot and a set of transitive dependencies — Tomcat, Netty, Bouncy Castle, Jackson, Vert.x, Log4j2, and the PostgreSQL driver — were updated in the API and operator, and several UI dependencies were bumped, closing roughly twenty published CVEs and advisories.

</details>

<details>

<summary>Artifacts</summary>

| Artifact                                                           | Version  |
| ------------------------------------------------------------------ | -------- |
| `catalyx-console` image (multi-arch `linux/amd64`, `linux/arm64`)  | `v2.0.1` |
| `catalyx-operator` image (multi-arch `linux/amd64`, `linux/arm64`) | `v2.0.1` |
| `catalyx-ui` image (multi-arch `linux/amd64`, `linux/arm64`)       | `v2.0.1` |
| `catalyx-canton` Helm chart                                        | 2.0.1    |
| `catalyx-canton-validator` Helm chart                              | 2.0.1    |

</details>

{% hint style="warning" %}
**Two changes remove functionality that 2.0.0 shipped:** the API's own `catalyx-api` Keycloak client, and the **Balances** tab. Both need action when you upgrade — see *Upgrading from 2.0.0* below.
{% endhint %}

***

## Version 2.0.0

**Released 31 July 2026**

CAT-BM 2.0 is a **complete rewrite succeeding the 1.x line**: a new operator, a new REST API, and a rebuilt web UI. Full details can be found in the expandable table below

{% hint style="warning" %}
**Upgrading from 1.x**

2.0 is not an in-place upgrade from 1.x. Install it fresh. Contact IntellectEU support before planning a migration from an existing 1.10 or 1.11 deployment.
{% endhint %}

<details>

<summary>Operator</summary>

Apply a single `Validator` custom resource and the operator provisions the full stack — the identity provider realm objects and OIDC clients, the Canton participant node, the validator app, the Wallet UI, and the CNS UI, plus an optional Participant Query Store. Components are managed as child `Application` resources with per-component readiness and reconciliation status. Traefik ingress, and PostgreSQL-backed participant and validator databases provisioned automatically.

</details>

<details>

<summary>REST API</summary>

Read-only against the Kubernetes custom resources, read/write through the Canton Ledger API proxy: balances, traffic status, participant health, DAR packages, ledger users and wallet users, parties — local, external, and onboarding — and participant public keys. Stateless OAuth 2.0 resource server with per-validator scoped tokens. An interactive Canton console over WebSocket. OpenAPI description published at `/v3/api-docs`.

</details>

<details>

<summary>Web UI</summary>

A React single-page application for operating validators without cluster access: a Dashboard, a Validators list, and a 13-tab validator detail view — Summary, Specification, Status, Balances, Traffic, Identity, DARs, Users, Wallet Users, Parties, Endpoints, Participant, and Keys. Application health and resource metrics, with optional Grafana deep links. External party onboarding, and the Canton console.

</details>

<details>

<summary>Artifacts</summary>

| Artifact                                                           | Version  |
| ------------------------------------------------------------------ | -------- |
| `catalyx-console` image (multi-arch `linux/amd64`, `linux/arm64`)  | `v2.0.0` |
| `catalyx-operator` image (multi-arch `linux/amd64`, `linux/arm64`) | `v2.0.0` |
| `catalyx-ui` image (multi-arch `linux/amd64`, `linux/arm64`)       | `v2.0.0` |
| `catalyx-canton` Helm chart                                        | 2.0.0    |
| `catalyx-canton-validator` Helm chart                              | 2.0.0    |

</details>

***

## Earlier versions

Release notes for the 1.x line are published under their own versions in this space.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Version 1.11</strong></td><td>Release notes for the 1.11 line.</td><td><a href="/catalyx-blockchain-manager/canton-network/version-1.11/release-notes.md">Release Notes</a></td></tr><tr><td><strong>Version 1.10</strong></td><td>Release notes for the 1.10 line.</td><td><a href="/catalyx-blockchain-manager/canton-network/version-1.10/release-notes.md">Release Notes</a></td></tr></tbody></table>


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/release-notes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
