> 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/validator-management/validator-upgrade-policy-and-release-schedule.md).
# Validator Upgrade Policy and Release Schedule
CatalyX's policy and process for validator node upgrades, release validation, and version compatibility on the Canton Network.
## Overview
CatalyX follows the official Canton Foundation release lifecycle for validator upgrades. New Canton releases are continuously monitored, evaluated, and validated by IntellectEU before being recommended for customer environments.
The objective of the upgrade process is to maintain compatibility with the Canton Network while minimizing operational risk and service disruption.
The official public calendar for SV Operations is published here: [https://sv-cal.canton.foundation](https://sv-cal.canton.foundation/?date=2026-09-24)
{% hint style="info" %}
CatalyX does not automatically upgrade validator nodes. Upgrades are performed in a controlled manner following internal validation, customer communication, and agreed maintenance windows where applicable.
{% endhint %}
***
## Types of Canton Upgrades
A Canton version upgrade consists of updating validator software, applying any required migrations, validating the upgraded deployment, and, when applicable, participating in a coordinated network protocol upgrade.
The process is designed to maintain ledger continuity, preserve participant synchronization, and minimize disruption to running applications. Depending on the target release, an upgrade may involve only updating the validator software or may also require additional migration and network coordination activities.
There are two types of upgrades in the Canton ecosystem: Version Upgrades and Protocol Upgrades.
### Version Upgrade
A version upgrade updates the validator software to a newer supported release (for example, from `0.6.10` to `0.6.11`). Each validator can perform a version upgrade independently; it does not require network-wide coordination.
Version upgrades typically involve:
* Updating the validator image.
* Performing a Helm upgrade (Kubernetes deployments).
* Updating the deployment bundle for Docker Compose deployments.
During a standard version upgrade:
* Do not delete or recreate the PostgreSQL databases.
* Do not modify migration IDs unless explicitly required by the release.
* Do not modify onboarding or application secrets.
* Always review the release notes before upgrading.
{% hint style="info" %}
For Docker Compose deployments, update the complete deployment bundle, including the Docker Compose files and startup scripts. Updating only the image tag may not be sufficient, because newer releases can introduce deployment configuration changes.
{% endhint %}
### Protocol Upgrade
A protocol upgrade changes the Canton Network protocol itself. Unlike version upgrades, protocol upgrades are coordinated across the network and follow a scheduled activation time.
Modern Canton releases use the **Logical Synchronizer Upgrade (LSU)** mechanism, allowing validators to transition to the new protocol with minimal disruption while maintaining application availability. Protocol upgrades generally do not require manual database migration or data reloading — see [Logical Synchronizer Upgrade (LSU)](#logical-synchronizer-upgrade-lsu) below.
***
## Logical Synchronizer Upgrade (LSU)
Beginning with Canton 3.5, protocol upgrades use the Logical Synchronizer Upgrade (LSU) mechanism. Instead of replacing the synchronizer infrastructure in place, LSU introduces the new synchronizer alongside the existing one.
The upgrade process allows:
* Parallel operation of old and new synchronizers.
* Validators to support both protocol versions during the transition.
* Automatic switching to the new logical synchronizer at the scheduled upgrade time.
* Continuous application availability throughout the upgrade.
* Retirement of the previous synchronizer after a defined retention period.
{% hint style="success" %}
LSU significantly reduces maintenance effort and enables seamless protocol upgrades across the network — no manual database migration or ledger reload is required on the validator side.
{% endhint %}
***
## Upgrade Policy
Validator upgrades are performed according to the release schedule published by the Canton Foundation.
When a new supported version becomes available, IntellectEU:
* Reviews the Canton Foundation release notes.
* Evaluates compatibility with supported CatalyX components.
* Performs internal validation and testing.
* Reviews migration requirements and known issues.
* Updates internal and customer documentation where necessary.
* Recommends the validated release to customers.
* Assists customers with upgrade planning and execution.
This process ensures that validator nodes remain compatible with the Canton Network while reducing the risk of introducing regressions into production environments.
***
## Release Validation Process
Before a validator version is recommended for customer use, IntellectEU follows an internal release validation process:
1. Reviewing the new Canton Foundation release.
2. Validating compatibility with supported CatalyX services.
3. Testing validator deployment and upgrade procedures.
4. Verifying database migrations (if applicable).
5. Validating package compatibility.
6. Reviewing known issues and workarounds.
7. Updating operational documentation.
8. Recommending the validated release for customer deployment.
{% hint style="info" %}
Only validated releases are recommended for production environments.
{% endhint %}
***
## Canton Release Schedule
CatalyX does not maintain its own fixed release calendar for Canton validator versions. Validator upgrades follow the availability of new Canton Foundation releases.
The official public calendar for SV Operations is published here: [https://sv-cal.canton.foundation](https://sv-cal.canton.foundation/?date=2026-09-24)
Customers can monitor upcoming and released versions through:
* Canton Foundation release announcements
* The official [Super Validator Operations calendar](https://sv-cal.canton.foundation), maintained by the Canton Foundation
* CatalyX Blockchain Manager [Release Notes](/catalyx-blockchain-manager/canton-network/version-1.11/release-notes.md)
* CatalyX Product Roadmap
After a new Canton release becomes available, IntellectEU performs validation before recommending customer upgrades.
***
## Typical Upgrade Process
A validator upgrade generally consists of four stages.
{% stepper %}
{% step %}
#### Preparation
Before performing an upgrade, it is recommended to:
* Schedule an appropriate maintenance window.
* Review the release notes for the target version.
* Verify that recent database backups are available.
* Verify that a recent Validator Identity Dump (IDDump) exists.
* Review any migration requirements.
Testing the upgrade in DevNet or TestNet before upgrading Production is recommended.
{% hint style="info" %}
See [Validator Backups and Identity Dumps](/catalyx-blockchain-manager/canton-network/version-1.11/validator-management/identity-backup-and-recovery.md) for how to schedule and verify backups and IDDumps.
{% endhint %}
{% endstep %}
{% step %}
#### Upgrade the Validator Software
Update the validator deployment to the target version.
**Kubernetes**
Update the validator image and perform a Helm upgrade.
Example:
`spec: imageTag: 0.6.x`
**Docker Compose**
Update the complete deployment package, including:
* docker-compose.yml
* start.sh
* IMAGE\_TAG
Updating only the image tag is not sufficient because newer releases may require updated deployment configuration.
{% endstep %}
{% step %}
#### Leave the Migration ID Unchanged
Hard domain migrations no longer exist. Since Splice 0.6.2, network upgrades use the Logical Synchronizer Upgrade (LSU) described in the next step, which needs no change to the validator definition.
* Do not change the **Migration ID** of an existing validator. It is used to name the participant database.
* The `migrationMigrating` flag is deprecated and ignored.
{% hint style="info" %}
From CAT-BM v1.11.19, the Migration ID and migration flag are no longer shown when editing a validator, and the Migration ID is optional for new validators.
{% endhint %}
{% endstep %}
{% step %}
#### Network Protocol Upgrade (When Applicable)
When a release includes a protocol upgrade, the Canton Network coordinates the transition using the **Logical Synchronizer Upgrade (LSU)** mechanism.
The process consists of:
1. Deploying the next-generation synchronizer alongside the existing infrastructure.
2. Running both synchronizers in parallel.
3. Validators upgrading to software supporting both protocol versions.
4. Scheduling the protocol switch through network governance.
5. Validators automatically switching to the new logical synchronizer.
6. Retiring the previous synchronizer infrastructure after the retention period.
This approach allows applications to continue operating throughout the protocol transition without requiring data migration or ledger reloading.
{% endstep %}
{% step %}
#### Post-Upgrade Validation
After the upgrade completes, verify that the validator is operating normally:
* Validator status is **Running**.
* Participant successfully joins and synchronizes with the network.
* Wallet login succeeds.
* Applications start successfully.
* No startup errors are present in the logs.
* Scan API responds successfully.
* Health status is normal.
Continue monitoring logs until validator initialization completes successfully.
{% endstep %}
{% endstepper %}
***
## Backup Recommendations Before Upgrading
Before every upgrade, IntellectEU recommends creating both a database backup and a Validator Identity Dump (IDDump). See [Validator Backups and Identity Dumps](/catalyx-blockchain-manager/canton-network/version-1.11/validator-management/identity-backup-and-recovery.md) for scheduling and restore procedures.
| Backup Type | Preserves | Does Not Preserve |
| ---------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------- |
| Database Backup | Validator database, participant database, ledger state, transaction history | Validator identities and cryptographic keys |
| Identity Dump (IDDump) | Validator identity, cryptographic keys, wallet identity, participant identity | Database contents, ledger state, transaction history |
{% hint style="warning" %}
For complete disaster recovery, both database backups and Identity Dumps should be available before performing an upgrade.
{% endhint %}
***
## Rollback Considerations
Rollback depends on the type of upgrade being performed.
**Validator software** — If no irreversible migration has occurred, validator software can generally be reverted to a previous supported version.
**Application upgrades** — Upgrades involving Daml package changes may require a more controlled rollback process. If new contract types or fields have already been introduced, reverting to a previous package version may not be possible; instead, a new package version may need to be published to safely migrate contracts back to a compatible state.
{% hint style="warning" %}
Always create both a database backup and a Validator Identity Dump (IDDump) before starting any upgrade, so recovery options remain available regardless of the rollback path.
{% endhint %}
***
## Application Upgrade Considerations
Application upgrades should support mixed-version deployments during the transition. The recommended approach combines:
* **Asynchronous rollout** — application providers and users independently deploy upgraded frontends, backends, and Daml packages.
* **Synchronous switch-over** — all participants activate the new workflows at an agreed point in time, once the required packages have been deployed. This minimizes the risk of workflow failures caused by version mismatches.
This approach allows existing workflows to continue operating while organizations upgrade on their own schedules.
***
## Upgrade Best Practices
**Before upgrading:**
* Review the release notes.
* Create a database backup.
* Create a Validator Identity Dump.
* Verify migration requirements.
* Schedule a maintenance window.
* Test the upgrade in DevNet or TestNet before Production.
**After upgrading:**
* Verify validator health.
* Confirm participant synchronization.
* Test wallet connectivity.
* Verify application functionality.
* Review logs for startup or migration errors.
* Monitor the deployment until it is fully operational.
***
## Version Compatibility
Validator nodes should remain on a supported Canton version validated by IntellectEU.
Although older versions may continue operating for a period of time, remaining significantly behind the supported version increases operational risk and may eventually lead to incompatibility with newer network components.
Customers are encouraged to upgrade after IntellectEU validates and recommends a new release.
### Consequences of Running an Outdated Validator
If a validator remains on an older version after the Canton Network has moved forward, the following issues may occur:
* Application initialization failures.
* Package compatibility conflicts.
* Migration failures.
* Validator remaining in **Pending** state.
* Failure to join or synchronize with the network.
* Inability to deploy newer applications or packages.
* Reduced compatibility with newer Canton protocol features.
* Unsupported configuration for future incident resolution.
{% hint style="danger" %}
In some cases, the validator must be upgraded before normal operation can resume.
{% endhint %}
***
## Customer Communication Process
When a new supported validator version becomes available, IntellectEU typically follows this process:
1. Review the official Canton Foundation release.
2. Perform internal compatibility testing.
3. Validate upgrade and migration procedures.
4. Update operational documentation if required.
5. Notify customers of the recommended upgrade.
6. Schedule or assist with the upgrade.
7. Verify validator health after deployment.
***
## Frequently Asked Questions
How often should validator nodes be upgraded?
Validator nodes should be upgraded after IntellectEU has validated and recommended the corresponding Canton Foundation release. There is no fixed calendar for upgrades, as they depend on the Canton Foundation release schedule and the validation process performed by IntellectEU.
Does every upgrade require a migration?
No. Some releases only require updating the validator application version, while others introduce schema or application changes that require a migration. Migration requirements are documented as part of each supported release.
Can upgrades be rolled back?
Application versions can generally be reverted if necessary. However, migrations may introduce irreversible data changes. Always create a database backup and Identity Dump before upgrading to ensure recovery options are available.
How long does an upgrade take?
Upgrade duration depends on validator size, database size, whether migrations are required, and infrastructure performance. Most routine upgrades complete within a planned maintenance window.
What is the difference between a version upgrade and a protocol upgrade?
A version upgrade updates the validator software independently on each node. A protocol upgrade changes the Canton Network protocol and is coordinated across the network, using the Logical Synchronizer Upgrade (LSU) mechanism in modern releases. See [Types of Canton Upgrades](#types-of-canton-upgrades).
Does every upgrade require downtime?
Not necessarily. Validator software upgrades typically require a maintenance window for the individual deployment. Protocol upgrades using LSU are designed to minimize service interruption and allow applications to continue operating during the transition.
Can validators be upgraded independently?
Yes, for version upgrades — each validator operator upgrades independently. Protocol upgrades, however, are coordinated across the Canton Network and follow a scheduled activation time.
Should upgrades be tested before Production?
Yes. IntellectEU recommends validating upgrades in DevNet or TestNet before deploying them to Production.
What happens if I delay upgrading?
Running an outdated validator version may eventually lead to package compatibility issues, application compatibility issues, and reduced compatibility with newer Canton features. See [Consequences of Running an Outdated Validator](#consequences-of-running-an-outdated-validator).
---
# 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-1.11/validator-management/validator-upgrade-policy-and-release-schedule.md?ask=&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.