Connectors

Each Orchestrator Node is connected to both NoM and the supported destination network using the JSON-RPC API. There are several types of connectors that provide different degrees of confidence for transaction finality.

Local Connectors

Full Node

The ideal configuration for an Orchestrator Node is to run its own full nodes for all supported networks. This way, it has a precise overview of the network state and does not rely to any third party that can be either maliciously corrupted or censored. Running full nodes also can detect chain reorganizations called reorgs.

Example of chain reorgs for a Bitcoin full node running continuously since 17 December 2016:

  • Actual reorgs: 4 (1 every 84,352 blocks / 570.3 days)
  • Avoided reorgs: 174 (1 every 1,939 blocks / 13.1 days)

Light Node

Light Nodes decrease the load required to run a full node. Some implementations are better than others and if properly used can effectively displace the need for a full node.

Remote Connectors

Decentralized RPC Providers

Decentralized RPC Providers:

Decentralized RPC Providers should only be used for redundancy purposes.

Centralized RPC Providers

Centralized RPC Providers:

  • Infura
  • Alchemy
  • Quicknode

Centralized RPC Providers should only be used for redundancy purposes.