# MIP-35┃Introducing Tunnel, the Parallel Bridging Module **URL:** \ **Category:** Approved PIPs\ **Created:** [October 8, 2024, 3:57pm UTC](https://gov.parallel.best/t/mip-35-introducing-tunnel-the-parallel-bridging-module/416 "2024-10-08T15:57:52Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![CooperLabs](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.parallel.best/cooperlabs/32/281_2.png) [@CooperLabs](https://gov.parallel.best/u/CooperLabs)\ **Post date:** [October 8, 2024, 3:57pm UTC](https://gov.parallel.best/t/mip-35-introducing-tunnel-the-parallel-bridging-module/416/1 "2024-10-08T15:57:52Z")
**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. ![](https://europe1.discourse-cdn.com/flex005/uploads/mimo1/original/1X/c76bf6aa54faca104a463f1f5a3f806d9944eb31.png) Although some solutions exist, such as [Jumper](https://jumper.exchange/), 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)](https://docs.layerzero.network/v2/home/modular-security/security-stack-dvns) and [Executors](https://docs.layerzero.network/v2/home/permissionless-execution/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](https://docs.layerzero.network/v2/home/v2-overview#x-of-y-of-n-message-authentication) and [independent execution](https://docs.layerzero.network/v2/home/v2-overview#independent-message-execution). ![](https://europe1.discourse-cdn.com/flex005/uploads/mimo1/original/1X/acdb3c987fa4a8fd2ae32afef2dfee5b8650acb8.png) **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](https://layerzeroscan.com/). **Tunnel, the Parallel Bridging Module Specifications:** - **OFT Standard:** - **Modular Security Stack:** - **Extensible:** - **Mint/Burn Limits:** - **Isolation Mode:** - **Fees:** - **Pause/Unpause:** **Bridge Transaction Lifecycle Overview:** ![](https://europe1.discourse-cdn.com/flex005/uploads/mimo1/original/1X/f1d331a384d5c216316497f3792e4be58b28a729.png) 1. **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. 2. **Send:** The source chain OFT calls `lzSend` on the source LayerZero Endpoint, providing the message payload and its unique path. 3. **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). 4. **Execute:** Endpoint ensures payload verification aligns with the OApp-configured Security Stack before committing to the channel. An executor invokes the `lzReceive` function 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. 5. **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](https://github.com/parallel-protocol/bridging-module), licensed under [MIT License](https://github.com/parallel-protocol/bridging-module/blob/main/LICENSE). It has been audited by Bail Security, with the costs of it supported by [Mimo Labs](https://twitter.com/mimo_labs). The report available is [here](https://github.com/parallel-protocol/bridging-module/blob/main/docs/audits/Bailsec%20-%20Parallel%20Bridge%20-%20BridgeableToken%20-%20Final%20Report.pdf). 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](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: - [MIP-35.1┃Deploy the PAR Bridging Module](https://gov.parallel.best/t/mip-35-1-deploy-the-par-bridging-module/417) - [MIP-35.2┃Deploy the paUSD Bridging Module](https://gov.parallel.best/t/mip-35-2-deploy-the-pausd-bridging-module/418) **Voting Options:** - Accept the implementation of Tunnel, the Parallel Bridging Module - Against/Rework the proposal - Abstain Author(s): Cooper Labs **Sentiment poll:** _Poll ([view on site](https://gov.parallel.best/t/mip-35-introducing-tunnel-the-parallel-bridging-module/416/1))_ ---
**Author:** ![CooperLabs](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.parallel.best/cooperlabs/32/281_2.png) [@CooperLabs](https://gov.parallel.best/u/CooperLabs)\ **Post date:** [October 14, 2024, 2:17pm UTC](https://gov.parallel.best/t/mip-35-introducing-tunnel-the-parallel-bridging-module/416/2 "2024-10-14T14:17:45Z")
The proposal is now live on Snapshot from October 14th at 5pm CET until October 21st at 5pm CET: [Snapshot](https://snapshot.org/#/mimo.eth/proposal/0x883149749741797afa4dfc1799868b46304c51f312b297e8a5a6e6fcb692e5b1) ---
**Author:** ![CooperLabs](https://dub1.discourse-cdn.com/flex005/user_avatar/gov.parallel.best/cooperlabs/32/281_2.png) [@CooperLabs](https://gov.parallel.best/u/CooperLabs)\ **Post date:** [October 24, 2024, 11:54am UTC](https://gov.parallel.best/t/mip-35-introducing-tunnel-the-parallel-bridging-module/416/3 "2024-10-24T11:54:34Z")
The vote has been approved by the DAO, result: [Snapshot](https://snapshot.org/#/mimo.eth/proposal/0x883149749741797afa4dfc1799868b46304c51f312b297e8a5a6e6fcb692e5b1)