Participant & Keys

Two read-only tabs that expose what the Canton participant node itself reports: Participant node health, synchronizer connections, identity, and keys.

Participant

The deepest health view in the UI. When something is wrong at the Canton level rather than the Kubernetes level, this is the tab that tells you. The heading carries the participant Version beside it.

While initialising

If the node has not finished initialising, the tab shows only:

• Initialized — false

• Active — Yes / No

• Waiting for — what the node is blocked on

Waiting for is the single most useful field during onboarding. A participant that sits here for a long time is usually waiting on the synchronizer or on network onboarding to complete, not failing.

Once initialised

Card	Meaning
Active	Whether this is the active instance
Uptime	Live-ticking, formatted 1d 2h 3m 4s
Connected Synchronizers	One row per synchronizer, with its ID (copyable) and health. This is where a lost synchronizer connection shows up first.
Topology Queues	The depth of the Manager, Dispatcher, and Clients queues. Sustained non-zero values mean topology changes are backing up.
Identity	The participant's UID, its Endpoint, and the Protocol Versions it supports.
Ports	The ports the node exposes.
Components	The participant's internal health components, each with a status and description. Component names are truncated after the :: separator, with the full name in the tooltip.

Health values

The status values are Canton's own, colour-coded by the UI:

Value	Reading
ok, healthy	Healthy
degraded	Degraded
failed, fatal, unhealthy	Failed
anything else	Unknown

States

Situation	What you see
Loading	Loading participant status…
No status	No participant data — The participant has not reported status yet.
Request failed	Failed to load participant status, with the error

This tab is entirely read-only. There is no restart, reconnect-synchronizer, or pruning action. For participant-level administration, use the Canton console.

---

Keys

The public keys held in the participant's key vault.

Column	Contents
Name	The key's name, or —
Purpose	signing or encryption
Key Spec	The cryptographic algorithm and curve
Usage	One badge per declared usage
Format	The key's encoding

What this tab tells you

It is the quickest way to confirm that KMS integration is working. With a KMS configured, the participant's operational keys are created and held in the key vault rather than in the participant database — and they appear here either way, so use the Key Spec and your KMS provider's own console to confirm where the private material actually lives.

States

Situation	What you see
No keys	No keys — The participant vault returned no public keys.
Request failed	Failed to load keys, with the error

Read-only. Key generation, rotation, import, and export are not exposed in the UI — they are participant and KMS operations. See Key Management Service (KMS).