Canton's next wave of applications needs operators. The ones ready first will run them.
Canton has crossed from experiment to critical financial infrastructure. Because the network is privacy-native, institutions can operate on-chain without exposing positions or counterparties, and real capital is now live. As it arrives, more teams are building their applications to run the way institutions expect: distributed across several independent operators, not a single node. That opens a direct opportunity for node operators, because every application on a Decentralized Party needs operators to host and govern it, and the ones ready first are matched in first.
Every decentralized application needs operators
A single node, or even two, is not decentralized. Each application on a Decentralized Party needs several independent operators, so no one operator controls user assets and the application keeps running even if a node goes down. This is recurring demand, not a one-time integration. Every new multi-party application needs its own set of operators, and any operator already running a Canton node can serve it without standing up anything new.
The operators who show up first win the introductions
Builders do not want to assemble an operator network from scratch, so they come to BitSafe for introductions to vetted, institutional-grade operators, and the ones already deployed are matched into the first applications. Being early compounds. An operator matched in at launch becomes a default choice as that application grows, earns alongside it as Featured App Rewards scale, and is the one builders return to for the next party.
Earn from infrastructure already running
On Canton, assets are held by a party, not the contract. A Decentralized Party is a single on-chain party whose keys and approvals are split across several operators, so none can act alone. Members review proposals, confirm them against an agreed threshold, and share in the rewards the party generates.
Decentralization Manager is the open-source application, released under Apache 2.0 and backed by a Canton Foundation grant, that lets a running Canton node join and govern Decentralized Parties from a single interface. Node operator participation is light: a software install plus accepting proposals, with no confirmation costs and no slashing risk. Operators keep full control over which applications they power, and put existing infrastructure to work.
Proven on Canton with CBTC
The clearest proof is CBTC. The first non-native asset on Canton launched on a Decentralized Party and has run on Decentralization Manager since day one, with over 10 million transactions to date. Operators in that party earn an average of nearly 200,000 CC per month. It is run by independent operators, and its attestors, Nethermind, DSRV, and Finoa Consensus Services, were the first to put Decentralization Manager into production.
"The CBTC Decentralized Party has shown how far Canton has come, and the public beta opening of Decentralization Manager is a big step for the whole ecosystem. Onboarding was remarkably smooth for our team - contract deployment was essentially one click. For any app still running on a single validator, this is the easiest path we've seen to move beyond a single point of failure."
Decentralization on Canton depends on independent operators, and every application that decentralizes makes the network more resilient as it grows.
Add your node to the first parties
Getting matched into the first wave of applications takes three steps.
Fill out the node operator interest form so BitSafe can connect you with the first applications looking for operators: bitsafe.typeform.com/to/oU6g8loF.
Deploy Decentralization Manager on an existing Canton node. The public beta is live on the Canton Foundation's GitHub: github.com/DLC-link/decentralization-manager.
Reach out to BitSafe to onboard as a peer and learn more about the operator program. Connected operators join the registry of available nodes, and when builders need operators to complete their Decentralized Party, connected peers are matched first.
The operators who sign up and deploy now are the ones builders add to their party first, and the default choice as those applications grow.