Summary:
The proposal aims to introduce and launch Parallel V3, a modular, scalable & decentralized stablecoins protocol.
Context:
Launched in 2021, Parallel pioneered by launching the first decentralized EUR stablecoin. It grew rapidly and then slowly declined over time, mainly due to the many limitations it has encountered over the years:
- Scalability: almost impossible to scale the supply of stablecoins without spending astronomical sums in incentives, mainly due to the architecture of the protocol, which is a collateralized debt protocol (CDP).
- Stability: Difficulty in maintaining a stable peg over time, mainly due to the lack of redeemability of the stablecoin against its collateral and the complexity of updating borrowing rates in correlation with market conditions.
- Upgradability: The protocol was designed to be partially upgradable, and this has been done several times over the years. However, it was very complicated to update securely, making any operation risky.
With this in mind, we decided it would be simpler to start from a fresh base to develop a V3. There were several options open to us:
- develop v3 from scratch
- fork an existing, proven protocol
Both for reasons of time (short) and cost (cheaper), it seemed unreasonable to redevelop an architecture that had already been developed dozens of times in the past by different protocols. So we decided to fork an existing protocol.
Starting October 2024, we got in touch with teams from several protocols to discuss an agreement to deploy a friendly fork. After several months of discussions, we reached an agreement with Angle Labs, the main developer of Angle Protocol, to deploy a licensed friendly fork of the Transmuter, their decentralized price stability module.
Rationale:
Parallel V3 is a stablecoins protocol allowing the creation of decentralized, capital-efficient and over-collateralized stablecoins built using a modular & upgradable architecture. The protocol consists of several different modules,which can be added or removed over time by the DAO, from which stablecoins can be issued or minted. Any type of stablecoin can be deployed on Parallel V3, for instance: USD, EUR, CHF, ETH, BTC, etc..
Parallel V3 is in majority a licensed friendly fork of Angle, with some in-house built modules (e.g. bridging module)
I. Parallel Modules
-
Parallelizer Module
a. Introduction
The Parallelizer Module is one of the main minting modules of Parallel stablecoins. It is conceived as a basket of different assets which can all be used to mint or burn the stablecoin at oracle value.
It comes with automated mechanisms to maintain the exposure to each asset in the reserves within reasonable bounds. This enables the system to properly segregate and diversify the risks between the assets in its backing, and guarantees at the same time that in case of a black swan event the system does not end up over-exposed to the weakest assets of its reserves.
The Parallelizer Module supports three main user actions: Mint, Burn and Redeem. The mint and burn actions rely on the idea that each asset in the reserves has a target price used to assess whether the asset is depegging and some conservative measure must be taken or not.
Practically speaking, the three operations work as follows:
- Mint: Stablecoins can be minted at oracle value from any of the supported assets with adaptive fees provided that the deviation of the asset used with respect to its target price is reasonable.
- Burn: Stablecoins can be burnt at oracle value for any of the assets in the backing with adaptive fees, provided that the deviation of all assets respective to their target price are reasonable. The idea is to avoid capital outflows changing the exposures of the system in times of uncertainty.
- Redeem: Stablecoins can be redeemed at any time against a proportional amount of each asset in the backing. Users should have a way to exit at any time, and so this feature is available in any conditions.
Built as an improvement of classic price stability modules (e.g. Sky) for stablecoin protocols, the Parallelizer system is designed with the following key properties:
-
Scalability: The Parallelizer enables minting and burning with limited fees from a wide range of assets. Its mechanisms work similarly with $1m TVL as with $1bn TVL.
-
Resilience: The underlying mechanisms of the Parallelizer system are all fully autonomous and predictable by all types of stakeholders. In case of a black swan event, the Parallelizer provides reasons to bet on the stablecoin returning to its target price.
-
Trustlessness: The Parallelizer is able to autonomously withstand unforeseen events, such as collateral depegs or hacks, without requiring any governance intervention.
-
Fairness: There cannot be any bank run as redemptions are thought to break sequentiality between users.
-
Robustness: The Parallelizer can be used as a basket of different stablecoins or assets allowing collateral risk to be well diversified.
-
Safety: If fees are properly set, the design provides incentives to bring the basket of reserves to a target desired allocation. In case of a depeg, it is unprofitable to perform trades that leave the protocol holding weak assets.
-
Gas-efficiency: Thanks to a range of different optimizations, the system is able to minimize the gas needed to interact with it.
-
Modularity: The system can not only accept any type of asset in the backing, its implementation is such that it can work for any type of stablecoin. On top of that, it is fully compatible with the other protocol’s minting modules: it works in parallel with the bridging module, savings module & flashloan module.
b. Mint & Burn
In the Parallelizer, it is possible to mint and burn the stablecoin for any of the asset in the collateral at a variable price. On top of the current oracle value of the asset, the price at which mints or burns happen also depend on whether the asset that is used is currently depegging or not.
Practically, this is done by tracking for each asset in the backing a target price denominated in the stablecoin’s base currency. This target value for a collateral can be either absolute or updated relatively frequently.
The stablecoin can be burnt for any asset in the backing. Contrarily to the mint case, the price at which the stablecoin is burnt does not only depend on the price of the asset for which it is burnt, it also depends on the price of all the other stablecoins in the backing.
For all assets in the backing, the system looks into their deviation with respect to their target price and then applies to the burn price a penalty equal to the largest deviation possible.
In its normal state, the stablecoin can be burnt for any of the assets in the system at their fair value which guarantees a small slippage for burning the asset. But in case of a depeg of one of the asset in the backing, this mechanism is meant to preserve the system’s exposures to all assets.
As the stablecoin can be burnt for the same value of assets regardless of the asset it is burnt for, it disincentivizes stablecoin holders from rushing to exit towards the safest asset.
The availability of these mint and burn functions allow any arbitrageur to take advantage of price deviations of the stablecoin on the secondary market to bring the stablecoin back to peg.
While the values at which mints and burns are taking place are one way for the Parallelizer system to control its relative exposures to the assets it has in reserves, the Parallelizer also relies on a variable fee mechanism to enable exposure to each asset to converge to a target area. Contrarily to the redemption case, a mint or a burn for one asset affects the system’s exposure to all its backing assets.
And so fees for a mint or burn operation depend on the exposure to the concerned asset after the operation, as a way to prevent the exposure from going beyond certain lower and upper limits.
For instance, mint fees can be set to a high value (100%) when the exposure is above a target exposure, while burn fees can be made low to incentivize reducing the exposure. Conversely, when exposure to an asset is below the target window, mint fees can be set low and burn fees high to incentivize users to increase the system’s exposure to this asset.
With this, it is still possible that exposures go over the bounds where for instance mint fees reach 100%. The reason is that when you burn for an asset, you’re mathematically increasing the exposures to all other assets in the system.
Assume the system is targeting a 40% maximum exposure for a stablecoin USDb, and so far 33 USDp have been issued with USDa, 33 with another stablecoin USDc and 33 with USDyield, then someone burning 15 USDp for USDyield would bring the exposure to USDb to above 40%. It should be at this point impossible to mint USDp with USDb, but burning USDp for USDb should come at a low cost.
In the Parallelizer, there can be negative fees to incentivize people to come with a certain asset. The system however verifies that this does not open arbitrage loops. It is impossible to set negative mint fees if these are in absolute value bigger than the positive burn fees for all the other assets in the system.
Below is an example of how a rebalancing operation may look like in the case of USDp:
c. Redeem
The redeem feature allows users to exchange their stablecoins for a proportional share of the underlying reserve assets at any time. This mechanism is designed to ensure fairness, especially during market stress scenarios, by preventing early redeemers from gaining an advantage over others.
-
Proportional Distribution: Upon redemption, users receive a mix of reserve assets proportional to their share of the total stablecoins, adjusted by a penalty factor. This ensures that no single user can deplete specific assets, maintaining system balance.
-
Penalty Factor: A dynamic penalty is applied during redemption, particularly when the system’s collateral ratio falls below 100%. This serves to:
- Deter Bank Runs: Users receive less than the fair value if they attempt mass redemptions during downturns.
- Incentivize Stability: Encourages users to hold their stablecoins, allowing the system time to recover.
For example, if the collateral ratio drops to 98.5% due to a depeg, and the penalty factor is set to 0.98, a user redeeming 10 USDp might receive assets worth approximately $9.65 instead of $9.85, thereby contributing to the protocol’s re-collateralization.
The figures below show the effect of burning with respect to redeeming in different collateral ratio settings:
d. Collateral Whitelist
The Parallizer can handle assets requiring permissioned holders. Certain collateral assets can be whitelisted, meaning only specific addresses are allowed to burn them for stablecoins or receive them during redemptions. This is particularly relevant for security tokens with restricted transferability.
The presence of whitelisted assets limits the full functionality and fairness of Parallelizer to whitelisted addresses only.
For example, if whitelisted collateral represents 20% of a fully collateralized protocol, a non-whitelisted address redeeming stablecoins would only receive 80% of the equivalent value (as they cannot receive the whitelisted token), whereas a whitelisted address would receive 100%. Non-whitelisted addresses can still burn stablecoins for non-whitelisted collateral.
Since redemption is primarily intended for sophisticated market makers and arbitrageurs (who are likely to be whitelisted), incorporating whitelisted collateral adds complexity to the redemption process but does not hinder Parallelizer’s ability to maintain the stablecoin’s price parity with its reserves on the secondary market.
Whitelist management can vary depending on the asset and is typically overseen by protocol governance or external trusted systems.
2. Savings Module
The Parallel Savings Module is what allows Parallel stablecoin holders to earn a native yield based on the returns generated by the protocol on its assets backing the stablecoin. It does not come with any extra composability risk, and there are no additional trust assumptions between owning an Parallel stablecoin and its staked version.
The yield rate that is paid by the Savings Module on a stablecoin depends on the return over assets the protocol is generating for this asset. Assuming all stablecoins are in the Savings contracts, and assuming no cut taken by the protocol, the protocol could pay up to this return over assets to all stablecoin holders.
The yield that is allocated through these contracts is generated by the assets held by the protocol across its different modules:
- Parallelizer Module
- Flashloan Module
- Bridging Module
The rate schedule above cannot be implemented automatically in a non manipulative way, and the protocol relies on keepers to adjust it.
Savings modules smart contracts are simple ERC4626 contracts, which means that upon staking an Parallel stablecoin in a savings contract you receive a classical ERC20 token that can then be transferred, staked, lent or used in any way you want.
The value of these tokens is not designed to remain pegged to their respective underlying asset, but increases over time as yield accrues to it.
While you may be able to acquire staked tokens on DEXes, there is no need to, and depositing Parallel stablecoins can be done without any slippage directly with the staking smart contract.
This system comes with no deposit or withdrawal fees. And upon depositing in it, you immediately start earning. For instance 1 stablecoin deposited in a savings contract and withdrawn after a 12s block would have earned the equivalent of 12s of the yearly rate encoded in the contract.
3. Bridging Module:
The Bridging Module is entirely based on the Parallel V2 Bridging Module (Tunnel), which is live on Ethereum, Polygon PoS & Fantom since November 2024. The Bridging Module was originally designed to be used in future versions of the protocol without any changes, thus not requiring additional audits, and therefore additional costs.
a. 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.
b. 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.
c. 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.
d. 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.
- 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:
- 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. The isolation mode makes it impossible to burn more stablecoins on the blockchain Y than what has been bridged from the other chains.
- 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.
-
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.
4. Flashloan Module:
Flash loans (also called One Block Borrows) are special transactions that allow the borrowing of an asset, as long as the borrowed amount (and a fee) is returned before the end of the transaction. These transactions do not require a user to supply collateral prior to engaging in the transaction. The innovation is that stablecoins given out in flash loans are minted during the flash-loan transaction and burnt at the end of it: this means that the size of the flash loans taken is not capped by an amount of liquidity in a pool but rather by a parameter chosen by governance.
Like done elsewhere, flash-loan transactions are only valid when the amount borrowed by the address taking the flash-loan is returned plus a fee (governance could vote to set no fees) at the end of the transaction. There could also be a cap on the size of the flash-loan taken.
Flash loans of Parallel stablecoins may serve different use cases like arbitrage between assets without needing the principal amount to execute the arbitrage. Overall, it improves the general market efficiency for Parallel stablecoins.
Parallel introduces for each stablecoin different parameters defining the fees that can be taken at each flash-loan and the maximum size allowed for a flash-loan. These parameters can be modified by governance votes.
II. Governance
While the main functionalities of Parallel V3 can work autonomously with no governance involved, Parallel V3 is not a governance-free protocol and is controlled by sPRL holders.
The protocol governance must be involved to:
- Deploy a new stablecoin
- Deploy the Protocol on a new chain
- Add/remove new minting modules
- Add/remove collateral assets to its backing
- Adjust the fee parameters that determine the target and maximum exposures to each asset
- Adjust oracle parameters
- Adjust Parallelizer module parameters
- Adjust Savings module parameters
- Adjust Bridging module parameters
- Adjust Flashloan module parameters
- Deploy an upgrade of the Protocol
III. Codebase Licenses
Parallel V3 is divided into 3 different repositories, each with different licenses:
- parallel-core: Licensed under MIT license, available here. Basically, you can do whatever you want as long as you include the original copyright and license notice in any copy of the software/source. The license includes the AccessManager contract.
- parallel-tokens: The license includes the stablecoins token contracts, as well as the Bridging & Flashloan modules.
- parallel-parallelizer: Licensed Friendly Fork of Angle Protocol codebase. Released under Business Source License 1.1 (BUSL 1.1) with rights granted to Mimo Labs & Cooper Labs to use the license for commercial purposes via a signed License and Fee-sharing Agreement. This agreement does not engage the Parallel DAO into anything. The license includes the Parallelizer & Savings modules.
IV. Fee Sharing
The parallel-parallelizer repository is a licensed-friendly fork of Angle Protocol’s Transmuter. The licenses have been granted to Mimo Labs and Cooper Labs without any financial remuneration. It is however mentioned in the agreement that Cooper Labs and Mimo Labs would propose to the Parallel DAO to share part of the fees generated by the licensed friendly fork, up to 1% of the fees generated until the licenses expire.
We therefore propose that the Parallel DAO share 1% of the fees generated by the parallel-parallelizer repository until the license expires on June 1, 2026.
V. Audits
While Parallel V3 is for the majority of the codebase a licensed friendly fork of the Angle Protocol, which is already audited and in production since 2 years, we decided to conduct an additional audit performed by Bail Security (audit report available here) and a partial formal verification performed by Certora (partial formal verification report available here).
In agreement with Mimo Labs, they decided to cover the costs of the audit & partial formal verification prior to the approval and production deployment of Parallel V3. The total cost for it is $200k. Bail Security audit invoice can be found here ($120k), Certora partial formal verification invoice can be found here ($80k).
We are requesting the DAO to reimburse the costs of the audit & partial formal verification for an amount of $200,000.
Note: Mimo Labs does not make any profit from this reimbursement.
Means:
- Human Resources: Multisig signers will need to sign transactions to execute the proposal.
- Treasury Resources: $200,000 worth of PAR/paUSD/USDC on Ethereum to Mimo Labs.
Technical implementation:
For each stablecoin and on each chain where the protocol will be deployed:
- Core Protocol:
- Deploy the AccessManager contract
- Deploy TokenP contract
- Set targetSelector of TokenP contract to TokenP_MINTER_ROLE by calling the accessManager
- Parallelizer Module:
- Deploy All facets
- Deploy DiamondInitializer if not deployed (used to initialize the Parallelizer)
- Deploy Paralleliser with the following collaterals config:
- Collateral1:
- Oracle:
- oracleType
- targetType
- quoteType
- stalePeriods
- chainlinkDecimals
- Hyperparameters:
- xMintFee
- yMintFee
- xBurnFee
- yBurnFee
- RedemptionSetup:
- xRedeemFee
- yRedeemFee
- Oracle:
- Collateral1:
- Set targetSelector of Parallelizer contract to GUARDIAN_ROLE and GOVERNOR_ROLE
- Grant TokenP_MINTER_ROLE to the Paralleliser by calling the accessManager
- Savings Module:
- Deploy sTokenP
- Set targetSelector of sTokenP to GUARDIAN_ROLE and GOVERNOR_ROLE
- Grant TokenP_MINTER_ROLE to the sTokenP by calling the accessManager
- Bridging Module:
- Deploy BridgeableTokenP contract
- Setup Peer and DVNs to link BridgeableTokenP with others chains
- Set targetSelector of BridgeableTokenP contract to GUARDIAN_ROLE and GOVERNOR_ROLE
- Grant TokenP_MINTER_ROLE to the BridgeableTokenP by calling the accessManager
- Flashloan Module:
- Deploy FlashParallelToken contract
- Set targetSelector of FlashParallelToken contract to GOVERNOR_ROLE
- Grant TokenP_MINTER_ROLE to the FlashParallelToken by calling the accessManager
Voting options:
- For the Launch of Parallel V3
- Against / Rework the Proposal
- Abstain
Sentiment poll:
- For Launch of Parallel V3
- Against/Rework the proposal
- Abstain
Author(s): Cooper Labs
