Skip to main content

​
Release of Canton 3.7.3

Canton 3.7.3 has been released on November 12, 2026.

​
Summary

This is a maintenance release that fixes a resource leak on sequencer nodes and makes party replication safer. It also improves the experimental traffic top-ups through the ledger in the traffic enforcement app and the alpha Hybrid Party Replication (HyPR). Its breaking changes affect party replication and the monitoring of CantonBFT P2P connections.

​
What’s New

​
Participant node operators

​
Traffic enforcement app: traffic top-ups through a Daml interface (experimental)

The traffic enforcement app (TEA) credits traffic top-ups that applications selling traffic (e.g. wallet providers) publish on the ledger through a new Daml interface. It replaces the TrafficPurchaser contracts of 3.7.0 to 3.7.2: TEA no longer credits exercises of TrafficPurchaser_PurchaseCredits. Before upgrading, switch the applications that sell traffic to templates implementing TrafficCreditReporter. Traffic top-ups through the ledger remain experimental: the Daml interface and the configuration may still change in a later release. The new Daml package canton-api-traffic-credit-v1 defines the TrafficCreditReporter interface. Its PublishCredit choice credits trafficAmount bytes to a TEA accountId and must be exercised with the authority of the paymaster in the interface view. TEA only ingests credits whose paymaster is one of its configured paymasters. The choice’s observers argument can notify additional parties of the credit without granting them authority to publish credits. Implementing templates supply trafficCreditReporter_publishCreditImpl, which must validate account ids and positive traffic amounts. Validation can evolve with the implementation without changing the interface package. The DAR canton-api-traffic-credit-v1-1.0.0.dar is shipped in the dars directory of the release bundle, so applications can depend on it. Top-up ingestion is enabled in the new block canton.participants.<participant>.traffic-accounting.traffic-enforcement-server.top-up:
The default is type = disabled. paymasters must not be empty, and the parties must be hosted on the participant. This block replaces the settings projection.top-up-paymasters and projection.initial-top-up-offset-begin-exclusive of 3.7.0 to 3.7.2, which are removed. Move them to the new block before upgrading, as the participant does not start with them. Once an ingestion offset has been persisted, it takes precedence over initial-offset-begin-exclusive. Changing that setting does not reprocess transactions at or before the persisted offset. With Daml top-ups enabled, the participant uploads the canton-api-traffic-credit-v1 DAR before starting TEA and vets it on every synchronizer it connects to, as long as canton.participants.<participant>.parameters.admin-workflow.auto-load-dar is enabled (the default). This setting also controls the other admin-workflow DARs. To manage these DARs manually, disable it and upload and vet the traffic credit DAR and the other required admin-workflow DARs. If the traffic credit DAR is missing while automatic loading is disabled, the participant logs a warning. A PublishCredit exercise whose arguments or acting parties do not match what TEA expects is not credited and is reported with the error code TRAFFIC_TOP_UP_NOT_CREDITED, which carries the update_id and offset of the credit.

​
Remote read of a party’s ACS (alpha)

These endpoints are part of Hybrid Party Replication (HyPR), which is in alpha. The new endpoint PartyManagementService.GetRemoteAcs (console: parties.get_remote_acs) lets a participant that is authorized to host a party read that party’s ACS from another participant through a sequencer channel. For now, exactly one party must be given. The new endpoint PartyManagementService.GetPartyFreezingTime (console: parties.get_party_freezing_time) returns the timestamp to pass as asOf to get_remote_acs. Remote read is disabled by default. It requires the alpha-acs-replication-support configuration on the source and target participants, and the alpha-sequencer-channel-support configuration on at least one sequencer node of the synchronizer.

​
Party ACS import for a Freezing participant (alpha)

For HyPR, PartyManagementService.ImportPartyAcs (console: parties.import_party_acs) with a party_id also accepts the import if the participant is Freezing for the party. The import then requires the contract import mode Validation. Once connected to the synchronizer again, the participant moves its entry for the party from Freezing to Onboarding, and then from Onboarding to Active once that is safe, as after an import for an Onboarding participant.

​
Breaking changes

​
Participant node operators

​
Confirmation threshold check counts only confirming hosts

This change improves safety: it prevents a hosting change that leaves a party unable to confirm requests. A party-to-participant change is rejected with TOPOLOGY_CONFIRMING_THRESHOLD_CANNOT_BE_REACHED if it leaves fewer hosts with Submission or Confirmation permission than the party’s confirmation threshold, unless the force flag FORCE_FLAG_ALLOW_CONFIRMING_THRESHOLD_CANNOT_BE_MET is set. Since 3.4.4, the check also counted hosts with Observation permission, which never confirm. For example, a host could downgrade itself to Observation without the force flag, and every request that needed the party’s confirmation then timed out until the party lowered its threshold. To downgrade a host, lower the threshold first, or in the same change. A party without hosts with Submission or Confirmation permission, and the removal of a party’s mapping, are not checked.

​
Party ACS import rejected after the party’s activation

This change improves safety: it prevents an ACS import that would leave the party with a wrong set of active contracts. PartyManagementService.ImportPartyAcs (console: parties.import_party_acs) with a party_id now rejects the import with PARTY_ACS_IMPORT_AFTER_ACTIVATION once the target participant has processed events past the party’s activation. This happens if the target participant stays connected while the party authorizes the hosting. Since the activation, the target participant may have processed archivals or unassignments of contracts in the snapshot. In earlier versions, the import then failed midway, or made archived contracts active again if their archivals had been removed. Disconnect the target participant before the party authorizes the hosting, as the offline party replication steps require. If it has already processed the activation, restore it from a backup taken before the activation and import again. The force flag IMPORT_PARTY_ACS_FORCE_FLAG_ALLOW_IMPORT_AFTER_ACTIVATION in the new field force_flags (console: forceFlags = Set(ImportPartyAcsForceFlag.AllowImportAfterActivation)) skips the check. Set it only if no contract in the snapshot has been archived or unassigned since the activation.

​
Synchronizer operators

​
CantonBFT: P2P endpoint metric label renamed

The label endpoint is renamed to p2p-endpoint (p2p_endpoint in Prometheus) on the metrics daml.sequencer.bftordering.p2p.endpoint-status and daml.sequencer.bftordering.security.noncompliant.behavior. The metric names are unchanged. On Kubernetes, the label endpoint identifies the scrape endpoint of the metrics collector, so the collector renamed the label of these metrics to exported_endpoint. The CantonBFT dashboards, which use the label, did not work there. The new label keeps its name on every deployment. Update dashboards and alerts that filter or group these metrics by endpoint or exported_endpoint. Until all sequencer nodes are upgraded, the metrics carry the old label on nodes that run an earlier version.

​
Minor Improvements

  • The Request-Timeout header of JSON Ledger API requests now also accepts a time unit, for example 15s. Values without a time unit are still interpreted as milliseconds.

​
Bug Fixes

  • Sequencer node: fixed another resource leak that increased CPU and memory usage after a few days of running.
  • Party replication: the party ACS import and the onboarding flag clearance now only consider the party’s own party-to-participant mapping. They no longer read the mapping of another party of the same namespace, such as a party whose identifier starts with the party’s identifier (e.g. party-10 for party-1). In earlier versions, the target participant could clear the party’s onboarding flag before all requests in flight at the party’s onboarding were decided, leave the flag set, or clear the other party’s flag too early, and online party replication could check the wrong mapping. If the target knows no onboarding mapping of the imported party itself, the import now fails with PARTY_ACS_IMPORT_MISSING_ONBOARDING_MAPPING.
  • Offline party replication: the automatic onboarding flag clearance no longer stalls when the first time the target participant observes is the safe time itself, or when its clearance is rejected because another change of the party’s hosting took effect first (e.g. with two targets onboarding the party in parallel). In earlier versions, the flag stayed set until a reconnect, a restart or a manual clear_party_onboarding_flag. It also no longer logs warnings while it waits for an announced synchronizer upgrade or for its clearance to take effect.
  • clear_party_onboarding_flag no longer leaves a pending onboarding clearance behind when called after the flag is cleared, as the documented polling does. In earlier versions, a later ACS import of the party (e.g. after offboarding it and onboarding it again) failed with INVALID_STATE_PARTY_MANAGEMENT_ERROR (ConflictingPendingOperationError), and each reconnect ran a needless clearance attempt. Records left behind by earlier versions are deleted on the next reconnect, or when the participant stops hosting the party.

​
Compatibility

The following Canton protocol versions are supported: Canton has been tested against the following versions of its dependencies: