> 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/architecture-overview.md).

# Architecture overview

[Decentralization Manager overview](/decentralization-manager/overview.md)

### Purpose

Decentralization Manager coordinates Canton topology, peer communication, package distribution, governed contract deployment, and governance workflows across organizations that operate a Decentralized Party.

This page is the canonical conceptual source for components, peers, and the workflow coordinator role. Task pages own procedures; the API reference owns route and status details.

### Component map

<table data-search="false"><thead><tr><th>Component</th><th>Responsibility</th><th>Boundary</th></tr></thead><tbody><tr><td>Web interface and HTTP API</td><td>Operator setup, status, workflows, governance, and operations</td><td>Browser authentication, roles, input validation, and privileged routes</td></tr><tr><td>Peer communication service</td><td>Coordinate workflows between Decentralization Manager instances</td><td>Persistent Noise identities, allowlisted peers, reachability, and protocol compatibility</td></tr><tr><td>Workflow coordinator</td><td>Start one workflow, invite peers, collect responses, and advance state</td><td>Temporary point of progress, not permanent authority over the party</td></tr><tr><td>Canton Admin API client</td><td>Topology, keys, packages, and privileged participant operations</td><td>Administrative credentials and least privilege</td></tr><tr><td>Canton Ledger API client</td><td>Contracts, commands, party data, users, rights, and interactive submissions</td><td>Party authorization and command semantics</td></tr><tr><td>Operational database and DAR storage</td><td>Persist identity, peers, credentials, workflow state, and staged packages</td><td>Integrity, encryption, backup, migration, and access control</td></tr><tr><td>Daml governance packages</td><td>Define proposals, confirmations, execution, membership, and modules</td><td>Installed package versions and on-ledger authorization</td></tr></tbody></table>

### One instance per organization

Each participating organization runs its own Decentralization Manager instance connected to its Canton participant. The organization controls its operator authentication, persistent Noise identity, operational database, Canton credentials, and upgrade process.

### Peer model

A peer is another Decentralization Manager instance recognized through a verified peer record. Peer connectivity supports workflow coordination; it does not create Canton topology, hosting, or governance membership by itself.

Operators exchange peer records through an authenticated out-of-band channel and allowlist intended peers. A changed Noise public key represents a different peer identity and requires coordinated updates.

### Coordinator model

The instance that starts a workflow acts as its coordinator for that run. It invites eligible peers, collects their responses, and advances the workflow state. The role is temporary and does not grant permanent control of the Decentralized Party.

A typical coordinated workflow is:

1. The initiating instance selects eligible peers and starts a run.
2. Peers receive and inspect invitations.
3. Each peer performs its local Canton or application step.
4. Peers return status or authorized material.
5. The coordinator advances the run when the active requirements are met.
6. Every operator verifies the resulting Canton or application state.

### Failure and recovery boundary

If a coordinator becomes unavailable, a workflow can pause while the Decentralized Party and its existing Canton state remain valid. Do not start a duplicate state-changing workflow until the original run and resulting Canton state are known. Release-specific resume, cancel, retry, and recovery procedures belong in [Decentralization Manager API and workflow reference](/decentralization-manager/operations-and-reference/api-and-workflow-reference.md) and [Decentralization Manager compatibility, releases, and troubleshooting](/decentralization-manager/operations-and-reference/compatibility-releases-and-troubleshooting.md).

### Canton, governance, and persistence

The Admin and Ledger APIs require separate least-privilege treatment. The governance core supplies propose, confirm, execute, cancel, and expire patterns; application modules define the governed behavior. Persistent state includes the Noise identity, database, peer records, party credentials, DAR artifacts, and workflow state required for recovery.

### Technical sources

* [Architecture](https://github.com/DLC-link/decentralization-manager/blob/main/docs/ARCHITECTURE.md)
* [Deployment guide](https://github.com/DLC-link/decentralization-manager/blob/main/docs/DEPLOYMENT_GUIDE.md)

### Related pages

* [Decentralized Party and Canton topology](/decentralization-manager/concepts-and-development/decentralized-party-and-canton-topology.md)
* [Decentralization Manager governance lifecycle](/decentralization-manager/concepts-and-development/governance-lifecycle.md)
* [Decentralization Manager production deployment](/decentralization-manager/get-started/production-deployment.md)
* [Decentralization Manager security architecture](/decentralization-manager/operations-and-reference/security-architecture.md)
* [Decentralization Manager API and workflow reference](/decentralization-manager/operations-and-reference/api-and-workflow-reference.md)

### Next step

👉 **Understand the identities and hosting model:** [Decentralized Party and Canton topology](/decentralization-manager/concepts-and-development/decentralized-party-and-canton-topology.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/architecture-overview.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.