> ## Documentation Index
> Fetch the complete documentation index at: https://docs.canton.network/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> If you are building a Canton Network application, start from https://docs.canton.network/appdev/quickstart.md. To run only a local network for your own Daml code, without building the QuickStart demo, see https://docs.canton.network/sdks-tools/development-tools/localnet.md.

# 3.7.3

> Canton 3.7.3 release notes.

# 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](#traffic-enforcement-app-traffic-top-ups-through-a-daml-interface-experimental)
in the traffic enforcement app and the alpha [Hybrid Party Replication (HyPR)](#remote-read-of-a-partys-acs-alpha).
Its [breaking changes](#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`:

```
top-up {
  type = daml-credit
  paymasters = ["paymaster::1220..."]
  // optional, defaults to the participant's pruning offset
  initial-offset-begin-exclusive = 42
}
```

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:

| Dependency | Version |
| - | - |
| Canton protocol versions | 36, 37 |

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.11 (Debian 17.11-1.pgdg13+2) – 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 17.11 (Debian 17.11-1.pgdg13+2), PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2) |