Summary:
The proposal introduces Tunnel, the Parallel bridging module; a secure, scalable & decentralized bridging infrastructure to allow the transfer of Parallel stablecoins between any supported chains.
Context
The current version of the Parallel protocol does not allow users to directly bridge PAR and paUSD between the different chains where the protocol is deployed. This is because each stablecoin on each chain has a different contract (PAR on Ethereum ≠ PAR on Polygon PoS).
Let’s take the example of a user wanting to bridge PAR from chain A to chain B. Currently it is necessary for him to sell his native PAR on chain A for let’s say USDC, then bridge the USDC on chain B, in order for him to buy back native PAR from chain B.
Although some solutions exist, such as Jumper, this is not efficient for users and this poses several problems:
- Security (Relying on several DEXs, bridges, etc…)
- Cost (swap fees, bridge fees, slippage)
- Time required
In the past, many collateralized debt protocols have developed modules allowing their stablecoins to be bridged between different chains. However, they did not take into account the risks this posed for the holders of their stablecoins. Indeed, a PAR minted on Polygon PoS does not have the same risks (collateral bridged from another chain, oracles used, decentralization of the chain, etc.) as a PAR minted on Ethereum (collateral native to the chain, oracles used, decentralization of the chain, etc.). Many protocols that have not taken these risks into account have accumulated bad debts as a result of blockchain bridge hacks (Harmony, Fantom) or bad oracles.
Using LayerZero infrastructure, we have developed a bridging module to solve these problems, which we are introducing under the name Tunnel.
Rationale:
LayerZero Infrastructure:
LayerZero is an immutable, censorship-resistant, and permissionless smart contract protocol that enables anyone to send, verify, and execute arbitrary messages on a supported blockchain. Using smart contracts deployed on each chain, in combination with Decentralized Verifier Networks (DVNs) and Executors, LayerZero enables different blockchains to seamlessly interact with one another. In LayerZero, message verification and execution are separated into two distinct phases, providing developers with more control over their application’s security configuration and independent execution.
Decentralized Verifier Networks (DVNs):
DVNs verify cross-chain messages. This permissionless role empowers any entity capable of verifying cross-chain data packets to join LayerZero as a DVN. Any native bridge, third-party bridge, middle chain, oracle, or other verification method may be used as a DVN, thereby avoiding vendor lock-in at the security level. As LayerZero has a modular design, application owners can combine DVNs to maximize verification for characteristics like security, cost, speed, or any parameter an application might want. In other words, LayerZero allows applications to configure any number and type of decentralized verifier networks (DVNs) to verify their cross-chain messages.
Permissionless Execution (executors):
Any entity can run an Executor, as it is an entirely permissionless role. The Executor ensures the smooth execution of a message on the destination chain by offering gas abstraction to the end-user. Executors do this by quoting end-users on the source chain in the source chain gas token while executing the transaction automatically on the destination chain. Much like applications can select a DVN set, they can also configure their application to choose a certain Executor or group of Executors. Applications also have the ability to build and run their own executor (as they can for DVNs) or operate without an Executor and have end-users manually invoke ‘lzReceive’ via LayerZero Scan.
Tunnel, the Parallel Bridging Module Specifications:
-
OFT Standard:
- The bridging module is following the Omnichain Fungible Token (OFT) Standard created by LayerZero. You can find more information about it here.
-
Modular Security Stack:
- Entirely controlled by the DAO: The bridging module is entirely managed by the DAO. Nobody else can change the parameters chosen by the DAO apart from itself.
- Decentralized Verifier Networks (DVNs): X of Y of N allows the DAO to designate a quorum of DVNs to check the integrity of a cross-chain message before signing off on a message’s validity. X of Y of N allows the DAO to combine DVNs however they like. For instance, a “1 of 3 of 5” combination of DVNs would include one required DVN and two arbitrary DVNs out of a total of five to verify a message before moving on to execution. This means that if two DVNs outside the required DVN were unresponsive out of five, message flow could continue, greatly aiding liveness and reducing reliance on a single bridge to zero. Let’s imagine that one of the required DVNs fails (offline, hacked). In this case, the transactions will be automatically reverted, causing no problems for the protocol. The DAO can then vote to change this DVN for another.
- Executors: Thanks to the permissionless nature of Executors, even if all automatic executors are down it’s still possible for the user to execute the transaction himself by manually invoke ‘lzReceive’ with transaction data on the destination chain, either using LayerZero Scan or the destination blockchain block explorer.
-
Extensible:
- Until now, to deploy one of the Parallel stablecoins on a new chain, it was necessary to deploy the entire protocol. However, this posed numerous constraints (deep liquidity for collaterals, cumbersome operational management, the existence of oracles, incentives to gain liquidity due to the incompatibility of Parallel stablecoins between chains). Thanks to the newly bridging module, deploy a Parallel stablecoin on a new chain will no longer need to deploy the entire protocol, but only certain contracts (AccessController, AddressProvider, paUSD/PAR contract) and the bridging module (OFT) related to the deployed stablecoin. This will greatly facilitate business development, thanks to rapid deployment and low operational management for the DAO.
- Let’s say the bridging module for a Parallel stablecoin called TKN is deployed on 3 blockchains, thanks to the bridging infrastructure users will be able to bridge from chain A to chain C, then to chain C to chain B, without having to bridge back to chain A. In other words, the bridging module acts as a mesh network where each blockchain can interact with each other, rather than as a network centralized around a single chain. This increases simplicity, efficiency and reduces the costs associated with bridging.
-
Mint/Burn Limits:
- Daily: This parameter defines the maximum amount of tokens that can be minted or burned per day. It is fully controlled & configurable by the DAO, and can be changed at any time via the ‘setBurnDailyLimit’ and ‘setMintDailyLimit’ functions in the OFT contract (lz-TKN). If the maximum burn amount is reached, the user will not be able to initiate a bridge transaction. If the maximum mint amount is reached, the user will automatically receive lz-TKN instead of TKN, which he can burn for TKN when the limits are no longer reached, or bridge his lz-TKN back to another blockchain.
- Global: This parameter defines a maximum total token amount that can be minted or burned on a blockchain. It is fully controlled & configurable by the DAO and can be changed by it at any time via the ‘setGlobalBurnLimit’ and ‘setGlobalMintLimit’ functions in the OFT contract (lz-TKN). If the maximum burn amount is reached, the user will not be able to initiate a bridge transaction. If the maximum mint amount is reached, the user will automatically receive lz-TKN instead of TKN, which he can burn for TKN when the limits are no longer reached, or bridge his lz-TKN back to another blockchain.
-
Isolation Mode:
- Isolation mode is our response to the mutualization of risks carried out by other bridge modules. Let’s say that the Parallel Protocol (PAR) is deployed on Ethereum and Polygon PoS and that the DAO wishes to deploy it on a new blockchain named Y following the receipt of a grant by this blockchain. However, this blockchain is much less decentralized, has tokens with lower liquidity (increasing the risk of bad debt) and a poorer track record than Ethereum and Polygon PoS. The DAO would also like to deploy the bridging module on this new blockchain, to enable PAR holders from other chains to bridge their tokens on the Y blockchain. However, it does not wish to propagate the risk caused by its PARs mined on the Y blockchain to PARs mined on Ethereum and Polygon PoS. The isolation mode makes it impossible to burn more PAR on the blockchain Y than what has been bridged from the other chains. Let’s continue with the previous example: let’s say there are 1 million PAR minted on the blockchain Y, of which 500,000 come from Ethereum and Polygon. An oracle problem occurs on blockchain Y, and the protocol ends with 4 million PAR mined without collateral and sold to the market, creating a PAR depeg on blockchain Y. The arbitrageurs will then arbitrate the PAR between the different blockchains using the bridging module. However, they will not be able to bridge more than 500,000 PAR (which has been bridged from other chains). In this way, the oracle problem remains isolated to blockchain Y and the bad debt does not spread to Ethereum and Polygon.
- Isolation mode can be activated/deactivated by the DAO via the ‘toggleIsolateMode’ function in the OFT contract (lz-TKN)
-
Fees:
- The protocol has the option to charge a fee when a TKN is bridged. The fee is taken on the destination blockchain when the lz-TKN is burned for TKN. The fee is taken via a fixed rate taken according to the bridged amount, there is no possibility to take a fixed fee per bridge transaction. Fees can be modified by the DAO via the ‘setFeesRate’ function, and are automatically sent to the address provided by the DAO via the ‘setFeesRecipient’ function.
-
Pause/Unpause:
- To make the protocol more secure in case of a problem, we’ve added the possibility to pause the TKN mint/burn. This function can be called by emergency guardians as well as by the DAO via a vote. The mint/burn can be deactivated and reactivated via the ‘pause’ and ‘unpause’ functions.
Bridge Transaction Lifecycle Overview:
- Burn: If no TKN burn limit (due to OFT configuration) is reached, then the TKN is burned and the lz-TKN equivalent is minted. However, if the burn limit is reached, the user will not be able to start the bridge process.
- Send: The source chain OFT calls
lzSendon the source LayerZero Endpoint, providing the message payload and its unique path. - Verify: Configured DVNs independently verify the packet on the destination side using the destination MessageLib. After the packet is verified by the sufficient number of DVNs required by the Security Stack, it is committed to the destination Endpoint by an appropriate worker (a DVN, executor, or user).
- Execute: Endpoint ensures payload verification aligns with the OApp-configured Security Stack before committing to the channel. An executor invokes the
lzReceivefunction to process the received packet with the Receiver OFT’s logic. This step ensures the message is delivered exactly once and without loss. If the system cannot guarantee this, the process is reverted to prevent any possibility of censorship. - Mint: If no TKN mint limit (due to OFT configuration) is reached, then the lz-TKN is burned and the TKN equivalent is minted. However, if the mint limit is reached, the user will receive lz-TKN (which can be bridged again to another blockchain), or wait until the mint limits on the destination blockchain are no longer reached to burn its lz-TKN in exchange for TKN.
The Bridging Module codebase is available here, licensed under MIT License. It has been audited by Bail Security, with the costs of it supported by Mimo Labs. The report available is here.
If the bridging module is approved by the DAO, it will be available to users on a new dApp (still in beta) accessible here: https://app.parallel.best/bridge
The proposal goal is to validate the use of this proposed infrastructure as bridging module. Deployed chains, DVN(s) chosen & executors used will be discussed in upcoming proposals.
Means:
- Human Resources: Multisig signers will need to sign transactions to execute the proposal.
- Treasury Resources: No treasury resources used.
Technical implementation:
The technical implementation for both PAR & paUSD are being discussed in two separated proposals:
Voting Options:
- Accept the implementation of Tunnel, the Parallel Bridging Module
- Against/Rework the proposal
- Abstain
Author(s): Cooper Labs
Sentiment poll:
- Accept the implementation of Tunnel, the Parallel Bridging Module
- Against/Rework the proposal
- Abstain