Canton External Signing

Overview

In Canton a party's on-ledger state is managed by one or more validators. The key question is who holds the party's authorizing private key:

• Internal party — the validator's key authorizes transactions; the user authenticates with a JWT on the Ledger API. Simplest operationally, but you trust the validator not to misuse the key.
• External party — the user holds the key (end-user wallet or backend) and signs transactions themselves. More control, wallet-like; required when you don't want the validator able to act unilaterally.

Topology: how a party is configured

A party's setup is defined by topology transactions, signed by the affected parties/validators and submitted to the ledger; together they form the topology state (parties, keys, validators, packages). The central one is the party-to-participant mapping (the hosting relationship), which declares the party's authorizing key and the validators that host it with permissions:

• Submission — validator's key authorizes transactions → internal party.
• Confirmation — validator only confirms → external party (party key authorizes).
• Observation — validator is informed/validates but doesn't confirm.

So: grant Submission → internal; grant Confirmation/Observation (and define the party's key in the mapping) → external.

Multi-hosted parties

To avoid fully trusting one validator, a party can be hosted by multiple validators with a confirmation threshold (N-of-M must approve before a transaction is valid) — improving security and availability. Single-hosted is simplest (full trust in one validator). The mapping defines the validator set, permissions, threshold, and any namespace delegations needed to verify topology signatures.