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.