> 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/connect-peers.md).

# Connect peers

[Decentralization Manager overview](/decentralization-manager/overview.md) · [Decentralization Manager prerequisites](/decentralization-manager/get-started/prerequisites.md) · [Run Decentralization Manager locally](/decentralization-manager/get-started/run-locally.md)

### Outcome

Exchange peer identities between Decentralization Manager nodes and verify mutual connectivity before starting a multi-party workflow.

### Before you start

Each organization should have:

* A running Decentralization Manager instance on an approved release.
* A stable persistent data directory and Noise identity.
* A reachable peer communication address and port.
* Access to the authenticated operator interface.
* The Canton participant identity associated with the node.
* An approved out-of-band channel for exchanging peer records.

Connecting peers does not create a Decentralized Party. It establishes the communication relationship required by later workflows.

### Peer information

A peer record includes the information needed to identify and reach a node, such as:

* Canton participant identifier.
* Operator-friendly name.
* Public hostname or address.
* Peer communication port.
* Noise public key.
* Associated Canton party when available.

Treat the public key and participant identity as security-sensitive configuration. Verify them through an authenticated channel.

### 1. Verify your own node identity

In the Network area, inspect the node’s participant information, public address, peer port, and Noise public key. Confirm that the persistent data directory is the intended one before sharing the record.

### 2. Copy your peer record

Use the interface’s share or copy action to produce the node’s peer record. Do not manually retype long identifiers unless the UI is unavailable.

### 3. Exchange records out of band

Send your record to each intended peer through an approved authenticated channel. Receive each peer’s record through the same process.

Do not accept a peer record solely because it arrived in an unauthenticated chat, public issue, or forwarded message.

### 4. Add the peer

Use the Network area’s paste or add action to import the peer record. Review the participant identifier, address, port, and public key before saving.

Repeat on both sides. One-sided configuration can leave the relationship unreachable or asymmetric.

### 5. Verify connectivity

After both sides save each other’s records, confirm that:

* The peer appears in the local list.
* The connectivity indicator becomes healthy.
* Heartbeat or health checks succeed.
* Logs do not show key, allowlist, protocol-version, DNS, or timeout errors.
* The same participant identifier and public key appear on both sides.

### 6. Test a harmless interaction

Before creating a party, use an approved health or discovery action that does not change Canton state. This validates routing and authentication without starting a workflow.

### Replace a peer record safely

A node’s Noise key can change if its persistent identity is lost or regenerated. When replacement is necessary:

1. Stop workflows involving the affected peer.
2. Obtain the new peer record through an authenticated channel.
3. Compare participant identity, address, and key with the operator.
4. Replace the stale record on every affected node.
5. Verify mutual connectivity before resuming workflows.

{% hint style="info" %}
Do not regenerate a Noise identity as a routine troubleshooting step. Other peers identify the node by its public key and may all require coordinated updates.
{% endhint %}

### Troubleshooting

| Symptom                          | Check                                                                 | Safe next action                                           |
| -------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------- |
| Peer remains unreachable         | Address, port, firewall, load balancer, DNS, and process status       | Test reachability from the peer’s network.                 |
| Unknown key or allowlist error   | Imported public key and current node identity                         | Re-exchange records through the authenticated channel.     |
| Only one side is healthy         | Whether both nodes added each other and advertise reachable addresses | Correct the missing or stale side.                         |
| Protocol-version mismatch        | Release versions across the mesh                                      | Follow the approved lockstep upgrade procedure.            |
| Connectivity drops after restart | Persistent data directory and Noise key                               | Restore the intended volume before replacing peer records. |

### Technical sources

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

### Related pages

* [Create a Decentralized Party](/decentralization-manager/get-started/create-a-decentralized-party.md)
* [Join the BitSafe Node Operator Network](/decentralization-manager/get-started/join-the-bitsafe-node-operator-network.md)
* [Decentralization Manager architecture overview](/decentralization-manager/concepts-and-development/architecture-overview.md)
* [Decentralization Manager backup, recovery, and mesh upgrades](/decentralization-manager/operations-and-reference/backup-recovery-and-upgrades.md)

### Next step

👉 **Create the shared identity:** [Create a Decentralized Party](/decentralization-manager/get-started/create-a-decentralized-party.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/get-started/connect-peers.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.