> 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/get-started/join-the-bitsafe-node-operator-network.md).

# Join the BitSafe Node Operator Network

{% hint style="info" %}
Join the BitSafe Node Operator Network so that BitSafe can consider your node for Canton applications that need independent operators for their Decentralized Parties.
{% endhint %}

### How it works

A node operator deploys Decentralization Manager on an existing Canton node. The operator then connects that node with BitSafe as a peer. After both teams validate the connection, BitSafe adds the operator to its registry of available nodes.

When an app developer needs independent operators, BitSafe matches connected peers first. The app and the participating operators enter into their own commercial agreement. BitSafe often coordinates the operator group and may act as the application administrator.

### Before starting, please check:

* [ ] An existing Canton node is running and accessible
* [ ] A technical contact is available for setup and validation
* [ ] You are installing the latest release of Decentralization Manager
* [ ] Peer and party details are ready to exchange securely
* [ ] On an AWS KMS participant, Decentralization Manager has AWS credentials and `kms:Sign` access

All nodes of a Decentralized Party must run the same release. A coordinator invites only peers that use the same Noise wire version and report version `0.1.9` or later.

### Signing support

Decentralization Manager signs the ledger transactions of a Decentralized Party with the party's Daml key. It supports two participant setups:

| Participant crypto provider | How Decentralization Manager signs                                                                                              | Operator setup                            |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| JCE (the Canton default)    | The node exports the party's Daml private key from the vault for each signature. It signs on the node and never stores the key. | None                                      |
| AWS KMS                     | It calls the AWS KMS `Sign` API. The key stays in AWS KMS.                                                                      | AWS credentials and `kms:Sign` permission |

Decentralization Manager supports no other KMS driver for this signing step. On such a participant, the signing step fails with a KMS error.

#### AWS KMS setup

On an AWS KMS participant, the participant creates each party Daml key under its own KMS role. The role of Decentralization Manager gets no access to the key by default. Decentralization Manager needs AWS credentials and `kms:Sign` on each party Daml key before you deploy contracts. Each Decentralized Party has its own Daml key. Without `kms:Sign`, the contracts workflow fails with `AccessDeniedException`. [Sign with AWS KMS](/decentralization-manager/operations-and-reference/sign-with-aws-kms.md) gives the setup procedure.

### Join in two steps

#### 1. Deploy Decentralization Manager

Deploy the open-source application on the existing Canton node:

* [GitHub repository](https://github.com/DLC-link/decentralization-manager)
* [Production deployment](/decentralization-manager/get-started/production-deployment.md)

Confirm that the node runs and that its Noise port is reachable. Then start the peer exchange.

#### 2. Connect with BitSafe as a peer

1. Share your DevNet peer record and party ID with BitSafe. To copy the peer record, open **Configuration** and click **Share my data** under **Peers:**.
2. BitSafe shares its peer record and party ID.
3. Add the peer record of BitSafe to your node. Click the pencil icon (**Edit peers**), then **Paste from Clipboard**, then **Save**.
4. Both teams confirm that the peer status reads "Connected via Noise protocol".

See [Connect peers](/decentralization-manager/get-started/connect-peers.md) for the full procedure.

### Next Steps

After a test party creation succeeds on DevNet, approved operators onboard on MainNet. TestNet is also available.

1. **MainNet connection:** Approved operators repeat the peer exchange on MainNet. They do not need to create a party.
2. **Registry activation:** BitSafe adds the operator to its available-node registry.
3. **App matching:** BitSafe introduces suitable operators when an application needs a Decentralized Party.
4. **Commercial agreement:** The app and the node operators agree on scope, responsibilities, service levels, and fees.

### Commercial model

Each app and its participating node operators agree on the commercial terms. Common structures include:

* A percentage of the app's Featured App Rewards
* A flat monthly fee
* A combination of reward share and a flat fee

BitSafe may coordinate the operator group and act as administrator. BitSafe does not guarantee operator earnings. Fees depend on the application, the operating requirements, the service levels, and the commercial agreement.

### Ready to begin?

Contact the BitSafe point of contact to start DevNet onboarding. BitSafe confirms the technical contact, the secure exchange channel, and the required connection details.

***

### Resources

* [Node Operator Product Sheet](https://docsend.com/view/e7r4fvijh8x3zd9a)
* [Building Decentralized Parties](https://docsend.com/view/k9jeckpvng348reu)

### Technical sources

* [Signing with AWS KMS party keys](https://github.com/DLC-link/decentralization-manager/blob/main/docs/KMS_SIGNING.md)
* [Signing backends](https://github.com/DLC-link/decentralization-manager/blob/main/crates/decman/src/signing/mod.rs)
* [Vault export signer](https://github.com/DLC-link/decentralization-manager/blob/main/crates/decman/src/signing/vault_export.rs)
* [Minimum peer version](https://github.com/DLC-link/decentralization-manager/blob/main/crates/decman/src/consts.rs)
* [Exchange peer details](https://github.com/DLC-link/decentralization-manager/blob/main/docs/ADDING_A_MEMBER_TO_A_DECENTRALIZED_PARTY.md#exchange-peer-details)
* [Deployment guide](https://github.com/DLC-link/decentralization-manager/blob/main/docs/DEPLOYMENT_GUIDE.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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bitsafe.finance/decentralization-manager/get-started/join-the-bitsafe-node-operator-network.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.