|title||NoM Multichain infrastructure|
|acceptance||upon usage by the community|
|activation||upon usage by the community|
A blockchain interoperability solution is paramount for every blockchain network that wants to develop a sustainable, thriving ecosystem. Users are able to frictionlessly swap assets between different blockchain networks through a seamless procedure enabled by user-friendly interfaces.
This integration with the wider blockchain ecosystem will simultaneously attract more users (builders, developers, marketers, liquidity providers, etc.) and will also unlock a core component of the Network of Momentum: the Protocol Level Liquidity.
Decentralized cross-chain bridges
Furthermore, in order to achieve protocol level liquidity and successfully kickstart the Orbital Program, a bidirectional mechanism to allow the flow of assets between NoM and other blockchain networks is required.
Why do we need a decentralized cross-chain bridge?
Current centralized exchanges (CEX) are single point of failures by either going rogue (e.g. FTX saga), shutting down due to regulatory pressures, or simply hacked and user funds drained (e.g. QuadrigaCX). Moreover, centralized exchanges have several other limitations and weaknesses:
- KYC mishandling and user account censorship
- cumbersome listing procedures or requirements
- prohibitive listing fees
- manipulative behavior (e.g. wash trading)
- delistings due to regulatory pressure
- opaque order book
Decentralized exchanges (DEX) and liquidity pool-based DEX AMMs (e.g. Synapse, Multichain, cBridge, Uniswap, Pancakeswap, etc.) are better suited for trustlessly swapping assets within or between blockchain ecosystems: a frictionless, user-centric approach that benefits every participant.
In order to fulfill the vision of a decentralized ecosystem, a robust multi-chain interoperability solution is crucial to be deployed and maintained at protocol level with a layered security approach.
Protocol Level Liquidity
What is Protocol Level Liquidity?
Protocol Level Liquidity is a way to incentivize liquidity providers by allocating and distributing funds for them directly from the network emission in a trustlessly and automated manner. NoM has a dual-coin inflation in ZNN (Zenon) and QSR (Quasar). A fraction of this dual-coin emission is reserved for the liquidity embedded, a system smart contract that is currently tasked to safely store it for the upcoming Orbital Program.
What is the Orbital Program?
Orbital Program is a protocol level liquidity program that incentivizes liquidity providers to participate and pool together liquidity for the wrapped representations of ZNN, QSR and ZTS tokens in exchange for the aforementioned fraction of the dual-coin emission. This program will create a sustainable model for external liquidity providers to participate into the network.
Why is this necessary?
Without proper incentive mechanisms, LPs will not be interested to join the Orbital Program and this in turn will hurt the ecosystem by limiting the potential of external users that would swap their assets to NoM. Moreover, beyond Orbital Program, new untapped markets and gateways to access NoM are necessary for a healthy development of the ecosystem.
There are several distinct components that will enable a multi-chain vision with Orbital Program at its core:
- The embedded contracts (bridge and liquidity)
- The orchestrator layer
- The EVM smart contracts
The possibility to exchange and swap assets in a trustless, decentralized way between NoM and other networks is conditioned by the existence of a decentralized bridge solution.
The liquidity embedded in its current form does not have the means to distribute rewards to liquidity providers in a trustless and automated way.
A robust interoperability solution must also maximize the compatibility with other blockchain networks:
A. Compatibility with account based networks
A.1. Compatibility with account based EVM networks (Ethereum, BNB Smart Chain, etc.)
The initial phase will consist of an implementation specifically designed for EVM compatibility:
- Execution compatibility: Ethereum virtual machine (i.e. Solidity)
- Cryptographic compatibility: ECDSA signatures (i.e. secp256k1)
- API compatibility: ETH JSON-RPC (i.e. Ethereum JSON-RPC API)
This interoperability solution will unlock liquidity from a wide range of both Layer-1 and Layer-2 EVM compatible networks such as Ethereum, BNB Smart Chain, Polygon, Avalanche, Arbitrum, etc.
Liquidity pools will be gradually deployed on those networks for the wrapped representations of ZTS assets, enabling a seamless process for users to access and get onboarded into the NoM ecosystem.
A.2. Compatibility with account based non-EVM networks (Polkadot, Cosmos, etc.)
In the future, more non-EVM networks can be connected by implementing custom integrations:
- Execution compatibility: Virtual machine type (i.e. WASM)
- Cryptographic compatibility: EdDSA signatures (i.e. Ed25519)
- API compatibility: custom API for each network
B. Compatibility with UTXO networks (Bitcoin, Litecoin, etc.)
In the next phase, compatibility with UTXO networks, in particular Bitcoin, is expected to be implemented and rolled-out. Further design changes are necessary for optimal integration with existent BIP340, BIP341 (e.g. Schnorr signatures - Musig2, MAST, Tapscript, etc.).
Security focused design
The whole design architecture of the decentralized cross-chain bridge is focused around security considerations.
Not a single centralized entity except the end user is able to move funds and several security mechanisms are organized in a layered structure to prevent and deter malicious actors from exploiting the infrastructure. The TSS participants are only able to sign transactions; they do not have the possibility to move user funds.
Time-challenge as a security primitive
Every sensitive action is split into two separate stages and is safeguarded by a time-challenge security primitive. This primitive is used throughout the codebase for every sensitive action that either involves moving funds or other critical actions.
Wrap and Unwrap
- ZTS = native Zenon Token Standard asset on NoM e.g. ZNN
- wZTS = wrapped Zenon Token Standard asset on a particular destination network e.g. wZNN
- ERC-20 = native Ethereum token on Ethereum mainnet e.g. DAI
- zERC-20 = wrapped Zenon Token Standard asset on NoM e.g. zDAI
Source NoM → Destination Ethereum
- ZNN (ZTS on NoM) → wrap → wZNN (ERC-20 on Ethereum)
- zDAI (ZTS on NoM) → unwrap → DAI (ERC-20 on Ethereum)
Source Ethereum → Destination NoM
- wZNN (ERC-20 on Ethereum) → unwrap → ZNN (ZTS on NoM)
- DAI (ERC-20 on Ethereum) → wrap → zDAI (ZTS on NoM)
Additionally, the two step procedure is enforced to either wrap or unwrap assets:
- Stage 1 Request Action: this signals the intention of a user to wrap or unwrap his assets.
- Stage 2 Redeem Action: this action settles the user’s request and actually delivers the swapped assets to its corresponding address.
The codebase has extensive unit-testing to cover common and exotic edge-cases that might appear in different scenarios.
What actors will participate in the NoM multi-chain infrastructure?
They will be elected from prominent members of the community. They will act as judges in case of a major failure of the infrastructure. They are responsible to safeguard the infrastructure in case of an emergency.
The role of the admin is to manage the infrastructure. It cannot move funds and its permissions are limited in scope. The embedded contracts are designed to be managed by the community members through a governance module, similar to Accelerator-Z. At the moment the governance capabilities of NoM are insufficient to ensure this functionality. Until a solution is developed, the admin will be managed by code maintainers.
Pillars as TSS participants
All the nodes of the orchestrator will run on Pillar nodes. This design decision is based on the consideration that the security of the whole network depends on consensus running nodes. They already have the technical background and know-how to operate nodes and a sufficient stake in the network to responsibly manage this critical piece of infrastructure. Pillars will be able to be part of the orchestrator peer-to-peer layer (libp2p) and participate in the threshold signature (TSS) ceremonies.
Liquidity Provides (LPs) are users with disposable capital that are incentivized through the Orbital Program to directly participate into the network by staking their liquidity in order to receive dual-coin (ZNN and QSR) rewards. They must ensure adequate levels of liquidity for users to be able to frictionlessly swap their assets in and out of the ecosystem.
What motivated the design?
This particular interoperability solution allows easy transfers from NoM to other networks. The embedded bridge contract allows the control of native ZTS assets on NoM, while EVM Solidity contracts allow the control of wrapped ZTS assets on EVM compatible chains.
Decentralized cross-chain bridge: end-to-end flow
The bridge is based on lock-and-release/mint-and-burn mechanisms: native assets are locked/burned on one side and released/minted on the other side. Depending on the nature of the swap, the following scenarios may appear:
Example native ZNN/wZNN (native ZNN and wZNN as ERC-20 token):
Native ZNN is locked in the bridge embedded contract on NoM and its wrapped representation, wZNN is minted by the Ethereum contract. For the opposite direction, wZNN is burned by the ETH smart contract and native ZNN is released by the embedded bridge.
Example stablecoin DAI/zDAI (DAI as ERC-20 token and zDAI as ZTS token):
DAI stablecoin is locked in the Ethereum smart contract, while the embedded contract mints the equivalent amount on NoM. For the opposite direction, zDAI is burned by the embedded contract and ETH token DAI released by the ETH smart contract.
Orbital Program: end-to-end flow
The Orbital liquidity embedded contract is based on the staking embedded contract.
A liquidity provider that wants to participate in the Orbital Program must supply a liquidity pool with the corresponding assets, swap the resulting LP token to NoM and lock it up into the liquidity embedded to earn dual-coin rewards.
For example, an Ethereum user wants to become a liquidity provider (LP) and deposit ETH and wZNN into a pool in order to participate into the Orbital Program. Depending on how much liquidity they provide for the wZNN/ETH pool on Uniswap, they will receive a proportional amount of ERC-20 LP tokens. In the next step, the LP must swap the ERC-20 LP tokens to the ZTS zLP tokens on NoM using the decentralized cross-chain bridge. In order to become eligible for receiving dual-coin rewards from NoM’s emission, the LP must deposit the zLP tokens into the liquidity embedded contract. The liquidity embedded contract mirrors the staking embedded contract in terms of locking the tokens for a predefined time period. However, it differs from a rewards’ perspective: participating LPs get both ZNN and QSR.
The implementation is fully open-source on Github with a permissive licensing model - GNU General Public License v3.0 to allow builders to develop a healthy middleware ecosystem for the Network of Momentum. The codebase in written in Go v1.20 and the EVM smart contracts are written in Solidity v0.8.17
The core components of the infrastructure - go-tss, tss-lib modules are properly audited are are used in production by high ranking cryptocurrencies (e.g. Thorchain).
Thorchain go-tss: https://github.com/thorchain/Resources/tree/master/Audits
Binance tss-lib: https://github.com/bnb-chain/tss-lib/releases/download/v1.0.0/audit-binance-tss-lib-final-20191018.pdf
IPFS libp2p: Security Considerations - libp2p
1.1 Embedded bridge contract
1.2. Embedded liquidity contract
EVM smart contracts
Testing environment: GitHub - HyperCore-Team/dockerized-testnet
GNU General Public License v3.0
VII. ZIP Comments
VIII. ZIP References
Hyperspace interoperability: cross-chain bridge
IX. ZIP License
This ZIP is licensed under GNU General Public License v3.0