> For the complete documentation index, see [llms.txt](https://docs.bitsafe.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bitsafe.finance/decentralization-manager/get-started/create-a-decentralized-party.md).

# Create a Decentralized Party

[Decentralization Manager overview](/decentralization-manager/overview.md) · [Connect Decentralization Manager peers](/decentralization-manager/get-started/connect-peers.md)

### 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](/decentralization-manager/concepts-and-development/decentralized-party-and-canton-topology.md) 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.

{% hint style="info" %}
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.
{% endhint %}

### 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](https://github.com/DLC-link/decentralization-manager/blob/main/docs/ARCHITECTURE.md)
* [Repository README](https://github.com/DLC-link/decentralization-manager/blob/main/README.md)

### Related pages

* [Decentralized Party and Canton topology](/decentralization-manager/concepts-and-development/decentralized-party-and-canton-topology.md)
* [Complete the first governance action](/decentralization-manager/get-started/complete-your-first-governance-action.md)
* [Decentralization Manager membership and governance changes](/decentralization-manager/operations-and-reference/membership-and-governance-changes.md)

### Next step

👉 **Validate governance:** [Complete the first governance action](/decentralization-manager/get-started/complete-your-first-governance-action.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bitsafe.finance/decentralization-manager/get-started/create-a-decentralized-party.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.