canton v3.5.14

Release of Canton 3.5.14

Canton 3.5.14 has been released on August 19, 2026.

Summary

This is a maintenance release with improvements for CantonBFT.

What’s New

CantonBFT Improvements

• Added a configuration option to override the view change timeout that is set via a topology transaction (SequencingParameters)
• Improved the DB query that loads in-progress consensus state after a restart. Now, nodes only load minimum necessary messages for rehydration, rather than all messages from the most recent epoch.
• Add check in mempool that local batches created are not too big.
• Further fine tune what messages get loaded as part of rehydration
• Add options in the SequencingParameters to make the view change timeout be dynamic.

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.24 (Debian 14.24-1.pgdg13+2), PostgreSQL 15.19 (Debian 15.19-1.pgdg13+2), PostgreSQL 16.15 (Debian 16.15-1.pgdg13+2), PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2)

canton v3.5.13

Release of Canton 3.5.13

Canton 3.5.13 has been released on August 13, 2026.

Summary

This is a maintenance release with a number of improvements in particular for
CantonBFT and traffic enforcement app, as well as minor improvements in various
areas.

What’s New

Traffic Enforcement App Improvements

• Added reject-multi-party-submissions to the participant's traffic enforcement configuration.
  Multi-party submissions normally bypass traffic enforcement, since TEA accounts are bound to a
  single party. Setting this to true rejects them instead. Disabled by default.

  canton.participants.participant1.traffic-enforcement {
    enabled = true
    reject-multi-party-submissions = true
  }
  

• Added allow-submissions-on-degradation to the participant's traffic enforcement
  configuration. When the balance can't be determined, for example during a database outage, this
  lets the submission proceed unchecked instead of failing it, logged at WARN. The submission is
  still charged, so an account without enough traffic ends up with a negative balance until it is
  topped up. Does not apply when the traffic service itself refuses the request. Disabled by
  default.

• Added database-query-timeout (default 1 second) and account-lookup-timeout (default 20
  seconds) to the internal traffic enforcement server's configuration, bounding the database read
  behind GetAccount and the overall call respectively. The former must be at least one
  millisecond and the latter must be strictly larger so a timed-out query still leaves room for a retry.

  canton.participants.participant1.traffic-enforcement {
    enabled = true
    allow-submissions-on-degradation = true
    traffic-enforcement-server {
      database-query-timeout = "1s"
      account-lookup-timeout = "20s"
    }
  }
  

CantonBFT Improvements

• CantonBFT now deletes unnecessary messages from previous views to prevent excessive memory usage during view changes.
• CantonBFT limits standalone mode to non-standard config enabled
• Fixed relative segment latency metric
• CantonBFT now logs more information about the view change process, including the reason for the view change and the new leader.
• Logs about backpressure and P2P that didn't provide useful information for operators have been removed
  or have seen their threshold lowered to DEBUG; other log messages have been improved.
• The current epoch graph in the "BFT ordering" dashboard is now a time series rather than a mere stat.
• Batch fetching: a node that is contributing to consensus but doesn't receive a batch will try to fetch it
  from other nodes, but previously it would only consider nodes that signed an acknowledgement for the batch.
  Now it will also consider nodes that didn't, as they could have retrieved the batch from other nodes earlier
  and be able to provide it.
  This improves dissemination success chances, and thus overall ordering latency, for nodes that experience connectivity
  issues.
• Fixed a deserialization issue with retransmission request
• Remove a deprecated gRPC header previously used internally for P2P authentication
• Start fetching batches earlier, before consensus starts on the block.
• Add metric for which node we are missing batches and need to fetch
• Retrieval of batches will be attempted by multiple nodes in parallel, by default 3 (configurable)
• CantonBFT's P2P server-side now has configurable keepalive settings and defaults have been made more robust
  against network infrastructure that may drop idle connections, leaving them in a zombie state.
• Fixed a view change nested timeout cancellation issue when receiving a commit certificate
  during a view change.

Improved Sequencer Logging

On the sequencer, the log line mentioning all events in a block now also can contain the outcome of the event.
By setting canton.sequencers.sequencer.parameters.enable-async-sequencer-logging = true, the logging will be
moved to the end of the block processing, but will include the outcome of the events in the block. The default
remains false to preserve the current behavior.
Note that as part of this change, the sequencer-id of the traffic control metrics and of the block event processor
metrics dropped the superfluous leading "SEQ::" string.

Detailed Participant to Sequencer Connect Logging

More debug logging has been added to the participant connecting to a sequencer in order to debug a race condition
in which connecting appears to hang at times.

Minor Improvements

• Fixed deserialization failure in AcsCommitmentCatchUpConfig
• Fixed an issue with authenticationServiceChannel to ensure it closes properly during shutdown.
• gRPC servers can now configure manual gRPC flow control window size; also, both gRPC servers and clients can
  now configure automatic gRPC flow control initial window size.
  The default is unchanged, i.e., for servers neither is set unless configured, so that the implementation default
  applies, and for clients manual flow control is enabled by default with a window size of 1 MB.
  Only CantonBFT's default has changed: implementation defaults are used also on the client side.
• LSU: On participant nodes, only expose LSU status of recent LSUs (instead of old past LSUs).

Bugfixes

• Improved engine handing of UnsupportedContractIdVersion: disclosure from a future version of Canton could cause the engine to crash
  and fail submissions with an internal error. A UnsupportedContractId interpretation error is now returned instead.
• Preserve traceparent information for traces with tracestate information.
  When serializing a trace in W3C format, the traceparent information was not
  preserved which has been fixed. However, a limitation still exists whereby
  CantonBFT discards the tracestate information, which will be fixed in a
  future release.

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1), PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1), PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1)

canton v3.5.12

Release of Canton 3.5.12

Canton 3.5.12 has been released on August 07, 2026.

Summary

This is a maintenance release that ships improvements for CantonBFT and the
traffic enforcement app, as well as improving the mitigation for a critical fix
shipped with 3.4.11.

What’s New

Traffic Enforcement App

• This release reworks and improves the way local traffic accounts on the participant are updated.
  In particular the par_traffic_enforcement_event is dropped and re-created from scratch. Events were never exposed through the API
  so this will only affect users who have been accessing the database directly.
  Importantly, the traffic balances are not affected by this change and account balance continuity is preserved, and the API for querying traffic balances remains unchanged.
• Various bug fixes in the in-memory implementation of the traffic accounting

CantonBFT Improvements

• Upon completing the locally-led segment in an epoch, CantonBFT nodes now dynamically increase the rate of retransmission requests to decrease the time it takes to retrieve any missing messages from other peers' segments.
• Added a new metric relative-segment-latency that records the rate and latency it takes to complete a segment after the segment led by this node completed.
• Lower log level of dissemination: some batch dissemination logs in CantonBFT were logged at WARN level, which is too high because they don't imply abnormal conditions nor non-compliant behavior. This change lowers their log level to INFO.

Bugfixes

(26-005, Critical): LSU: Cancelled LSU leftover state prevents PN startup after a successful LSU

A mitigation of this bug has already been shipped in 3.4.11, this patch release
improves the early fix.

Issue Description

Cancelled LSU left stale state that combined with a subsequent successful LSU state would prevent a participant node from starting up due to it erroneously recognizing the state mixture as an incomplete LSU and failing to complete it.

Affected Deployments

Participant nodes

Affected Versions

All versions before 3.5.11

Impact

Participants will not start up if restarted for any reason

Symptom

Participant node does not start with a log message: Attempting to run Startup participant node failed with Unable to finish upgrade ...

Workaround

Do not restart a PN before upgrading to a non-affected version. For the cancelled DevNet LSU to the physical synchronizer id ::35-4 the issue could be mitigated by running a database query:

update par_synchronizer_connection_configs
set
  status = 'I'
where
  physical_synchronizer_id = 'global-domain::1220be58c29e65de40bf273be1dc2b266d43a9a002ea5b18955aeef7aac881bb471a::35-4';

Likeliness

The issue happens on a restart of the participant node, regardless of the restart cause, including normal operational procedures.

Recommendation

Upgrade to 3.5.11

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1), PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1), PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1)

canton v3.5.11

Release of Canton 3.5.11

Canton 3.5.11 has been released on July 30, 2026.

Summary

This is a maintenance release that fixes a bug in participants for LSU and provides minor operational improvements.

What’s New

Minor Improvements

• Improved the resilience of the CachedJwtVerifierLoader JWK cache during temporary JWKS endpoint outages.
  Set the jwks-cache-config.auto-refresh-after configuration to a positive duration below jwks-cache-config.cache-expiration
  on any participant, sequencer, and mediator node admin-api, participant node ledger-api, and sequencer node public-api
  to reduce the chances of cache misses and corresponding auth outages.
• Bumped the version of AWS SDK from 2.44.3 to 2.49.3 to fix a security vulnerability with netty.
• Added index that improves performance of block sequencer pruning.

Bugfixes

Participant node restart failure after a canceled LSU followed by a successful LSU

A Participant node would not start up with a failure log "Attempting to run Startup participant node failed with Unable to finish upgrade ..."
following a restart. This can happen after a successful LSU following an earlier canceled LSU.
The bugfix allows a participant node to start up successfully in this scenario.

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1), PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1), PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1)

canton v2.10.6

Release of Canton 2.10.6

Canton 2.10.6 has been released on August 12, 2026. You can download the Daml Open Source edition from the Daml Connect Github Release Section. The Enterprise edition is available on Artifactory.
Please also consult the full documentation of this release.

Summary

This maintenance release addresses performance limitations during hard domain migrations for participants with a large Active Contract Set (ACS).

What’s New

Domain Migration Performance Improvement

The "reconnect" step of hard domain migration has been optimized to replay ACS changes
into the ACSCommitmentProcessor much faster for Canton deployments using PostgreSQL databased backend.
In order to enable the faster alternative database query, use this new configuration option:

canton.participants.<participant>.parameters.use-alternative-changes-between-query = true

Together with the new index on the active_contracts table, this significantly speeds up the initial domain reconnection following a hard domain migration.
This change requires a database migration to be applied to the nodes when upgrading to this Canton version.
Index creation is expected to take roughly a couple of seconds per 1 million records in the active_contracts table.

The previous behavior can be restored by setting the configuration option to false.

Minor Improvements

• Upgraded gRPC to 1.81.0 and AWS SDK to 2.49.4 to resolve Netty security issues

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	5, 7

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM Zulu11.72+19-CA (build 11.0.23+9-LTS, mixed mode)
Postgres	Recommended: PostgreSQL 12.22 (Debian 12.22-1.pgdg120+1) – Also tested: PostgreSQL 11.16 (Debian 11.16-1.pgdg90+1), PostgreSQL 13.23 (Debian 13.23-1.pgdg13+1), PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1)
Oracle	19.20.0

canton v3.5.10

Release of Canton 3.5.10

Canton 3.5.10 has been released on July 23, 2026.

Summary

This is a maintenance release that brings UX and hardening improvements.

What’s New

Minor Improvements

• Fixed an edge case that could cause deserialization of proto durations to fail
• Fixed an issue where topology transactions with max serial where not handled properly
• Ledger JSON API /v2/state/active-contracts-page is now available via POST; the GET variant that expects a request body is deprecated.
• Bump Flyway dependency to 12.0.2 to enable Postgres 18 support

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1), PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1), PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1)

canton v3.5.9

Release of Canton 3.5.9

Canton 3.5.9 has been released on July 16, 2026.

Summary

This is a maintenance release that brings few minor improvements.

What’s New

Minor Improvements

• Improved and relaxed DB locking-scheme to avoid colliding with pg_dump execution. Also introduced better visibility for lock contention by emitting INDEX_DB_LOCK_TIMEOUT_ERROR in ERROR logs.
• Switch from TRUNCATE queries to VACUUM + opportunistic REINDEX DB queries. This approach is using lower level DB locks less likely to collide with external processes.
• Increase default network timeout for Indexer Database calls from 20 seconds to 40 seconds (canton.participants.<participant_name>.parameters.ledger-api-server-parameters.indexer.postgres-data-source.network-timeout) to provide more tolerance for indexing big transactions.
• Report indexer as unhealthy after crash until at least one uncommitted update from before crash was processed or there are no uncommitted updates from before the crash. This puts a participant in unhealthy status if indexer enters crash loop due to problematic update in the queue.
• An internal change is introduced which grants ReadAsAnyParty permissions to the traffic enforcement service. This removes the need to use non-standard config options to run local traffic enforcement with auth enabled:

  canton.participants.<participant_name>.ledger-api.admin-token-config.act-as-any-party-claim=true
  canton.participants.parameters.non-standard-config=true
  

• The participant admin party is now exempt from the traffic enforcement balance check during submission.

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1), PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1)

canton v3.5.8

Release of Canton 3.5.8

Canton 3.5.8 has been released on July 09, 2026.

Summary

This is a maintenance release that brings several operational improvements.

What’s New

Improvements to TopologyManagerReadService and TopologyAggregationService

• The services return the error TOPOLOGY_STORE_NOT_INITIALIZED in case the the topology store hasn't been initialized yet.
  This can happen in two cases:
  • When onboarding to a synchronizer, before the download and the processing of the initial topology state has completed,
  • During a logical synchronizer upgrade, before the the successor store has been initialized either through the local topology copy or the download of the topology state from the successor sequencers.
• The services return the error TOPOLOGY_STORE_NOT_FOUND when requesting topology data for a synchronizer that is not known to the node.
• The services now only return data for all active synchronizers when no synchronizers are specified in the request.
  Previously, data for all synchronizers was returned, including the inactive predecessor synchronizers after an LSU.

Improvements to database connection error reporting

If a database call takes more time than the configured postgres_data_source.network_timeout a new, more specific INDEX_DB_SQL_NETWORK_TIMEOUT_ERROR will be logged. This replaces the previously raised INDEX_DB_SQL_NON_TRANSIENT_ERROR.

Minor Improvements

• Improved log trace correlation in the JSON Ledger API: package and health endpoints that previously logged with an empty trace context now propagate the caller's TraceContext.
• The JSON Ledger API endpoint GET /v2/interactive-submission/preferred-package-version is now marked as deprecated in the OpenAPI specification as well (previoulsy it was marked as deprecated only in the textual description). Use POST /v2/interactive-submission/preferred-packages instead. The endpoint remains functional and will be removed in Canton 3.6.

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1), PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1)

canton v3.5.7

Release of Canton 3.5.7

Canton 3.5.7 has been released on July 01, 2026.

Summary

This release provides a new Ledger API endpoint to obtain command completions and fixes a number of minor issues.

What’s New

New GetCompletions endpoint on the command completion service

Background

The command completion service only offered CompletionStream, which always filters by a single user and a non-empty set of parties. There was no way to stream completions across all parties.

Specific Changes

A new completion streaming endpoint is introduced: GetCompletions (gRPC) or /commands/command-completions (JSON API). This endpoint offers more flexible filtering semantics compared to the existing CompletionStream, /commands/completions endpoint. It filters by parties only; there is no user filtering:

• A non-empty parties filters to those parties and requires ReadAs (or ActAs) for each.
• An empty parties returns completions for all parties and requires ReadAsAnyParty (or ActAsAnyParty).

In all other respects it behaves like CompletionStream, which becomes deprecated.

Impact and Migration

This is an additive change. CompletionStream is unchanged, so no migration is required.

Participant Local Traffic Accounting

Note: This is a beta feature.

Background

Participants must pay for traffic on the synchronizer for every message they send, including confirmation requests for daml transactions.
This cost is largely triggered by submissions from the Ledger API and currently cannot be easily attributed to the submitting parties.

Specific Changes

This release introduces a feature tracking the traffic spent by the participant on behalf of submitting parties for the execution of daml transactions.
An account is implicitly tied to each submitting party and is debited for the traffic cost of their submissions.
The cost deducted on the account is the one already available on the completion response.

Note that only submissions with a single actAs party are accounted for. This includes local parties.

When the traffic accounting feature is enabled, a new service is available on the Ledger API to

• query the current account balance for a given party (requires ExecuteAs rights on the party)
• add traffic to an account (requires Admin rights on the participant)

This feature is disabled by default and can be enabled by setting the canton.participants.<participant_name>.traffic-enforcement.enabled = true configuration option to true.
When disabled, the TrafficService will not be exposed to the Ledger API, no accounting will be performed and no enforcement will be done on submissions.

When the feature is enabled, accounting is performed but enforcement is disabled by default.
To enable traffic enforcement, set canton.participants.<participant_name>.traffic-enforcement.enforce-cost-on-submissions = true.
When enforcement is enabled, on submission, the participant will check if the submitting account has enough traffic to pay for the submission. If not, the submission will be rejected.

Note that it is possible for account balance to be negative, even with enforcement enabled, if concurrent submissions are made from the same submitting party.

Impact and Migration

This change requires a database migration. The migration is additive only, but will be performed regardless of whether the feature is enabled or not.

Minor Improvements

• Added latency metrics for KMS signing and decryption operations.
• Fixed a BFT ordering sequencer crash-recovery issue affecting freshly onboarded nodes which could leave them stuck.
• LSU: improved handshake between a sequencer and its successor: the physical synchronizer id and sequencer id are now validated.
• The JSON Ledger API now rejects malformed identifiers (e.g. template-id) provided in requests (one that does not follow the <package>:<moduleName>:<entityName> format) with a descriptive 400 Bad Request error that names the expected format, instead of surfacing it as an internal error.

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1), PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1)

canton v3.5.6

Release of Canton 3.5.6

Canton 3.5.6 has been released on June 24, 2026.

Summary

This is a maintenance release that fixes an exceptional severe bug around logical synchronizer upgrades and brings a few improvements.

What’s New

Minor Improvements

• Connection pool metrics:
  • Add a psid label, populated if it is provided when connecting. This should be the case starting from the second connection to a synchronizer, or upon LSU.
  • Close the connection-health and subscription-health metrics associated to the psid when the pool is closed, instead of closing all the existing ones when the pool is started.
• Updated com.google.protobuf libs from 3.25.5 --> 3.25.9
• LSU: A call to AcknowledgeSigned with a timestamp before the upgrade time returns immediately, without any acknowledgement being done.
• Fix JDBC query for computing last activations: Under adverse conditions (data corruption) this query might called with empty inputs where it would have failed execution with PostgreSQL server version 14.
• (Potentially) BREAKING: Aggregatable submissions are now rejected eagerly to preserve bandwidth.
  This means that the submission error code SEQUENCER_AGGREGATE_SUBMISSION_ALREADY_SENT may now also
  be returned during the synchronous submission of the sequencer, as the state of the aggregation is also
  checked before ordering. In addition, the gRPC error code has been modified from FAILED_PRECONDITION to
  ALREADY_EXISTS to better reflect the nature of the error. Clients should be updated to handle this error
  code accordingly. Due to backwards compatibility, the old gRPC error code will be returned for PV35 and
  before on the async path, and the new capability must only be turned on when all nodes have been
  upgraded to a Canton version that supports this change. The new capability can be enabled using canton.sequencers.seq.parameters.enable-reject-delivered-aggregations-on-pv-35 = MED
  for mediators. This can be combined with the new configuration option of the mediator canton.mediators.mymediator.parameters.delayed-verdict-sender.enabled = true.
  Generally, the sequencer will send out the verdict after reaching the threshold. All subsequent sent verdicts are thrown away. The new option now allows threshold + extra verdicts to be sent immediately, while the rest of the mediators will wait a short amount of time. This allows to reduce the load on the sequencer by 30%, creating more capacity for other transactions.
• Fixed an issue that prevent external parties from being allocated on a participant with an offline root key via the Ledger API's PartyManagementService.AllocateExternalParty endpoint.
• Fixed an issue whereby the sequencer would no longer make progress after a failed write. Sequencers in such a state now report 'liveness' unhealthy.
• Require Participant Admin (not just IDP Admin) permissions in order to be able to grant CanReadAsAnyParty and CanExecuteAsAnyParty rights to users.

Bugfixes

(26-004, High): LSU: Missing synchronization between topology local copy and purging

Issue Description

Because of the lack of synchronization, it can happen that topology purging kicks in before the local copy of the topology state is finished, which result in incorrect topology state for the successor.

The issue can occur only when topology purging is enabled, which is not the case by default.

Affected Deployments

Participant nodes

Affected Versions

All versions before 3.5.6

Impact

Topology fork

Symptom

• Participant nodes issues warning/errors about missing topology transactions that were valid before the LSU.
• Submission of a transaction is rejected because of missing topology transactions that were valid before the LSU.

Workaround

Restore from backup and ensure topology purging is disabled

Likeliness

Exceptional

Recommendation

Upgrade to 3.5.6

Compatibility

The following Canton protocol versions are supported:

Dependency	Version
Canton protocol versions	34, 35

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM (build 21.0.12+2-nixos, mixed mode, sharing)
Postgres	Recommended: PostgreSQL 17.10 (Debian 17.10-1.pgdg13+1) – Also tested: PostgreSQL 14.23 (Debian 14.23-1.pgdg13+1), PostgreSQL 15.18 (Debian 15.18-1.pgdg13+1), PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1)