Parallelbyjeanbrasse.eth

MIP-35┃Introducing Tunnel, the Parallel Bridging Module

Voting ended 7 months agoSucceeded

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:

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.