> 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/concepts-and-development/decentralized-party-and-canton-topology.md).

# Decentralized Party and Canton topology

[Create a Decentralized Party](/decentralization-manager/get-started/create-a-decentralized-party.md)

### 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

| Key                       | Purpose                                                  | Storage boundary                         |
| ------------------------- | -------------------------------------------------------- | ---------------------------------------- |
| 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

1. Operators agree on the intended participant and owner set.
2. Nodes establish peer connectivity.
3. Each participant generates required local keys.
4. The coordinator assembles topology proposals.
5. Owners authorize the decentralized namespace definition.
6. The approved definition is submitted and propagated.
7. Owners authorize PartyToParticipant mappings.
8. 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

* [Architecture](https://github.com/DLC-link/decentralization-manager/blob/main/docs/ARCHITECTURE.md)
* [Canton documentation](https://docs.digitalasset.com/)

### Next step

👉 **Plan controlled changes:** [Decentralization Manager membership and governance changes](/decentralization-manager/operations-and-reference/membership-and-governance-changes.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/concepts-and-development/decentralized-party-and-canton-topology.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.