Create a Decentralized Party

Decentralization Manager overview · Connect Decentralization Manager peers

Outcome

Coordinate participating nodes to create a Decentralized Party, then verify its namespace and hosting-participant topology on Canton.

Before you start

• Every participating node runs an approved compatible release.
• Peer records are exchanged and connectivity is healthy in both directions.
• Each node can reach its Canton Admin API with the required topology and key permissions.
• The target synchronizer and Canton environment are agreed.
• The initial participants, owners, and approval policy are approved by the organizations involved.
• No conflicting onboarding workflow is active on a participating node.

A Decentralized Party is a shared Canton identity. Treat its initial owners and approval policy as a governed production decision, not a demo default.

1. Plan the party

Record:

• Human-readable party purpose.
• Party identifier prefix.
• Participating organizations and nodes.
• Initial owner set.
• Approval threshold or policy.
• Target Canton environment and synchronizer.
• Workflow coordinator for this run.
• Evidence and review required before activation.

2. Start onboarding

From the coordinator node, open the party-creation workflow and select the intended peers. Enter the approved party prefix and approval policy.

Review the invitation list before starting. A missing or unintended peer changes the resulting ownership model.

3. Peers review invitations

Each peer should verify:

• Coordinator identity.
• Party purpose and environment.
• Participant list.
• Proposed approval policy.
• Expected Canton participant and member party.

Peers accept only after the information matches the approved plan.

4. Generate keys

Each participating node generates the required namespace and Daml signing keys through its own Canton participant. Private key material remains under the participant’s control.

5. Create and sign topology proposals

The coordinator constructs the decentralized namespace and PartyToParticipant topology proposals. Participating owners authorize the proposals through their local Canton participants.

See Decentralized Party and Canton topology for the distinction between namespace keys, Daml signing keys, and Noise keys.

6. Submit the namespace definition

After the required authorizations are collected, the coordinator submits the decentralized namespace definition and waits for the approved topology-propagation condition.

7. Submit hosting-participant mappings

The workflow authorizes and submits the PartyToParticipant mappings that connect the new party to its hosting participants.

Do not remove propagation waits or manually skip failed workflow steps. A topology proposal may be accepted by one component before it is usable by the next.

8. Verify the party

A successful workflow should confirm:

• The Decentralized Party identifier is stable and matches the planned prefix.
• The decentralized namespace definition contains the approved owner set and policy.
• The expected participants host the party with the intended permissions.
• Required signing keys appear in the applicable topology mappings.
• Every node records the same resulting party identity.
• The workflow reaches its completed state without unresolved peer errors.

If the coordinator becomes unavailable

The coordinator is the point of progress for the active workflow. Do not start a second conflicting onboarding run until the original state is understood. Use the approved cancel, retry, or recovery procedure for the selected release.

Membership changes after creation

Adding or removing participants is a separate governed operation. The party identifier can remain stable while membership changes, but parties with active contracts may require additional state-replication procedures. Do not treat re-running initial onboarding as the default membership-change process.

Troubleshooting

Stage	Common check	Safe response
Invitations	Peer connectivity, version compatibility, and pending invitation state	Resolve peer health before retrying.
Key generation	Admin API access, participant vault permissions, and local logs	Do not export or move private keys outside the approved process.
Topology signing	Owner identity, proposal serial, target store, and signer rights	Inspect the exact proposal rather than creating a parallel one.
Propagation	Synchronizer connectivity and topology state	Wait according to the reviewed release behavior.
Final verification	Namespace and PartyToParticipant mappings across nodes	Do not deploy governed contracts until all nodes agree.

Technical sources

• Onboarding architecture
• Repository README

Related pages

• Decentralized Party and Canton topology
• Complete the first governance action
• Decentralization Manager membership and governance changes

Next step

👉 Validate governance: Complete the first governance action.