Connect peers
Decentralization Manager overview · Decentralization Manager prerequisites · Run Decentralization Manager locally
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:
Stop workflows involving the affected peer.
Obtain the new peer record through an authenticated channel.
Compare participant identity, address, and key with the operator.
Replace the stale record on every affected node.
Verify mutual connectivity before resuming workflows.
Troubleshooting
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
Related pages
Next step
👉 Create the shared identity: Create a Decentralized Party.
Last updated