Decentralized Party and Canton topology
What a Decentralized Party is
A Decentralized Party is one Canton party identity whose ownership and hosting span multiple participant nodes. The party identity can remain stable while approved topology changes update its owners, hosting participants, permissions, or signing policy.
Three identities to keep separate
Canton participant identity: identifies the Canton participant operated by an organization.
Canton party identity: identifies the party used by applications and Daml contracts.
Decentralization Manager peer identity: identifies the application instance to other peers through its Noise public key.
Changing a peer identity does not automatically change Canton topology. Changing Canton topology does not automatically update peer records.
Decentralized namespace
The party’s namespace is controlled by an approved owner set under a configured signing policy. The namespace definition establishes who can authorize topology changes for identifiers under that namespace.
The policy is configurable. Do not rely on a threshold copied from another deployment.
PartyToParticipant mapping
The PartyToParticipant topology mapping defines which participants host the party and the permissions associated with that hosting relationship. This mapping allows the same party to operate across independent participants.
Key categories
Namespace signing key
Authorize namespace topology
Canton participant key store
Daml signing key
Authorize party actions on Canton
Canton participant key store
Noise key
Authenticate Decentralization Manager peer communication
Decentralization Manager persistent data
Operator login credential
Authenticate a person to the application
Identity provider and browser session
These keys are not interchangeable. Do not export a Canton private key to fix a Decentralization Manager peer problem.
Creation sequence
Operators agree on the intended participant and owner set.
Nodes establish peer connectivity.
Each participant generates required local keys.
The coordinator assembles topology proposals.
Owners authorize the decentralized namespace definition.
The approved definition is submitted and propagated.
Owners authorize PartyToParticipant mappings.
The mappings are submitted and verified across nodes.
Membership change
Adding or removing a participant requires a new topology state with the correct serial and owner authorization. The application must distinguish:
Namespace owners.
Hosting participants.
Daml governance members.
Decentralization Manager peers.
A change in one set does not guarantee that the others change automatically.
Parties with active contracts
A participant joining an existing party may need access to active contract state under the replication or Active Contract Set onboarding process supported by the current release. Topology membership alone may not make historical or active application state available.
Propagation and verification
After submission, wait for the reviewed propagation condition. Then read authoritative topology from every relevant participant or store. Do not treat a successful submission response as proof that all nodes can use the party.
Common failure modes
Wrong topology store or synchronizer.
Stale serial number.
Missing owner authorization.
Incorrect participant identifier.
Key generated on the wrong participant.
Peer connectivity failure during coordination.
Mapping visible on one node but not yet propagated to another.
Technical sources
Next step
👉 Plan controlled changes: Decentralization Manager membership and governance changes.
Last updated