Architecture overview
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
Web interface and HTTP API
Operator setup, status, workflows, governance, and operations
Browser authentication, roles, input validation, and privileged routes
Peer communication service
Coordinate workflows between Decentralization Manager instances
Persistent Noise identities, allowlisted peers, reachability, and protocol compatibility
Workflow coordinator
Start one workflow, invite peers, collect responses, and advance state
Temporary point of progress, not permanent authority over the party
Canton Admin API client
Topology, keys, packages, and privileged participant operations
Administrative credentials and least privilege
Canton Ledger API client
Contracts, commands, party data, users, rights, and interactive submissions
Party authorization and command semantics
Operational database and DAR storage
Persist identity, peers, credentials, workflow state, and staged packages
Integrity, encryption, backup, migration, and access control
Daml governance packages
Define proposals, confirmations, execution, membership, and modules
Installed package versions and on-ledger authorization
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:
The initiating instance selects eligible peers and starts a run.
Peers receive and inspect invitations.
Each peer performs its local Canton or application step.
Peers return status or authorized material.
The coordinator advances the run when the active requirements are met.
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 and Decentralization Manager compatibility, releases, and troubleshooting.
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
Related pages
Next step
👉 Understand the identities and hosting model: Decentralized Party and Canton topology.
Last updated