Building Decentralized Apps On Canton With Decentralization Manager

Canton was built for institutional assets, and more of them arrive every month. That is a growing opportunity for builders, and the ecosystem will fund you to go after it: the Canton Foundation's development fund pays teams to build on Canton.

What matters is getting one thing right: how parties work. On Canton a party holds assets, not the smart contract. Distributing that party across multiple independent operators, with threshold signing and on-chain governance, is what lets institutions trust an application with serious assets. It is also the kind of infrastructure that takes a specialist team months to build, so most teams launch on a single operator instead.

That shortcut holds until the application starts to matter. When one operator controls the assets, a single outage or compromise can take the whole application down with it, and that concentration is the first thing institutional counterparties look at before they commit capital.

That is the gap Decentralization Manager closes: the months of specialist work become something you inherit instead of build.

Start with the hard part. A Decentralized Party is Canton's native model for distributing a party's custody and governance across multiple independent operators under a signing threshold, where a defined number must act together to authorize anything. No single operator holds control, and operators can rotate in and out without exposing key material. Canton supported this pattern from the start; it is not something BitSafe invented. Standing one up properly (selecting operators, configuring thresholds, wiring on-chain governance, handling key rotation) is the specialist work that takes months.

Now the shortcut. Decentralization Manager is the open-source framework that turns those months into something you configure. It lets institutions and developers create their own Decentralized Party, manage operators, set thresholds, and ship governed applications through a modular plugin architecture. It was developed through an approved Canton Foundation development-fund grant and contributed to the Canton Foundation GitHub.

So the one-line version: a Decentralized Party is the Canton-native pattern, and Decentralization Manager is how you actually stand one up and run it. Both sit on Canton, the network purpose-built for institutional participants, where privacy is architectural rather than bolted on.

Open source under Apache 2.0: once you have access, you download Decentralization Manager and run it yourself, with the Admin UI included in the package so there's no separate setup. CBTC is the production proof that the architecture works, running today as a Decentralized Party that governs custody and admin operations on Canton MainNet.

Decentralization Manager is built in layers, so you take only what your application needs. At its heart is the Generalized Governance Core, with prebuilt plugins layered on top, all coming together in one open-source release under Apache 2.0.

It all ships together, open source under Apache 2.0: the application UI, the Governance Core, the plugins, and the underlying Decentralized Party infrastructure as a single package.

The stack maps to what you're building. Most teams start with the Governance Core and reach for a plugin when one fits.

For an application that needs decentralized custody and governance, the path is the Generalized Governance Core. Build a custom application on it for anything beyond the prebuilt set: lending pools, AMMs, governed treasury workflows, real-world asset tokenization. You build the decentralization layer once and reuse it across every product on top. CBTC is the production reference: it runs as one Decentralized Party and already powers a multi-venue trading ecosystem, with more applications plugging into the same party rather than rebuilding it per app.

When a plugin fits your use case, it shortens the path:

A second shape is emerging that widens what Decentralization Manager is for. The same decentralization model can secure a party where the end user holds the key, with no governance set and no plugins on top. The party is hosted across multiple operators with a threshold for redundancy, so no single node's failure locks the user out, while signing authority stays with the user. The clearest use case is decentralized wallets, where single-node hosting is exactly the failure mode this removes. Alongside it, dedicated token-factory tooling will make token issuance a turnkey path rather than custom work.

This direction is forward-looking. The current definition of Decentralization Manager stays focused on governed applications.

Canton's institutional moment is here, and as more assets and builders arrive, the demand for easy decentralization is accelerating. On Canton, decentralization is not a feature you bolt on later; it is what separates an application institutions can put assets behind from one they keep at arm's length. Decentralization Manager makes that something you inherit from day one instead of something you build from scratch.

BitSafe is one of the first decentralization layers on Canton, and CBTC is the production proof that the architecture holds up when institutions put assets behind it. Decentralization Manager is how that same groundwork becomes something every other builder on Canton can ship on.

Decentralization Manager is rolling out access in stages. Two ways to get going now: