The sections covered in this release note are:

Summary

What’s New

Additional Enhancements and Updates

Security and Bug Fixes

LTS FAQ

Download and Installation

Summary

Release 2.10.0 has three key enhancements.

First, the long awaited Smart Contract Upgrade (SCU) is now Generally Available. Fixing application bugs or extending Daml models is possible without downtime or breaking Daml clients. This feature also eliminates the need to hardcode package IDs which increases developer efficiency. The steps to enable this feature are described below.  It was introduced as Beta in v2.9.1 and has since undergone a lot of hardening based on customer feedback so it transitioned to GA status.

Secondly, the new “Tri-State Vetting” feature complements SCU by allowing a DAR to be unvetted in production. This is helpful to disable a DAR that has a bug in its business logic and then upgrade it without downtime.  

Lastly, this is the first Daml Enterprise release to be designated a Long Term Support (LTS) release.  An LTS release focuses on long term stability and may forgo feature enhancements.   It is supported for multiple years and can be upgraded to with full data continuity, but it does have some caveats:

• Limited cross-version compatibility, specifically no guaranteed support for old Canton Protocol versions.
• No long-term support for deprecated features.
• Focuses on supporting LTS versions of environment components (java, databases, etc).
• LTS releases are only guaranteed to have Critical or High issues fixed.  Lower priority fixes are possible but not mandatory.

Please see the section LTS FAQ below for more information.

The many additional enhancements and bug fixes of this release are discussed further below.

Impact and Migration

Daml 2.10.0 is a Long Term Support (LTS) release. There is a new Canton protocol version (PV=7) in this release and it also supports PV=5. Please note that protocol version 6 has been marked as deleted and should not be used. Protocol version 7 has been introduced as its stable replacement. There is also a  new Daml LF version (LF 1.17). Some features  have been deprecated in support of this being a LTS release and also to enable SCU.

Please remember that since version 2.9, you must set the protocol version explicitly. In prior releases, the domain protocol version was set to the latest protocol version by default. To specify the protocol version for a domain:

myDomain {

  init.domain-parameters.protocol-version = 7

}

Specifying for  a domain manager is:

domainManager {

  init.domain-parameters.protocol-version = 7

}

You can read more about protocol versions in the public docs. If you are unsure which protocol version to pick, use the latest one supported by your binary (see docs).

Please ensure all your environments use the same protocol version: you should not use one protocol version in your test environment and another one in production.

If a protocol version is not provided, then an error message like this will be generated:

ERROR c.d.c.CantonEnterpriseApp$ - CONFIG_VALIDATION_ERROR(8,0): Failed to validate the configuration due to: Protocol version is not defined for domain `mydomain`. Define protocol version at key `init.domain-parameters.protocol-version` …

Daml-LF versions 1.14, 1.15, and 1.17 are available in this release. LF 1.15 is the default Daml compiler setting. LF 1.16 has been deleted and should not be used. Use LF 1.17 to enable the SCU feature.

The compatibility matrix is:

• PV5 is compatible with LF 1.14 and LF 1.15.
• PV7 is compatible with LF 1.14, LF 1.15, and LF 1.17.

PV7 and LF 1.17 enable SCU and SCU is disabled with any other configuration.

Please note that the deprecated Intel-based MacIntosh binaries are produced on a best effort basis.  At some future point, a lack of Intel Mac machines may preclude building Intel binaries which will result in Intel-based MacIntosh support changing to unsupported and unavailable.

What’s New

Smart Contract Upgrading (SCU)

The SCU feature debuted as a Beta level feature in 2.9.1 and it is now GA.  These release notes similar to the 2.9.1 release notes with some updates.

Background

SCU allows Daml models (packages in DAR files) to be updated on Canton transparently, provided guidelines in making the changes are followed. For example, you can fix a Daml model bug by uploading the DAR that has the fixed package version. This feature requires LF 1.17 and Canton Protocol versions 7. The detailed documentation is available here with the reference documentation available here.  Please note that enabling this feature may require code updates for rarely used language idioms.  It does require that the daml.yaml file sets the package version and that the version is increasing as new versions are developed.

Details

This feature is well-suited for developing and rolling out incremental template updates. There are guidelines to ensure upgrade compatibility between DAR files. The compatibility is checked at compile time, DAR upload time, and runtime. This is to ensure data backwards compatibility and forward compatibility (subject to the guidelines being followed) so that DARs can be safely upgraded to new versions. It also prevents unexpected data loss if a runtime downgrade occurs (e.g., a ledger client is using template version 1.0.0 while the participant node has the newer version 1.1.0).

A general guideline is that additive model changes are allowed but items cannot be removed. A summary of the allowed changes in templates are:

• A template can add new optional fields at the end of the list of fields;
• A record datatype can add new optional fields at the end of the list of fields, and a variant/enum datatype can add new constructors at the end;
• The ensure predicate can be changed and it is reevaluated at interpretation;
• A choice signature can be changed by adding optional parameters at the end;
• The controller of a choice can be changed;
• The observer of a choice can be changed
• The body of a choice can be changed;
• A new choice can be added to a template;
• The implementation of an interface instance can be changed;

The Beta version of this feature allowed a new interface instance to be added to a template but this ability is not available in the GA release. Please consult the documentation for more information.

The package name associates a series of DAR versions where the newest version is the default version to use. The package name and version (e.g., “version: 1.1.0”) are specified in the daml.yaml file. Package name is now part of the Fully Qualified Name instead of the package ID. Internally, the package ID is still available and used at run time where the package name and version are resolved to a package ID. This allows backwards compatibility.There is flexibility where the package ID can still be specified (prior approach) or the package name can be used (new approach). A side effect is that the package name provides a namespace scope where modules, templates, and data belong to the namespace of a package. 

To prevent unexpected behavior, this feature enforces that a DAR being uploaded to a participant node has a unique package name and version. This closes a loophole where the PN allowed uploading multiple DARs with the same package name and version. For backward compatibility, this restriction only applies for packages compiled with LF >= 1.17. If LF <= 1.15 is used, there can be several packages with the same name and version but this should be corrected as it will not be supported further.

Compilation support for smart contract upgrade is enabled by adding following fields to the daml.yaml:

--target=1.17

upgrades: <path to dar files of prior versions>

For additional type checking, use the ‘dry-run’ option which simulates the checks a PN will run during the upload step. The format of the command is “daml ledger upload-dar --dry-run” which can be included as part of a CI/CD process.

The JSON API server is compatible with the smart contract upgrade feature by:

• Supporting package names for commands and queries;
• Allowing use of an optional packageIdSelectionPreference field to specify a preferred package ID to use.  This allows the client to specify the package ID like in prior releases but it is not a best practice;
• Requiring either a package ID or package name to be present to disambiguate the partially-qualified form of template/interface ids.

Previously JSON API had supported partially qualified template IDs, (i.e.  simply ``<module>:<entity>``) as an interactive convenience which fails if  there is more than one package with matching template names. Since this   format was not supported for production use and will not work with smart  contract upgrades, it is now unavailable.

The Java and TypeScript codegen allow the use of package name and package ID (if needed). 

Impact and Migration

This feature is not enabled by default. There are three steps that are required to enable this feature:

1., Compile the Daml model(s) into LF 1.17 (LF 1.15 is the default). When using the daml build command to compile a Daml project, make sure the LF-version is set to 1.17. To do this, set this field in the daml.yaml

build-options:

 ---target=1.17

Additionally, use the following field to enable compile time checking of LF 1.17 upgrade DARs:

upgrades: <path to dar files of prior versions>

2. The Canton protocol version needs to be set to 7. (This is the default version for daml sandbox and daml start.) See here (the parameter protocolVersion) for domain parameter configuration.

3. Use the script library called daml-script-lts instead of the older daml-script. 

4. Domain migration. For existing systems, the protocol version change requires a domain migration that is discussed in “Change the Canton Protocol Version.” 

This feature is not compatible with some deprecated coding patterns which may require some code changes. 

1. Retroactive interface instances are not supported.

2. Using divulged contracts during interpretation, is deprecated since Daml 1.14, and does not work with upgrades.

3. Interface definitions are not upgradable by SCU.  So, to allow upgrading of templates,  move co-mingled interfaces into a different package that can be referenced by all current and future versions of the template.

4. Exception definitions are not upgradable by SCU. So, to allow upgrading of templates,  move co-mingled exception definitions into a different package. 

5. Test scripts are not upgradable by the SCU. Move your tests to a separate dedicated package and make sure they are not uploaded to the ledger. 

Please refer to the documentation for more details.

Known limitations

Compile time compatibility checking in the IDE is not reflected directly in the IDE (Daml Studio). 

Triggers are incompatible with the DAML-LF 1.17. As a consequence, you cannot use upgrading (available in 1.17) and triggers (available in 1.15) in combination.

A participant running 2.10 and protocol version 5 will not be able to connect to a domain running on versions 2.9.0 through 2.9.3). The issue is fixed on 2.9.4.

Tri-State vetting

Background

Starting with protocol version 7, topology management is extended with full support for unvetting which  disables all Choices and bare contract creates for the unvetted DAR. You would want to use this if there was a DAR that had a serious logic error in a Choice and you did not want anyone to execute that Choice so you unvett the DAR.  In particular, this feature:

• Allows a participant to disable a DAR for new transactions, while still allowing the validation of existing contracts that were created with that DAR.
• Allows upgrading contracts originally created with packages no longer vetted.

Specific changes

A new CheckOnlyPackages topology transaction is introduced, alongside the existing VettedPackages, that allows a participant to specify a collection of Daml packages that can only be used for validating pre-existing contracts on the ledger and not for executing new Daml transactions.

The currently existing DAR disabling/unvetting operations become supported for production usage when:

• Issuing a specific request against the gRPC participant Admin API: PackageService.unvetDar

• Using the Canton console command: participant.dars.vetting.disable

By default CheckOnlyPackages transactions will be published automatically when a DAR is disabled.  In case low level management of CheckOnlyPackages topology transactions is needed, the following new topology management endpoints have been introduced:

• For adding new transactions: TopologyManagerWriteService.AuthorizeCheckOnlyPackages or via Canton console: participant.topology.check_only_packages.authorize
• For querying the current state: TopologyManagerReadService.ListCheckOnlyPackages or via Canton console: participant.topology.check_only_packages.list

Impact and migration

There is no migration required since this is a new protocol version 7 feature. In participants running with prior protocol versions, unvetting of DARs is supported for production use-cases.

Additional Enhancements and Updates

Canton

Memory check during node startup:  A memory check has been introduced when starting the node. This check compares the memory allocated to the container with the -Xmx JVM option. The goal is to ensure that the container has sufficient memory to run the application. To configure the memory check behavior, add one of the following to your configuration:

canton.parameters.startup-memory-check-config = warn  // Default behavior: Logs a warning.

canton.parameters.startup-memory-check-config = crash // Terminates the node if the check fails.

canton.parameters.startup-memory-check-config = ignore // Skips the memory check entirely.

Keep Alive configuration in Ledger API:  gRPC subsystem comes with a built-in mechanism for sending keep alive signals. All Canton endpoints support this concept. However, so far only Canton's Public and Admin APIs could be configured to change the default behavior. Now, also the Ledger API gains this capability.

The keep alive behavior of the Ledger API can be configured through

canton.participants.participant.ledger-api.keep-alive-server.*

The default values of the keep alive configuration for the ledger api has been set to

time: 10m

timeout: 20s

permitKeepAliveTime: 10s

permitKeepAliveWithoutCalls: true

The default values of the keep alive configuration for all the other endpoints are set to

time: 40s

timeout: 20s

permitKeepAliveTime: 20s

permitKeepAliveWithoutCalls: false

The effective settings are reported by the Participant Node at the initialization time with a logline:

2024-10-31 18:09:34,258 [canton-env-ec-35] INFO  c.d.c.p.a.LedgerApiService:participant=participant - Listening on localhost:5001 over plain text with LedgerApiKeepAliveServerConfig(10m,20s,10s,true).

A new parameter value for permitKeepAliveWithoutCalls has been introduced to all keep alive configurations. When set, it allows the clients to send keep alive signals outside any ongoing grpc call.

Enhanced status admin command:  The status of all Canton nodes now includes the Canton release version. Additionally, the participant status lists the supported protocol versions while domain nodes such as the sequencer show the protocol version. The additional status information is only available from Canton nodes running on this or later versions.

Please note that  this change may break Canton scripts if they import `NodeStatus` and derived classes, as they have been moved into a new package. This will not happen in the default case but only if the operator has made explicit use of the types.  The following import statement needs to be updated:

-import com.digitalasset.canton.health.admin.data.{NodeStatus, ParticipantStatus}

+import com.digitalasset.canton.admin.api.client.data.{NodeStatus, ParticipantStatus}

Command rejection logging:  When a command is rejected due to conflict (e.g. usage of an inactive contract), every participant detecting the conflict will now log the resource causing the conflict at INFO level. This change affects the following error codes:

• LOCAL_VERDICT_LOCKED_CONTRACTS
• LOCAL_VERDICT_LOCKED_KEYS
• LOCAL_VERDICT_INACTIVE_CONTRACTS
• LOCAL_VERDICT_DUPLICATE_KEY
• LOCAL_VERDICT_INCONSISTENT_KEY
• LOCAL_VERDICT_CREATES_EXISTING_CONTRACTS

Additional metrics added:  Two new metrics have been added that count the number of created and archived contracts observed by a participant. Contracts created as part of the standard Canton ping workflow are excluded from the tally.

• participant_daml_parallel_indexer_creates
• participant_daml_parallel_indexer_archivals

KMS key management:  This is a type change which may break scripts:  the `name` parameter of `rotate_node_key` from `Option` to `String`.  Added a `name: String` parameter to `rotate_kms_node_key`, allowing operators to specify a name for the new key.

Performance improvements:  We reduced the latency on the sequencer for processing and sequencing events from other nodes.  We introduced contract key prefetching / bulk loading to improve workloads that fetch many contract keys.

Removed deprecated Java bindings:  Java binding functionality deprecated in 2.5 for command submission has been permanently removed. This affected following methods

•   redundant constructors of `SubmitCommandsRequest`
•   redundant serialization methods of the form `SubmitCommandsRequest.toProto`
•   redundant serialization methods of the form `SubmitAndWaitRequest.toProto`
•   redundant serialization methods of the form `SubmitRequest.toProto`

Additional monitoring: Several monitoring enhancements are available:

• Canton can now include JVM Garbage collection events in the log file. This can be enabled using the configuration option `canton.monitoring.logging.log-gc-events = true`
• Canton now checks if a Postgres database connection becomes read-only.
• Added a new command health.count_in_flight that returns the number of pending submissions and transactions on a domain.

Query cost logging: Periodic query cost logging now also covers the standard deviation  of query times alongside the previously supported mean and total times.

Transaction Trace:  This feature provides a trace to help developers debug and diagnose issues in their DAML model more effectively. It is similar to a stack trace but only tracks command and exercise calls.

• Logging Level: The trace is outputted at the DEBUG level in the participant log.
• Error Handling: The trace is output at the point of any interpretation error and when the interpretation is aborted due to a timeout
• Trace Format: The transaction trace outputs in the following format:

in choice XXXXXXXX:Mod2:Template2:Choice2 on contract 00XXXXXXXX (#3)

in choice XXXXXXXX:Mod1:Template1:Choice1 on contract 00XXXXXXXX (#1)

in create-and-exercise command XXXXXXXX:Mod1:Template1:Choice1.

Such a trace indicates that the point where the error occurred or the execution was aborted happened inside the body of Choice2, which was exercised from the body of Choice1, which was itself part of an API create-and-exercise command. The trailing (#x) indicates the index of the corresponding exercise node within the transaction that would have been generated if the interpretation had passed through.

Daml Finance 

Smart Contract Upgradeability (SCU): Daml Finance is now smart contract upgradeable by relying on Daml SDK 2.10.0 and Daml LF 1.17. As part of this change, each package incorporates its major version number (Vx) into its path, package name, and module name. Consequently, the major version for all Daml Finance packages has been incremented.

Context-Aware Semaphore Lock Release: A fix added to the Daml.Finance.Util package ensures that a holding protected by a semaphore lock will only be released if the lock's context matches the provided unlock context. This prevents inadvertent releases.

New AutoCallable Instrument: A new AutoCallable instrument has been introduced to the experimental Daml.Finance.Instrument.StructuredProduct package. This addition expands the set of available structured product instruments.

PQS

PQS now supports the highly sought after ability to use  package-name (specified in daml.yaml) in queries instead of the more cumbersome package-id, which is required to support smart contract upgrades. When specifying a template/interface/choice name, simply substitute any package-id with the package-name (eg. now "register:DA.Register:Token") instead of the old "deadbeefpackageidhex:DA.Register:Token" format. This applies to template filters and SQL queries (eg. via the active() function). These functions will always return all versions of a given identifier. Qualified name can be:

• fully qualified, e.g. <package-name>:<module-path>:<template-name>
• partially qualified, e.g. <module-path>:<template-name>

As shown, this change allows querying and configuring PQS by package-name instead of package-id.  This makes identically named templates/choices (by package-name:module:name) accessible in an integrated manner.  Note that package-id and package-version are now accessible via the Read API (eg. select * from active("my-package:Module:Template");   ). 

Note: PQS does not currently enforce "package-name:package-version" uniqueness for packages obtained from the ledger. These may be duplicated in Daml-LF versions 1.15 and earlier on the ledger.

The PQS Read API now returns the package-name, package-id, and package-version for each contract instance, making it easy for users to determine and inspect different versions over time. To reconstruct the old experience (should you need to) of querying one specific version, simply use a filter predicate in the SQL. eg. SELECT * FROM active('mypackage:My.App:MyTemplate') WHERE package_id = 'deadbeefpackageidhex'.

Several performance improvements in bulk operations were made.  This includes: initialization, startup, and pruning.

Additional metrics and logging to provide more feedback on operational aspects such as latency and long running operations.

There is a breaking change where the Read API now returns signatories and observers column, instead of witnesses. They are more useful than witnesses since they are not constrained to authorization of the Ledger API user in use. Therefore they are very useful for off-ledger read delegation.

Security and Bug Fixes

A queue of tasks was unbounded and could use a large amount of heap memory which could result in  an OutOfMemoryError.  This has been optimized.

A ledger fork and participant could crash due to a retroactive interface due to the view reinterpretation of an exercise of a retroactive interface failing.  This is fixed.

A participant replica fails to become active under certain database network conditions. The previously active replica fails to fully transition to passive due to blocked database connection health checks, which leaves the other replica to fail to transition to active. Eventually the database health checks get unblocked and the replica transitions to passive, but the other replica does not recover from the previous active transition failure, which leaves both replicas passive.  This has been resolved.

A participant replica could hang during initialization due to a race condition that is fixed.

A rare occurrence could happen that would result in a participant being unable to reconnect to a domain.  Contracts created on participants running PV=3 have an unauthenticated contract ID. When these participants are upgraded to PV=5 without setting the allow-for-unauthenticated-contract-ids flag to true, any submitted transaction that uses such unauthenticated contract IDs will produce warnings during validation, but also put the participants in an incorrect state. From then on, the participant will not output any ledger events any more and fail to reconnect to the domain.

Since 2.9.0, the Hard Synchronization Domain Migration command `repair.migrate_domain` aborts when it detects in-flight submissions on the participant. It now also includes a check for in-flight transactions.

LTS FAQs

Summary

First Daml Enterprise release to be designated a Long Term Support (LTS) release. An LTS release focuses on long term stability and may forgo feature enhancements. 

It is supported for multiple years and can be upgraded to with full data continuity, but it does have some caveats:

• Limited cross-version compatibility, specifically no guaranteed support for old Canton Protocol versions.
• No long-term support for deprecated features.
• Focuses on supporting LTS versions of environment components (java, dbs, etc).
• LTS releases are only guaranteed to have Critical or High issues fixed.  Lower priority fixes are possible but not mandatory.

Long term Support Q&A

What is the support duration for Daml 2.10 LTS? When is the End of Life support for 2.10, since it is our LTS release for the 2.x series?

The minor version support duration is 2 years for non-deprecated features. Deprecated features are not supported. The features remain within the LTS only for the purpose of upgrading. If bugs are exposed then application changes will be required. A 5 year support window is available as part of the ultra-premium (Build+) SKU but it requires written mutual agreement of the chosen version between customer and DA.

Will bug fixes and security patches continue to be released for non-LTS versions of Daml 2.x, and if so, for how long?

Daml 2.x is planned to only have the 2.10 LTS version; there are no plans to have another minor release (e.g., 2.11.0) so there is no plan to have a non-LTS release. The 2.10 LTS release will continue to get bug-, security-, and dependency fixes at least once a quarter. However, LTS releases are only guaranteed to have Critical or High issues fixed.  Lower priority fixes are possible but not mandatory and at the discretion of the Digital Asset product and engineering team. 

What specifically are the deprecated features which are no longer supported as of 2.10-LTS?

The 2.10 LTS release notes are the definitive source of information. A summary of the deprecated features no longer supported are:

• Canton Protocol Versions (PV) 5 and 7 are supported. Prior PV versions 3 and 4 were discontinued in release 2.9.1. The PV=6 was experimental and deleted.
• Daml-LF versions 1.14, 1.15, and 1.17 are available in this release.
• Intel-based MacIntosh binaries for development purposes are deprecated and provided on a best effort basis.
• Enabling the Smart Contract Upgrade feature has the following impact:
  • require that the daml.yaml files set the package version and that the version is increasing as new versions are developed.
  • a DAR being uploaded to a participant node has a unique package name and version.
  • The JSON API server requires either a package ID or package name to be present to disambiguate the partially-qualified form of template/interface ids.
  • Both LF 1.17 and PV=7 are required.  The PV change requires a domain migration
  • Retroactive interface instances are not supported.
  • Using divulged contracts during interpretation is deprecated since Daml 1.14, and does not work with upgrades.
  • Interface definitions are not upgradable by SCU. So, to allow upgrading of templates, move co-mingled interfaces into a different package that can be referenced by all current and future versions of the template.
  • Exception definitions are not upgradable by SCU. So, to allow upgrading of templates, move co-mingled exception definitions into a different package. 
  • Test scripts are not upgradable by the SCU. Move your tests to a separate dedicated package and make sure they are not uploaded to the ledger. 
  • Triggers are incompatible with the DAML-LF 1.17. As a consequence, you cannot use upgrading (available in 1.17) and triggers (available in 1.15) in combination.

• • Java binding functionality deprecated in 2.5 for command submission has been permanently removed.

• PQS has several changes:
  • PQS now supports using  package-name (specified in daml.yaml) in queries instead of the more cumbersome package-id,
  • The PQS Read API now returns the package-name, package-id, and package-version for each contract instance.
  • The Read API now returns signatories and observers column, instead of witnesses.

What is the recommended timeline for customers to migrate to 2.10 LTS?

Customers should migrate to 2.10 LTS by June 2025.

The policy that applies here is that:  “Within a Major version, security and bug fixes are applied to the latest Minor version as well as the second to latest Minor version release, the latter being limited to 6 months after its release or 3 months after the release of the latest Minor version, whichever is longer.”

The second to last Minor version release is 2.9.1 which debuted on July 17, 2024.  Applying the first minor criteria, 2.9.1 is six months past its debut date so that criteria means it is already unsupported. However, the second criteria means that 2.9.1 is unsupported 3 months after the debut of 2.10 LTS which would be June 2025.  Earlier releases than 2.9.1 are already considered unsupported.

Do I need to upgrade my smart contracts as well, if I upgrade to 2.10?

It depends on whether your 2.10 deployment will use PV=5 or PV=7. Note that the latter is required by the SCU feature.

If PV=5 are used then there is no need to migrate your existing contracts to a new domain (now called ‘synchronizer’).  However, if PV=7 is used then the protocol version change necessitates a synchronizer (formerly ‘domain’) migration.

Will there be a direct upgrade path from 2.10 LTS to V3.0 GA when it’s released? 

Yes, 2.10 is the last minor release ahead of the v3.x release and as such is the version to be on to prepare to take advantage of v3.x features and Canton Network's decentralized infrastructure.

Migration to v3.0 should be considered based on the use case you wish to deliver and with a view to taking advantage of the new capabilities enabled by the Global Synchronizer infrastructure of the Canton Network. Please discuss this in more detail with your representative.

Every major version change is expected to have architectural and language changes which require code changes.  There will be a migration document and guidance to highlight these changes in detail and support customers as they upgrade.

What is the minimum version customers need to be on to upgrade to 2.10 LTS? 

The Canton protocol version is important for this discussion. PVs 3 and 4 were removed in 2.9.1 since the Daml Enterprise releases they were part of are no longer supported.  The PV=5 can be used with LF 1.15 directly in 2.10 LTS.  Please see item 2. above if you want to use Smart Contract Upgrades.

Can I skip upgrading to 2.10, wait and upgrade from my existing version of 2.x straight to 3.x?

Please refer to the prior answers for particulars. Also, 2.10 LTS will be the only fully supported version as of June 2025.

Do I have to upgrade all components to the versions listed in the release notes, or can I run on older versions of these components with 2.10, particularly older versions of PQS?

In general you should always use the latest component versions that are listed in the “Download and Installation” notes of the Release Notes.  If you have a support request, it is expected that the support team will request that you upgrade any component to the version listed in the Release Notes.

Can I connect to the Canton Network/Global Synchronizer, if I upgrade my existing Canton nodes to 2.10?

You cannot directly connect a 2.x Canton participant node to the 3.x Canton Network / Global Synchronizer.  However, some customers who want to access the value of the Canton Network have built a bridge from their 2.x application to the Canton Network. Please discuss this in more detail with your CS representative to understand the best path for you.

If I am running multiple Canton nodes, which older 2.x versions is 2.10 backwards compatible with (because 2.10 is running on a higher protocol version)?

PV=5 is the lowest version that 2.10 LTS supports which overlaps with prior releases. If the SCU feature is enabled then there is no PV overlap.

What protocol versions are available in 2.10 and what does the upgrade path look like?

PV=5 is the lowest version that 2.10 LTS supports which overlaps with priori releases so if you are using a PV=5 then you can directly move to 2.10 LTS.  If you want to use the SCU feature then there is no PV overlap because PV=7 is required and a domain/synchronizer migration is needed.

How long will the backward compatibility with Canton Protocol Version 5 be maintained?

There is no plan to deprecate PV=5. In theory a bug could be found in PV=5 which could require a new protocol version, but this is not a current concern or consideration.

Where can I get initial documentation about V3.0 features and how to evaluate?

For early adopters of v3.x, there is documentation available today in preview and for the accelerators being built for the Global Synchronizer. Please ask your representative for more information. A new external site is being developed for v3.x to be published at GA. The documentation for new v3.x features will be incrementally added and updated and shared with all customers as soon as it is publicly available. 

How frequently will updates be released for 2.10 LTS compared to non-LTS versions?

If there are any bug-, security-, and dependency fixes there will be an LTS patch release at least once a quarter.

Download and Installation 

The Daml 2.10.0 SDK has been released. You can install it using the command: daml install 2.10.0.

The table below lists how you can download Daml Enterprise or individual components.

If you are using Oracle JVM and testing security provider signatures, note that the Canton JAR file embeds the Bouncy Castle provider as a dependency. To enable the JVM to verify the signature, put the bcprov JAR on the classpath before the Canton standalone JAR. For example:

java -cp bcprov-jdk15on-1.70.jar:canton-with-drivers-2.10.0-all.jar com.digitalasset.canton.CantonEnterpriseApp

Note: These Docker images are designed to be suitable for production use, with minimal size and attack surface. Minimal images can sometimes make debugging difficult (e.g. no shell in the containers). For convenience, we provide “debug” versions of each of the above images, which you can access by appending “-debug” to the image tag (e.g. digitalasset-docker.jfrog.io/http-json:2.10.0-debug).