Skip to main content

Protocol Architecture

The protocol is composed of on-chain and off-chain components. We will get into details on both next:

Off-chain architecture​

Frontend​

The frontend of this dApp was built with React. It interacts with the backend server using API calls and with the protocol smart contracts using ethers library. Here's a breakdown of the frontend environment:

  1. Deployment URL: The deployed frontend application is accessible at https://alliancebridge.io/.

Important Notes:​

  1. The production frontend is built with minified and optimized code for improved performance.

  2. Environment variables specific to the production environment are configured and not included in the Git repository for security reasons.

Backend Server Environment​

The backend server is a Node.js application, using express, responsible for handling business logic, redis interactions, and communication with blockchain nodes. Here's a breakdown of the backend server environment:

  1. Deployment Location: The backend server is deployed on https://backend.alliancebridge.io/.

  2. API Documentation: The API reference documentation for the backend server can be found at Backend Reference.

  3. Environment Variables: The backend server relies on environment variables to define configurations such as redis connections, API keys, and blockchain network settings. These variables are managed securely on the deployment platform.

Important Notes:​

  1. The backend server code in the Git repository might not reflect the exact production configuration due to the use of environment variables.

  2. Access to the backend server itself is restricted for security reasons. Interaction with the backend happens solely through the documented API endpoints.

SDK​

The Nexera Interoperability Protocol SDK provides an abstraction layer that simplifies the complexity of the Nexera Interoperability Protocol, allowing developers to focus on building their applications. By providing easy-to-use tools and libraries, enables developers to add custom messaging functionality to their dApps, making it possible to send specific messages to the different supported chains.

The SDK is composed by a core part with the main Teleport functionality, and allows the addition of SDK modules, to interact with the dApp specific SDK. Developers can create custom modules and add them to the SDK to provide additional functionality for the specific dApps. By Default, the official Nexera dapps SDK modules are added.

To use the Nexera Interoperability Protocol SDK, developers need to instantiate the SDK using the SDK factory. The factory allows developers to configure the modules that should be instantiated and the chain to which they want to connect. Once the SDK instance is created, developers can use it to interact with the Nexera Interoperability Protocol and the specific dApps.

More information on the SDK reference can be found at SDK Reference.

On-chain architecture​

The Nexera Interoperability Protocol consists of the following on-chain components (contracts):

  1. Teleport.
  2. ProviderSelector.
  3. CCIPProviderAdapter.
  4. MPProvider.
  5. DApps (ERC20, ERC721, ERC1155 routers, among others).

Teleport​

The teleport contract is an orchestrator/aggregator of Cross-chain interoperability solutions. It means, that the Nexera Interoperability Protocol supports sending messages using multiple messaging providers like CCIP and traditional Nexera messaging protocol.

ProviderSelector​

The ProviderSelector contract contains the logic to select the best provider for the configured settings. This contract knows all the available providers, and will be capable of selecting the correct provider when the teleport asks.

This logic is separated from the teleport to make it easier to be changed. In the future, if the logic used to select a provider is changed, we can easily create a new contract, audit it, and configure it in the teleport to replace the old one.

Currently, the protocol is using the MultiWithDefaultProviderSelector. This selector implements the IProvider interface and is designed to handle multiple providers, selecting a default one when necessary. Additionally, it allows the Teleport to send messages using a specific provider.

CCIPProviderAdapter.​

This contract implements the IProvider interface, which adds the needed functions for the teleport to interact with this contract. Also, this is kind of an adapter between the teleport interface, and the CCIP interface, hence the name.

MPProvider​

The MPProvider contract also implements the IProvider interface, and contains the logic related to the Messaging protocol, that the teleport uses for interoperability via the original Nexera messaging protocol.

This is the contract that triggers the needed events for the messaging protocol.

DApps​

The dApp term is an abbreviation for decentralized applications. There are currently two dApps (routers) implemented for the Nexera Interoperability Protocol so far. Both of them provide the possibility to transfer assets between different blockchains. They are:

  1. The ERC20 router dapp: please refer to the Bridging ERC20 Tokens documentation to know more about this router and how it works.

  2. The ERC721 router dapp: please refer to the Bridging ERC721 Tokens documentation to know more.

Governance members​

The Nexera Interoperability Protocol operates under a Threshold Signature Governance model, ensuring a secure and decentralized decision-making process.

Decisions are made through a majority signature requirement. This means that for a proposal to pass, at least n/2 + 1 members (where n is the total number of governance members) must cryptographically sign their approval on the proposal.

Members management and contracts upgrades are subject to go through the governance process.

Interaction Diagram​

The following diagram illustrates how the components of the protocol interact with each other:

Nexera Interoperability Protocol architecture