# Parallel Documentation Public documentation of the Parallel stablecoin protocol — USDp, sUSDp, PRL, multi-chain. Enter the Parallel World # Overview ## **Introduction** **Parallel** is a decentralized, modular stablecoins protocol with different entities and individuals contributing to its development and adoption. As a result, the documentation refers to different areas of “Parallel” which are worth distinguishing. * **Parallel Protocol**:\ A decentralized, non-custodial stablecoins protocol implemented for the Ethereum Virtual Machine. * **Parallel Interfaces**:\ Multiple web interfaces allowing easy interaction with the Parallel Protocol. Those interfaces are ways to interact with the Parallel protocol. * **Parallel Governance**:\ A governance system for governing the Parallel Protocol, enabled by the [PRL Token](/governance/parallel-governance-token-prl). ## Parallel Parallel is a capital-efficient, modular stablecoins protocol that allows the creation of over-collateralized, decentralized stablecoins. The protocol comes with EVM smart contracts which facilitate interactions and integrations. ### Overview Parallel 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, for instance: USD, EUR, CHF, ETH, BTC, etc.. Parallel is licensed under [BUSL-1.1](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/LICENSE) & [MIT](https://github.com/parallel-protocol/parallel-core/blob/main/LICENSE.md). Once deployed, Parallel will function in perpetuity, provided by the existence of the blockchain and their dependencies. ### Key Concepts Stablecoins in Parallel involves: * **Collateralization**: Stablecoins are backed by an overcollateralized basket of correlated assets. * **Depeg Protection**: The protocol automatically adjusts fees and penalties when an asset deviates from its target value. * **Modularity:** The protocol operates through independent minting modules that can be activated or modified by the DAO. * **Open Participation**: Anyone can mint or burn stablecoins through the protocol. # Products ## Stablecoins Parallel stablecoins are decentralized stable currencies issued by the protocol. Their issuance is handled through minting modules, such as the Parallelizer Module, where users deposit an overcollateralized basket of assets (such as ETH, BTC, or other stablecoins) to mint new tokens. Each stablecoin ([USDp](/products/parallel-v3/stablecoins-and-savings/usdp-and-susdp), etc.) can be configured independently with its own parameters, including the types of assets accepted as collateral, the fees applied, and the exposure limits set by the DAO. To ensure price stability, the protocol automatically adjusts minting or burning fees whenever the token deviates from its reference currency. In practice, these stablecoins form the core of the Parallel system and serve as the foundation for all other ecosystem products. Discover USDp ## Savings Savings tokens are the “yield-bearing” versions of Parallel stablecoins. When a user deposits a standard stablecoin, such as [USDp](/products/parallel-v3/stablecoins-and-savings/usdp-and-susdp), they receive its Savings equivalent, like sUSDp. This token represents a staked position that automatically accrues yield over time. The yield comes from the protocol’s revenues, such as fees from minting and burning operations or stablecoin reserve management. The calculation and distribution of these yields are managed by “keepers”, actors designated by the DAO to guarantee transparency and consistency. As a result, Savings tokens allow users to grow their stablecoin holdings without leaving the Parallel ecosystem, while benefiting from a simple and integrated mechanism. Discover sUSDp # Use Cases ## Stablecoins * **Payments & Transfers**: Users can send and receive money globally in a stable currency (USDp, etc.) without being exposed to crypto volatility. * **Trading & Liquidity**: They can be used on decentralized exchanges (DEXs) as a stable trading pair or liquidity pool asset. * **Collateral in DeFi**: Stablecoins can serve as collateral in lending protocols, derivatives platforms, or yield farming strategies. * **Multi-Currency Options**: By supporting several fiat references (USD, EUR…), Parallel stablecoins open the door to diversified currency usage in DeFi. ## Savings * **Passive Income**: Users can hold Savings tokens (eg. sUSDp) to automatically earn interest without actively managing positions. * **Safe Yield Alternative**: Provides a decentralized alternative to traditional savings accounts, especially attractive in countries with low bank interest rates. * **Integration in DeFi**: Savings tokens can be used in DeFi protocols (as collateral, in pools, or strategies) while continuing to accrue yield. * **Long-Term Store of Value**: They allow users to park funds safely over time, combining stability (via the peg) and growth (via yield). # Parallel V3 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 using Parallel V3, for instance: [USD](/products/parallel-v3/stablecoins-and-savings/usdp-and-susdp), EUR, CHF, ETH, BTC, etc..

High Level Architecture

# How It Works Parallel V3 is designed as a modular and scalable system where each functional component exists as an independent module. These modules can be deployed, upgraded, paused, or reconfigured without disrupting the entire protocol. This gives the opportunity to launch multiple stablecoins (USDp, EURp, etc.), customize their parameters, and extend functionality over time.

Parallel Stablecoins Minting Modules

# Parallelizer Module ## 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.

Parallelizer Module

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. ## 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.

Parallel Stability Mechanism

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.

Parallel Stability Mechanism

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.

Parallelizer Exposure Control

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:

Parallelizer Rebalancing

## 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:

Burning versus Redeeming in different cases

Burning versus Redeeming in different cases

## 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. # 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

Parallel Savings Yield & Multiplier Effect

The rate schedule above cannot be implemented automatically in a non manipulative way, and the protocol relies on keepers to adjust it. In order to prevent any potential keeper from turning malicious and uncontrollably increasing the sUSDp rate, there is a possibility to set a maximum possible rate on Savings module. 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. # Bridging Module The Bridging Module is entirely based on the Parallel V2 [Bridging Module](/products/parallel-v2/how-it-works/bridging-module), 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. ## 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](#decentralized-verifier-networks-dvns)) and Executors, LayerZero enables different blockchains to seamlessly interact with one another.

LayerZero Infrastructure

## 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. ## 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/). ## 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](https://docs.layerzero.network/v2/developers/evm/oft/quickstart). ### 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](https://layerzeroscan.com/protocol/parallel-protocol) 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](/security/parallel-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

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 `lzSend` on 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 `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. **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. # 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.

Flash Loans Explained

:::info 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. ::: # Stablecoins & Savings ## Stablecoins Parallel stablecoins are decentralized stable currencies issued by the protocol. Their issuance is handled through minting modules, such as the Parallelizer Module, where users deposit an overcollateralized basket of assets (such as ETH, BTC, or other stablecoins) to mint new tokens. Each stablecoin ([USDp](/products/parallel-v3/stablecoins-and-savings/usdp-and-susdp), etc.) can be configured independently with its own parameters, including the types of assets accepted as collateral, the fees applied, and the exposure limits set by the DAO. To ensure price stability, the protocol automatically adjusts minting or burning fees whenever the token deviates from its reference currency. In practice, these stablecoins form the core of the Parallel system and serve as the foundation for all other ecosystem products. ## Savings The Parallel Savings product 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. # USDp & sUSDp ## USDp USDp is the USD stablecoin of Parallel V3. It is a decentralized, overcollateralized asset backed by a basket of cryptocurrencies and stablecoins, including yield-bearing versions such as sfrxUSD or sUSDe. The issuance and redemption of USDp are currently managed by Parallel modules. USDp is currently deployed on these chains: | Blockchain | Contract Address | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [0x9B3a8f7CEC208e247d97dEE13313690977e24459](https://etherscan.io/address/0x9B3a8f7CEC208e247d97dEE13313690977e24459#code) | | Base | [0x76A9A0062ec6712b99B4f63bD2b4270185759dd5](https://basescan.org/address/0x76A9A0062ec6712b99B4f63bD2b4270185759dd5#code) | | Sonic | [0x08417cdb7F52a5021bB4eb6E0deAf3f295c3f182](https://sonicscan.org/address/0x08417cdb7F52a5021bB4eb6E0deAf3f295c3f182#code) | | HyperEVM | [0xbe65f0f410a72bec163dc65d46c83699e957d588](https://hyperevmscan.io/address/0xbe65f0f410a72bec163dc65d46c83699e957d588#code) | | Avalanche | [0x9eE1963f05553eF838604Dd39403be21ceF26AA4](https://snowscan.xyz/address/0x9ee1963f05553ef838604dd39403be21cef26aa4#code) | | Polygon | [0x1250304F66404cd153fA39388DDCDAec7E0f1707](https://polygonscan.com/address/0x1250304F66404cd153fA39388DDCDAec7E0f1707#code) | | Arbitrum | [0x76A9A0062ec6712b99B4f63bD2b4270185759dd5](https://arbiscan.io/address/0x76A9A0062ec6712b99B4f63bD2b4270185759dd5#code) | | Optimism | [0x90337e484B1Cb02132fc150d3Afa262147348545](https://optimistic.etherscan.io/address/0x90337e484B1Cb02132fc150d3Afa262147348545#code) | | Sei | [0x048C4e07D170eEdEE8772cA76AEE1C4e2D133d5c](https://seiscan.io/address/0x048C4e07D170eEdEE8772cA76AEE1C4e2D133d5c#code) | | Binance Smart Chain | [0x048C4e07D170eEdEE8772cA76AEE1C4e2D133d5c](https://bscscan.com/address/0x048C4e07D170eEdEE8772cA76AEE1C4e2D133d5c#code) | | Berachain | [0x9eE1963f05553eF838604Dd39403be21ceF26AA4](https://berascan.com/address/0x9eE1963f05553eF838604Dd39403be21ceF26AA4#code) | | Scroll | [0x9eE1963f05553eF838604Dd39403be21ceF26AA4](https://scrollscan.com/address/0x9eE1963f05553eF838604Dd39403be21ceF26AA4#code) | | Gnosis | [0x9eE1963f05553eF838604Dd39403be21ceF26AA4](https://gnosisscan.io/address/0x9eE1963f05553eF838604Dd39403be21ceF26AA4#code) | | Unichain | [0x9eE1963f05553eF838604Dd39403be21ceF26AA4](https://uniscan.xyz/address/0x9eE1963f05553eF838604Dd39403be21ceF26AA4#code) | | Ink | [0x9eE1963f05553eF838604Dd39403be21ceF26AA4](https://explorer.inkonchain.com/address/0x9eE1963f05553eF838604Dd39403be21ceF26AA4?tab=contract) | | Tac | [0x4DeF531c3060686948f00EcC7504f2E0b71EDa14](https://explorer.tac.build/address/0x4DeF531c3060686948f00EcC7504f2E0b71EDa14?tab=contract) | | Linea | [0x8fCf9118fdD359f6277cDd143c2Da206e64140F3](https://lineascan.build/address/0x8fCf9118fdD359f6277cDd143c2Da206e64140F3#code) | | X Layer | [0x8fCf9118fdD359f6277cDd143c2Da206e64140F3](https://www.oklink.com/fr/x-layer/address/0x8fCf9118fdD359f6277cDd143c2Da206e64140F3/contract) | | Plume | [0x8fCf9118fdD359f6277cDd143c2Da206e64140F3](https://explorer.plume.org/address/0x8fCf9118fdD359f6277cDd143c2Da206e64140F3?tab=contract) | | Plasma | [0xC2f8B5d893217462aE9c9879c9285A5a3AAbcb8F](https://plasmascan.to/address/0xC2f8B5d893217462aE9c9879c9285A5a3AAbcb8F#code) | | Katana | [0x8fCf9118fdD359f6277cDd143c2Da206e64140F3](https://katanascan.com/address/0x8fCf9118fdD359f6277cDd143c2Da206e64140F3#code) | | Fraxtal | [0x8fCf9118fdD359f6277cDd143c2Da206e64140F3](https://fraxscan.com/address/0x8fCf9118fdD359f6277cDd143c2Da206e64140F3#code) | | World | [0x8fCf9118fdD359f6277cDd143c2Da206e64140F3](https://worldscan.org/address/0x8fCf9118fdD359f6277cDd143c2Da206e64140F3#code) | | Hemi | [0x8fCf9118fdD359f6277cDd143c2Da206e64140F3](https://explorer.hemi.xyz/address/0x8fCf9118fdD359f6277cDd143c2Da206e64140F3?tab=contract) | ## Staked USDp sUSDp is the yield-bearing version of USDp, the stablecoin of Parallel V3. When a user deposits USDp into the Savings Module (an ERC-4626 vault), they receive sUSDp in return. This token represents their claim on the deposited USDp plus the yield generated by the protocol. sUSDp is currently deployed on these chains: | Blockchain | Contract Address | | ---------- | ----------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [0xd3a452b305c8285c0dd7b8537665c734d3d279ef](https://etherscan.io/address/0xd3a452b305c8285c0dd7b8537665c734d3d279ef#code) | | Base | [0x472ed57b376fe400259fb28e5c46eb53f0e3e7e7](https://basescan.org/address/0x472ed57b376fe400259fb28e5c46eb53f0e3e7e7#code) | | Sonic | [0xe8a3da6f5ed1cf04c58ac7f6a7383641e877517b](https://sonicscan.org/address/0xe8a3da6f5ed1cf04c58ac7f6a7383641e877517b#code) | | HyperEVM | [0x9b3a8f7cec208e247d97dee13313690977e24459](https://hyperevmscan.io/address/0x9b3a8f7cec208e247d97dee13313690977e24459#code) | | Avalanche | [0x9d92c21205383651610f90722131655a5b8ed3e0](https://snowscan.xyz/address/0x9d92c21205383651610f90722131655a5b8ed3e0#code) | # Implementation ## Parallelizer Module The Parallelizer Module, which is going to serve as the main minting module, is deployed on what we believe to be the main drivers for growth for the protocol. Tokens allowed in the backing of USDp have been carefully reviewed for their stability, robustness, sustainable yield generation and business development potential. Allowed assets and their parameters can be updated at any time by the DAO. The Parallelizer Module is deployed on several initial chains with these parameters: * **Ethereum:** * **frxUSD:** * Price Feed: [Chainlink frxUSD/USD](https://etherscan.io/address/0x9B4a96210bc8D9D55b1908B465D8B0de68B7fF83#code) * Minimum Exposure: 0.00% * Maximum Exposure: 100.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.00% * Mint Cap: 100,000,000.00 * **sfrxUSD:** * Price Feed: [sfrxUSD/frxUSD Exchange Rate](https://etherscan.io/address/0xcf62F905562626CfcDD2261162a51fd02Fc9c5b6#code) + [Chainlink frxUSD/USD](https://etherscan.io/address/0x9B4a96210bc8D9D55b1908B465D8B0de68B7fF83#code) ([MorphoChainlinkOracleV2](https://etherscan.io/address/0x0cB7dEe76aA916A3666F50b044f16051C325B3E2#code)) * Minimum Exposure: 20.00% * Maximum Exposure: 95.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.05% * Mint Cap: 100,000,000.00 * **USDe:** * Price Feed: [Chainlink USDe/USD](https://etherscan.io/address/0xa569d910839Ae8865Da8F8e70FfFb0cBA869F961#code) * Minimum Exposure: 0.00% * Maximum Exposure: 100.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.00% * Mint Cap: 100,000,000.00 * **sUSDe:** * Price Feed: [Chainlink sUSDe/USD](https://etherscan.io/address/0xFF3BC18cCBd5999CE63E788A1c250a88626aD099#code) * Minimum Exposure: 20.00% * Maximum Exposure: 95.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.05% * Mint Cap: 100,000,000.00 * **Base:** * **USDS:** * Price Feed: [Chainlink USDS/USD](https://basescan.org/address/0x2330aaE3bca5F05169d5f4597964D44522F62930#code) * Minimum Exposure: 0.00% * Maximum Exposure: 100.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.00% * Mint Cap: 100,000,000.00 * **sUSDS:** * Price Feed: [sUSDS/USDS Exchange Rate](https://basescan.org/address/0x906B24a339b848369B24Dc9Ed368b947fB9693bf#code) + [Chainlink USDS/USD](https://basescan.org/address/0x2330aaE3bca5F05169d5f4597964D44522F62930#code) ([MorphoChainlinkOracleV2](https://basescan.org/address/0x965018CbDdC4683EfA22998C324C399D7C7B0E51#code)) * Minimum Exposure: 20.00% * Maximum Exposure: 95.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.05% * Mint Cap: 100,000,000.00 * **HyperEVM:** * **USDe:** * Price Feed: [Redstone USDe/USD](https://hyperevmscan.io/address/0xca727511c9d542aab9ef406d24e5bbbe4567c22d#code) * Minimum Exposure: 0.00% * Maximum Exposure: 100.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.00% * Mint Cap: 100,000,000.00 * **sUSDe:** * Price Feed: [Redstone sUSDe/USD](https://hyperevmscan.io/address/0xFf8D73F413F0093A14190A987883B5101D7855Dd#code) * Minimum Exposure: 20.00% * Maximum Exposure: 95.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.05% * Mint Cap: 100,000,000.00 * **Avalanche:** * **USDC:** * Price Feed: [Chainlink USDC/USD](https://snowscan.xyz/address/0xF096872672F44D6EBA71458D74Fe67F9A77A23B9#code) * Minimum Exposure: 0.00% * Maximum Exposure: 100.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.00% * Mint Cap: 100,000,000.00 * **ygamiUSDC Silo Vault: (wrapped as a Yearn Vault)** * Price Feed: [Vault Share Exchange Rate](https://snowscan.xyz/address/0x9fD32FD5e32C6B95483d36C5E724C5C5250Ce010#code) + [Chainlink USDC/USD](https://snowscan.xyz/address/0xF096872672F44D6EBA71458D74Fe67F9A77A23B9#code) ([MorphoChainlinkOracleV2](https://snowscan.xyz/address/0x338Dab2A67193C1E8E53506Ae34552B588DB2A44#code)) * Minimum Exposure: 20.00% * Maximum Exposure: 95.00% * Whitelisted: No * Stale Period: 86,400 seconds * Mint Fee: 0.00% * Burn Fee: 0.05% * Mint Cap: 100,000,000.00 ## Savings Module The Savings USDp, which is called sUSDp is deployed on several chains. The Savings USDp will act as a low risk yield bearing with real yield coming from assets generating yield in the backing of USDp. Main use cases include, but are not limited to wallet integration for one click USD saving account & collateral asset in lending protocols. As mentioned previously, savings rates aren’t automatically updated and need to be updated by a keeper. Cooper Labs and Mimo Labs have been approved as keepers. :::info In order to prevent any potential keeper from turning malicious and uncontrollably increasing the sUSDp rate, the maximum possible rate of sUSDp has been set at 35.00% ::: The Savings Module is deployed on several initial chains with these parameters including: * Ethereum * Base * HyperEVM * Avalanche ## Bridging Module Deploying the Bridging Module on all the chains where the core protocol is deployed is allowing USDp to freely move across any chain, including those where the Parallelizer Module is not deployed. This is also enabling contributors to move forward extremely quickly in terms of integration and business development, requiring no additional development work to deploy the token on a lending protocol or DEX. The Bridging Module is deployed on several initial chains with these parameters including: * **Ethereum:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Base:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Sonic:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **HyperEVM:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Avalanche:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Binance Smart Chain:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Optimism:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Arbitrum:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Polygon PoS:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Sei:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Berachain:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Scroll:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Gnosis:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Unichain:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Ink:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Tac:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Linea:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **X Layer:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Plume:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Plasma:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Katana:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Fraxtal:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **World:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No * **Hemi:** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Horizen * Canary * Mint Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Burn Limits: * Daily: 2,500,000.00 * Global: 10,000,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No ## Flashloan Module Flashloans play an important role in Parallel V3, enabling USDp assets in backing to be rebalanced in the Parallelizer Module, and allowing future USDp liquidity pools to be arbitraged in order to maintain the best price between all pools. To facilitate these operations, the flashloan module is deployed on all chains where the core protocol is also deployed. Fees will be sent to the FeeCollector contract in order to be redistributed. Below are current DAO-approved parameters:
BlockchainMaximum AmountFee (%)
Ethereum100,000.000.00
Base100,000.000.00
Sonic100,000.000.00
HyperEVM100,000.000.00
Avalanche100,000.000.00
Binance Smart Chain100,000.000.00
Optimism100,000.000.00
Arbitrum100,000.000.00
Polygon PoS100,000.000.00
Sei100,000.000.00
Berachain100,000.000.00
Scroll100,000.000.00
Gnosis100,000.000.00
Unichain100,000.000.00
Ink100,000.000.00
Tac100,000.000.00
Linea100,000.000.00
X Layer100,000.000.00
Plume100,000.000.00
Plasma100,000.000.00
Katana100,000.000.00
Fraxtal100,000.000.00
World100,000.000.00
Hemi100,000.000.00
# Fee Distribution Parallel V3 generated fees by the USDp codebase are distributed as follow: | Receiving Fees | Fee Distributed (%) | | -------------- | ------------------- | | sUSDp | 90.00 | | DAO Treasury | 10.00 | # 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](/governance/sprl). 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 # Licensing Parallel V3 is divided into 3 different repositories, each with different licenses: * [parallel-core](https://github.com/parallel-protocol/parallel-core): Licensed under MIT license, available [here](https://github.com/parallel-protocol/parallel-core/blob/main/LICENSE.md). 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](https://github.com/parallel-protocol/parrallel-tokens): Licensed under MIT license, available [here](https://github.com/parallel-protocol/parrallel-tokens/blob/main/LICENSE). 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 stablecoins token contracts, as well as the Bridging & Flashloan modules. * [parallel-parallelizer](https://github.com/parallel-protocol/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](https://github.com/parallel-protocol/parallel-parallelizer/blob/audit/bailsec-april-2025/Parallel_x_Angle___Licensing_agreement_redacted.pdf). In [PIP-50](https://gov.parallel.best/t/pip-50-l-introducing-parallel-v3-a-modular-scalable-decentralized-stablecoins-protocol/475), it was approved that 1% of the fees generated by the licensed friendly fork (parallel-parallelizer [repositery](https://github.com/parallel-protocol/parallel-parallelizer)) will be allocated to Angle Labs until the license expires on June 1, 2026. # Parallel V2 :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Parallel V2 is a decentralized protocol that issues stablecoins, the € stablecoin ([PAR](https://docs.parallel.best/parallel-protocol/parallel-v2/par)) and the $ stablecoin ([paUSD](https://docs.parallel.best/parallel-protocol/parallel-v2/par-1)), on the Ethereum, Polygon and Fantom blockchains. The [PAR](https://docs.parallel.best/parallel-protocol/parallel-v2/par) & [paUSD](https://docs.parallel.best/parallel-protocol/parallel-v2/par-1) stablecoin are decentralized, non-custodials, and collateral-backed FIAT stablecoins. # Stablecoins :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: # PAR :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: PAR is a EURO stablecoin backed by collaterals, and can only be minted with governance-approved collaterals. PAR are created when users deposit accepted tokens (such as WETH, WBTC, USDC, etc) as collateral in vaults and in turn receive a loan against that collateral. **Token Symbol:** PAR | Blockchain | Contract Address | | ----------- | ---------------------------------------------------------------------------------------------------------------------- | | Ethereum | [0x68037790a0229e9ce6eaa8a99ea92964106c4703 ](https://etherscan.io/token/0x68037790a0229e9ce6eaa8a99ea92964106c4703) | | Polygon PoS | [0xe2aa7db6da1dae97c5f5c6914d285fbfcc32a128](https://polygonscan.com/token/0xe2aa7db6da1dae97c5f5c6914d285fbfcc32a128) | | Fantom | [0x13082681E8CE9bd0aF505912d306403592490Fc7](https://ftmscan.com/token/0x13082681E8CE9bd0aF505912d306403592490Fc7) | ### PAR is non-custodial There are no counterparties involved in the minting and burning of PAR tokens, as actors in the network transact directly with the PAR smart contracts. Vaults are non-custodial, with each borrower having full control over their collateral and borrowed PAR balances, provided it meets the minimum health factor governed by the protocol as a whole. :::info You can use PAR to earn yield by Providing Liquidity. ::: # How does PAR work? :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ### How are PAR stablecoins created? Users can deposit from a large variety of collateral types (like wBTC) and borrow a safe amount of PAR at low interest. As of May 2022, PAR is over-collateralized by over 6 different tokens on 3 different networks. :::info To get more informations on each collateral risks parameters, you can read PAR Risk Parameters. ::: ### What is an over-collateralized stablecoin ? To retain its value, a stablecoin must have another asset that is put as collateral to back its intrinsic value. That collateral must be redeemable at any time. PAR has a loan and repayment process utilizing collateralized debt positions (CDPs) via the Mimo Protocol to secure assets as collateral on-chain. That means that for every 1€ of PAR out there, you can be sure that it’s backed with more than 1€ worth of another asset, such as BTC, ETH or USDC. ### What does this mean for the peg? If PAR is trading below 1€, people are incentivized to buy PAR from open markets and pay off loans at a discount. This ensures that PAR won’t be worth substantially less than 1€ at all times. If PAR is trading above 1€, people have an incentive to mint PAR from the vaults and sell it for collateral (for example). This ensures that PAR will not always be significantly higher than 1€. ## What is the difference with algorithmic stablecoins ? Stablecoins are cryptocurrencies that are supposed to be pegged to fiat currencies like the US dollar. In the cases of USD-pegged stablecoins, their prices are supposed to be $1 at all times. Each stablecoin project differs in ways they maintain the peg. The two biggest ones, tether (USDT) and Circle's usd coin (USDC), are "collateralized” by fiat reserves, meaning they have cash or cash-equivalent assets in their reserves. So each USDT or USDC traded in the crypto market is backed by what’s actually in the possession of the stablecoin issuers. Over the past year, a new form of stablecoin emerged to increase capital efficiency: algorithmic stablecoins, such as terraUSD (UST), magic internet money (MIM), and neutrino usd (USDN). They’re called algorithmic because what backs them is an on-chain algorithm that facilitates a change in supply and demand between them (the stablecoin) and another cryptocurrency that props them up. ### Differences Unlike these projects, the PAR collateral is not the governance token (PRL), but assets such as Bitcoin, Ethereum, USDC, MATIC, etc. which ensures a better stability than when it is correlated to a governance token with a lower market cap. :::info To get more information about the difference between PAR and others stablecoins, you can read [Not all Stablecoins are made equal](https://medium.com/mimolabs/not-all-stablecoins-are-made-equal-724fd64a3de8) from Mimo Labs Medium. ::: ## Disclaimer This guide is not financial advice. :::warning Keep in mind that a strategy that works well at a given time may perform poorly (or make you lose money) at another time. Please stay informed, monitor the markets, keep an eye on your investments, and as always, do your own research. ::: # Where can I get PAR ? :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## By Minting Firstly, through minting by creating a [vault](/products/parallel-v2/how-it-works/vaults). ![PAR minting page](/images/vhD2KhoH911fF39sDMmN.png) :::info You can find how to mint PAR here. ::: ## By Swapping on a DEX (aggregator) You can get PAR through DEX or DEX aggregators like [Paraswap](https://app.paraswap.io/#/MIMO-PAR/123?network=ethereum) or [1inch](https://app.1inch.io/#/1/swap/ETH/0x90b831fa3bebf58e9744a14d638e25b4ee06f9bc/import-token) which are interesting to find the best route to get the best exchange rate. ​ Swap on [Paraswap](https://app.paraswap.io/#/MIMO-PAR/123?network=ethereum)​​​ Swap on [LiFi](https://transferto.xyz/swap) Swap on [DefiLlama](https://swap.defillama.com/) Swap on [DLN](https://app.dln.trade/dln?inputChain=137\&outputChain=1\&inputCurrency=0xe2aa7db6da1dae97c5f5c6914d285fbfcc32a128\&outputCurrency=0x68037790a0229e9ce6eaa8a99ea92964106c4703) Swap on [1inch](https://app.1inch.io/#/1/swap/ETH/0x90b831fa3bebf58e9744a14d638e25b4ee06f9bc/import-token) ## By buying on a CEX You can also find PAR on centralized exchanges like Bittrex, Liquid, HitBTC or Folgory. [Trade on Bittrex](https://global.bittrex.com/Market/Index?MarketName=BTC-PAR) ![](/images/jAWvgnSFP4WIWOEhTf3I.svg) [Trade on Folgory](https://folgory.com/) - Euro Support, IBAN deposits, debit cards [Trade on HitBTC](https://hitbtc.com/par-to-usdt) # paUSD :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: paUSD is a USD stablecoin backed by collaterals, and can only be minted with governance-approved collaterals. paUSD are created when users deposit accepted tokens (such as WETH, WBTC, USDC, etc) as collateral in vaults and in turn receive a loan against that collateral. **Token Symbol:** paUSD | Blockchain | Contract Address | | ----------- | ----------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [0x571f54D23cDf2211C83E9A0CbD92AcA36c48Fa02](https://etherscan.io/address/0x571f54D23cDf2211C83E9A0CbD92AcA36c48Fa02#code) | | Polygon PoS | [0x8054d4D130C3A84852f379424Bcac75673a7486B](https://polygonscan.com/address/0x8054d4D130C3A84852f379424Bcac75673a7486B#code) | ### paUSD is non-custodial There are no counterparties involved in the minting and burning of paUSD tokens, as actors in the network transact directly with the paUSD smart contracts. Vaults are non-custodial, with each borrower having full control over their collateral and borrowed paUSD balances, provided it meets the minimum health factor governed by the protocol as a whole. :::info You can use paUSD to earn yield by Providing Liquidity. ::: # How does paUSD work? :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ### How are paUSD stablecoins created? Users can deposit from a large variety of collateral types (like wBTC) and borrow a safe amount of paUSD at low interest. As of May 2024, paUSD is over-collateralized by over 23 different tokens on 2 different networks. :::info To get more informations on each collateral risks parameters, you can read paUSD Risk Parameters. ::: ### What is an over-collateralized stablecoin ? To retain its value, a stablecoin must have another asset that is put as collateral to back its intrinsic value. That collateral must be redeemable at any time. paUSD has a loan and repayment process utilizing collateralized debt positions (CDPs) via the Mimo Protocol to secure assets as collateral on-chain. That means that for every 1$ of paUSD out there, you can be sure that it’s backed with more than 1$ worth of another asset, such as BTC, ETH or USDC. ### What does this mean for the peg? If paUSD is trading below 1$, people are incentivized to buy paUSD from open markets and pay off loans at a discount. This ensures that paUSD won’t be worth substantially less than 1$ at all times. If paUSD is trading above 1$, people have an incentive to mint paUSD from the vaults and sell it for collateral (for example). This ensures that paUSD will not always be significantly higher than 1$. ## What is the difference with algorithmic stablecoins ? Stablecoins are cryptocurrencies that are supposed to be pegged to fiat currencies like the US dollar. In the cases of USD-pegged stablecoins, their prices are supposed to be $1 at all times. Each stablecoin project differs in ways they maintain the peg. The two biggest ones, tether (USDT) and Circle's usd coin (USDC), are "collateralized” by fiat reserves, meaning they have cash or cash-equivalent assets in their reserves. So each USDT or USDC traded in the crypto market is backed by what’s actually in the possession of the stablecoin issuers. Over the past year, a new form of stablecoin emerged to increase capital efficiency: algorithmic stablecoins, such as terraUSD (UST), magic internet money (MIM), and neutrino usd (USDN). They’re called algorithmic because what backs them is an on-chain algorithm that facilitates a change in supply and demand between them (the stablecoin) and another cryptocurrency that props them up. ### Differences Unlike these projects, the paUSD collateral is not the governance token (MIMO), but assets such as Bitcoin, Ethereum, USDC, MATIC, etc. which ensures a better stability than when it is correlated to a governance token with a lower market cap. :::info To get more information about the difference between PAR and others stablecoins, you can read [Not all Stablecoins are made equal](https://medium.com/mimolabs/not-all-stablecoins-are-made-equal-724fd64a3de8) from Mimo Labs Medium. ::: ## Disclaimer This guide is not financial advice. :::warning Keep in mind that a strategy that works well at a given time may perform poorly (or make you lose money) at another time. Please stay informed, monitor the markets, keep an eye on your investments, and as always, do your own research. ::: # Where can I get paUSD ? :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## By Minting Firstly, through minting by creating a [vault](/products/parallel-v2/how-it-works/vaults) on [Parallel](https://pausd.mimo.capital/).
## By Swapping on a DEX (aggregator) You can get paUSD through DEX or DEX aggregators like [Paraswap](https://app.paraswap.io/#/MIMO-PAR/123?network=ethereum) or [1inch](https://app.1inch.io/#/1/swap/ETH/0x90b831fa3bebf58e9744a14d638e25b4ee06f9bc/import-token) which are interesting to find the best route to get the best exchange rate. ​ Swap on [Paraswap](https://app.paraswap.io/#/MIMO-PAR/123?network=ethereum)​​​ Swap on [LiFi](https://transferto.xyz/swap) Swap on [DefiLlama](https://swap.defillama.com/) Swap on [DLN](https://app.dln.trade/dln?inputChain=137\&outputChain=1\&inputCurrency=0xe2aa7db6da1dae97c5f5c6914d285fbfcc32a128\&outputCurrency=0x68037790a0229e9ce6eaa8a99ea92964106c4703) Swap on [1inch](https://app.1inch.io/#/1/swap/ETH/0x90b831fa3bebf58e9744a14d638e25b4ee06f9bc/import-token) # How It Works :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: # Classic Vaults :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The core of the Parallel Protocol are **Vaults**. Users mint **PAR/paUSD** by depositing **collateral** such as Ether (ETH) into the Vault smart contract. The steps involved to mint new PAR/paUSD are as follows: * A Borrower deposits collateral, automatically creating a new Vault. Based on the Vault's collateral balance, a Borrower can borrow up to a certain amount of PAR/paUSD. The Vault must be collateralized with more than a **Minimum Collateralization Ratio** (MCR) for borrowing. For example, an MCR of 150% means borrowers need 150% collateral deposited before they can borrow. * A separate liquidation MCR (**Liquidation Ratio** (LR)) is used to calculate for liquidations. For example, an LR of 130% means Vaults with an MCR below 130% can be liquidated. Both ratios for initial borrowing and liquidations are configured per collateral type. * The PAR smart contract mints the borrowed amount of PAR tokens to the Borrower. * An **Origination Fee** is applied for newly created debt. (0.2% of minted amount) * [PAR](/products/parallel-v2/stablecoins/par) & [paUSD](/products/parallel-v2/stablecoins/par-1) are ERC20 tokens that one can transfer and use normally, pegged to the EUR & USD fiat currency. * A **Borrowing Fee** accrues over time on all active Vaults, which has to be fully repaid before the Borrower can withdraw their collateral. * A **Health Factor** is the ratio between a vault's current and minimum MCR (or LR.) If a Vault's liquidation health factor goes below a minimum value due to market changes, profit-seeking Liquidators can liquidate the **undercollateralized** Vault to receive its collateral at a discount. * Borrowers need to retain enough collateral in their Vaults to borrow additional funds and avoid being liquidated. * The PAR & paUSD token are fully redeemable stablecoins. Borrowers can redeem and burn PAR/paUSD to repay their debt, close their Vault, and withdraw their collateral. * Liquidators earn a liquidation bonus for liquidating underwater vaults. * A **Liquidation Fee** is charged to the Borrower during liquidation, which is added to the outstanding debt. :::info Learn more about Vaults : * [Depositing](/products/parallel-v2/how-it-works/vaults/depositing) * [Borrowing](/products/parallel-v2/how-it-works/vaults/borrowing) * [Fees](/products/parallel-v2/how-it-works/vaults/fees) * [Withdrawing](/products/parallel-v2/how-it-works/vaults/withdrawing) * [Repaying](/products/parallel-v2/how-it-works/vaults/repaying) * [Liquidating](/products/parallel-v2/how-it-works/vaults/liquidating) ::: # Depositing :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The first step to start interacting with the Mimo protocol is to create a Vault and deposit collateral. Increasing the amount of collateral deposited increases the amount of PAR/paUSD one can borrow. ![](/images/-MeONN46WgZgZfYG2nAI.png) The deposited collateral is locked in a Vault, and allows the owner to borrow PAR/paUSD tokens up to an amount based on the Minimum Collateralization Ratio (MCR). An MCR of 150% means borrowers need 150% collateral deposited before they can borrow up to 100%. # Borrowing :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Borrowers can repay or borrow more PAR/paUSD at any time, within the limits of the MCR. Borrowing alters the total supply of outstanding PAR/paUSD. When one borrows, the Vaults contract mints new PAR/paUSD tokens for them. ![](/images/-MeOONh2d7zIEPYJ5oQ4.png) Borrowers can continue to mint PAR/paUSD as long as they deposit a greater value of collateral in their vault. This guarantees that all outstanding PAR/paUSD are fully backed by sufficient collateral. # Fees :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The Parallel Protocol is generating revenues by taking fees on minted PAR/paUSD and distribute them to various actors. You can learn more: * [Fees Generation](/products/parallel-v2/how-it-works/vaults/fees/fees-generation) # Fees Generation :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The Parallel Protocol is generating revenues by taking fees on minted PAR/paUSD. These fees are called "Origination Fee" and "Borrowing Fee". ### Origination Fee The "Origination Fee" is a fee taken at the moment of the mint of newly PAR/paUSD tokens. The "Origination Fee" is quoted as a percentage of the total newly minted PAR/paUSD. Origination Fee parameters for each token are available here. ### Borrowing Fee The "Borrowing Fee" is a fee taken on the amount of PAR/paUSD minted by against a collateral. The "Borrowing Fee" is automatically added to the borrower's debt at each block. Borrowing Fee parameters for each token are available here. :::info Learn more about Fee Distribution [here](/governance/parallel-governance-token-prl/tokenomics/fee-distribution). ::: # Withdrawing :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Withdrawing involves redeeming PAR/paUSD for the underlying collateral. When redeemed, the system burns PAR/paUSD tokens to repay a vault’s debt. This debt includes any borrowing fees that has accrued on the vault over time. ![](/images/-MeOTYowKv-zgIDPxde2.png) Users can withdraw their collateral whenever they wish as long as it does not decrease the Vault’s health factor below the minimum amount determined by the MCR. Withdrawing is limited to the Vault’s owner. # Repaying :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Vault owners are recommended to keep their collateral ratios well above the MCR and LR to avoid liquidations despite collateral price changes. One way to maintain a high collateral ratio is to regularly repay vault debt. ![](/images/-MeOTec0d17KrbLDLn2Q.png) Users can repay their vault debt partially or fully at any point by redeeming PAR/paUSD tokens. PAR/paUSD tokens used to repay debt are burned, removing them from circulation. # Liquidating :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Liquidation ensures that there is always sufficient collateral to cover all PAR/paUSD tokens. Vaults below a specified health factor are subject to liquidation by profit-seeking actors in the network. Network actors have a financial incentive to trigger liquidations as fast as possible. This has the positive effect of removing risky vaults from the system. ![](/images/-MeOV3BCllljW-xL_EzL.png) A **liquidation fee** is charged to the borrower during liquidation, added to the outstanding debt. ## Insurance Fund All vaults in the Parallel Protocol are covered by the Insurance Fund. The Insurance Fund comes into use when a vault that faces liquidation does not have enough collateral to pay for the entire outstanding debt. :::info Potential bad debt are covered by the Insurance Fund. Learn more about it [here](/security/insurance-fund). ::: The Insurance Fund will cover the difference in those cases. Liquidation will simply fail if the safety reserve can not cover it. Once enough fees have been collected, liquidation can proceed. During this time, the safety reserve will take on the volatility risk of the collateral.

Insurance Fund Architecture

# Bridging Module :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Tunnel, the Parallel bridging module is a secure, scalable, and decentralized bridging infrastructure which enable seamless transfer of PAR and paUSD between supported chains. The module is designed to be highly flexible while maintaining robust security, allowing the Parallel Protocol to expand across multiple chains without compromising the stability of its stablecoins. Built on LayerZero's infrastructure, it offers several key features: ## Security & Architecture * Utilizes LayerZero's decentralized message verification and execution infrastructure * Implements a modular security stack with configurable Decentralized Verifier Networks (DVNs) * Employs an "X of Y of N" security model allowing flexible combinations of validators * Includes fallback mechanisms through permissionless execution if automated systems fail * Follows the Omnichain Fungible Token (OFT) standard ## Key Features * **Daily & Global Limits**: Configurable mint and burn limits to manage risk * **Isolation Mode**: Optional feature to contain risk from less secure chains * **Fee System**: Flexible fee structure for sustaining operations * **Emergency Controls**: Pause/unpause functionality for risk management * **Fully DAO Controlled**: All parameters and operations managed by governance ## Risk Management * Mint/burn limits on both daily and global levels * Chain-specific isolation modes to prevent risk propagation * Multiple DVNs required for transaction verification * Automatic transaction reversal if required validators are unavailable * Full governance control over all security parameters ## Codebase & License The Bridging Module codebase is publicly available here and is released under the MIT License. The code has been audited by Bail Security. The audit report is available [here](/security/audits). More technical informations available in the [developers documentation](/developers-hub/parallel-v2/bridging-module). # LayerZero Infrastructure :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## **Overview** 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)

LayerZero Overview

## **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/). # Specifications :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## **OFT Standard** The bridging module is following the Omnichain Fungible Token (OFT) Standard created by LayerZero. You can find more information about it [here](https://docs.layerzero.network/v2/developers/evm/oft/quickstart). ## **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](https://layerzeroscan.com/) 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](/security/parallel-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. # Implementation :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The currently voted implementation of the PAR & paUSD bridging modules can be found here: * [PAR](/products/parallel-v2/how-it-works/bridging-module/implementation/par) * [paUSD](/products/parallel-v2/how-it-works/bridging-module/implementation/pausd) # PAR :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## **Ethereum** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Polyhedra * Optionals: 1 of 2 * Nethermind * Google Cloud * Mint Limits: * Daily: 25,000.00 * Global: 200,000.00 * Burn Limits: * Daily: 25,000.00 * Global: 200,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No ## **Polygon PoS** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Polyhedra * Optionals: 1 of 2 * Nethermind * Google Cloud * Mint Limits: * Daily: 25,000.00 * Global: 200,000.00 * Burn Limits: * Daily: 25,000.00 * Global: 200,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No ## **Fantom** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Polyhedra * Optionals: 1 of 2 * Nethermind * Google Cloud * Mint Limits: * Daily: 1,000.00 * Global: 5,000.00 * Burn Limits: * Daily: 1,000.00 * Global: 5,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * Yes # paUSD :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## **Ethereum** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Polyhedra * Optionals: 1 of 2 * Nethermind * Google Cloud * Mint Limits: * Daily: 15,000.00 * Global: 100,000.00 * Burn Limits: * Daily: 15,000.00 * Global: 100,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No ## **Polygon PoS** * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Polyhedra * Optionals: 1 of 2 * Nethermind * Google Cloud * Mint Limits: * Daily: 15,000.00 * Global: 100,000.00 * Burn Limits: * Daily: 15,000.00 * Global: 100,000.00 * Fees: * Rate: 0.00% * Isolate Mode: * No # Super Vaults (SV) :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Super Vaults are a versatile tool for managing positions in changing markets. For example, if you're initially very bullish on an asset like wETH, you can use a Super Vault to enter a leveraged long position. If the market shifts and you're no longer confident in your position, you can reduce risk by rebalancing to less volatile collateral. You can also withdraw your capital at any time for use elsewhere. When you're done with the vault, you can use emptyVault to repay any outstanding debts and retrieve your collateral. :::info Learn more about Super Vaults core feature : * [Leveraging](/products/parallel-v2/how-it-works/super-vaults-sv/leveraging) * [Rebalancing](/products/parallel-v2/how-it-works/super-vaults-sv/rebalancing) * [EmptyVault](/products/parallel-v2/how-it-works/super-vaults-sv/emptyvault) ::: Super Vaults also offer additional features, such as the ability to grant others control over your vault for management purposes. The Managed Vaults feature allows you to choose from a list of approved addresses to rebalance your vault, which can include smart contracts like DAOs. The Automated Vaults feature enables automatic rebalancing of your vault based on a user-specified collateralization ratio, acting as a stop loss. This is convenient for those who don't have the time or knowledge to manage their vault, and provides an opportunity for vault operators to maximize collateral value and overall protocol health. :::info Learn more about Super Vaults delegation features : * [Automated Rebalance](/products/parallel-v2/how-it-works/super-vaults-sv/automated-rebalance) * [Managed Rebalance](/products/parallel-v2/how-it-works/super-vaults-sv/managed-rebalance) ::: To ensure proper access control, all Super Vault operations must be performed through a user's [`MimoProxy`](/developers-hub/parallel-v2/super-vault-sv/proxy-design/mimoproxy), which is the only contract instance with the necessary permissions. All core functions, such as depositing, withdrawing, borrowing, and liquidating, are accessible through `MimoProxy`. Remember, as with vaultsCore, you must first approve the deposited amount to `MimoProxy` before calling any deposit functions. :::info Super Vaults are only available for PAR on Polygon PoS. ::: # Leveraging :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: SuperVaults allow for leveraging assets without any additional capital. For example, let's assume we are very bullish on an asset we are holding (e.g. WETH), and we want to enter into a 3x long position. After initializing a SuperVault, we could call `leverage` on our SuperVault to do this. The steps required to leverage our WETH, assuming we start with 1 WETH, would be to: 1. Take a flashloan of the additional amount of WETH we want to leverage. In this example, we want to leverage 3x, so we need to borrow 2 additional WETH to borrow from the flashloan. 2. Deposit the 3 total WETH (minus some flashloan fees) into a vault owned by the SuperVault contract 3. From this newly deposited WETH, mint PAR. The MIMO protocol enforces that we can mint a maximum of `(Collateral Amount)/(Minimum Collateralization Ratio)` worth of PAR. The Minimum Collateralization Ratio (MCR) for WETH is 1.3, so we can mint a maximum of `(3)/(1.3)`, or about 2.3 WETH, worth of PAR. 4. Sell the newly minted PAR for WETH using an Aggregator (e.g. OneInch or Paraswap), and use the WETH to repay the flashloan + fees. Note: Given a starting amount `S`, the total amount of an asset that we can leverage depends on the MCR of the asset defined in `collateralConfig` . Specifically, the additional amount we leverage must be less than `S/(MCR - 1)`. This is derived in the Leverage Max Amount Derivation section. If the price goes up after we leveraged, we can take advantage of the price increase through borrowing more PAR using or withdrawing more ETH. If we wish to cash out all of our leveraged ETH, we could use the `emptyVault` feature to: 1. Take a flashloan to borrow some ETH. 2. Swap the borrowed ETH to repay the outstanding debt in the leveraged vault. 3. Withdraw the leveraged ETH and repay the flashloan.\ If the price has increased, we will have more ETH than we initially started with after repaying the flashloan! See the `emptyVault` section for more details on how `emptyVault` is implemented. # Rebalancing :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: In addition to leveraging, SuperVaults also allow for rebalancing vaults to use another collateral without requiring any additional capital. For example, let's assume that in our example from the previous section, our leveraged asset did not appreciate in the way we predicted, and ETH actually entered a bear market. To minimize our risk from our leveraged position, we could `rebalance` our SuperVault to use a less risky collateral, such as USDC. The `rebalance` call does the following: 1. Take a flashloan of the starting collateral - in this example, we are rebalancing ETH to USDC, so the starting collateral is ETH and the rebalanced collateral is USDC. 2. Use an aggregator to swap the borrowed starting collateral for the rebalanced collateral. 3. Deposit the rebalanced collateral into a new vault, and borrow PAR from the new vault 4. Use the borrowed PAR to pay back any outstanding debts on the starting collateral vault 5. Withdraw all starting collateral from the vault to repay back the loan The amount of PAR we can borrow in step 3 is limited by the MCR of the rebalanced collateral. Thus, rebalancing is much more effective for moving to collaterals with lower MCRs as that will allow us to rebalance more collateral. Note: Only vaults created by through the `MIMOProxy` can be rebalanced. # EmptyVault :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `emptyVault` feature can be used to once we are done using a vault for a specific collateral and we wish to repay all debts for the collateral and withdraw our collateral balance without any additional capital. Note: You should use `withdraw` instead if the vault you wish to close does not have any outstanding debt. The `EmptyVault` call does the following: 1. Flash loan some collateral 2. Use an aggregator to swap loaned collateral for PAR 3. Use swapped PAR to repay any outstanding vault debt 4. Withdraw collateral from vault Note: There will likely be some leftover PAR from repaying the vault debt since we don't know exactly how much PAR we will get from a swap. The vault will still technically exist after calling `emptyVault`; it will just have zero collateral balance and zero vault debt. # Automated Rebalance :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ### Use Case Scenario For our scenario, let's assume we want to open a vault with WETH as collateral. However, we want to be protected from liquidation in case of a price drop, similar to setting a stop loss on a centralized exchange. To achieve this, we can utilize the Automated Vaults feature in Super Vault. This feature implements checks to reduce the risk of abuse, such as limiting the collateralization ratio that must be achieved before rebalancing, controlling the maximum change in vault value during rebalancing, and limiting the number of rebalances that can occur within a given time frame. Users can set the fees they're willing to pay for rebalancing, including flat fees per rebalance and variable fees based on the rebalanced amount, to incentivize keepers and cover the gas costs of calling the rebalance function. This allows users to delegate the management of their vault to others while maintaining proper safeguards. ### Automated Rebalance Configuration To open a vault up for automated rebalances, a user must must set the following automated rebalance parameters : * The id of the vault to rebalance. * The maximum allowed slippage on rebalancing swaps : each rebalance call will swap one collateral for another. This parameter impose maximum slippage amounts to ensure a vault collateral doesn't lose too much value in between rebalances. The variation is calculated as : vaultVariation=rebalanceValue−swapResultValuerebalanceValuevaultVariation = \\frac{rebalanceValue - swapResultValue}{rebalanceValue}vaultVariation=rebalanceValuerebalanceValue−swapResultValue​"} /> * The targeted ratio of the rebalance : each rebalance will move the collateral and debt from the starting vault to a vault with less volatile collateral to bring the starting vault's collateralization ratio to a given target ratio. * The trigger ratio for the rebalance : keepers can only rebalance if the vault's collateralization ratio is lower or equal than the trigger ratio set by the user. * The rebalancing vault MCR buffer : the automated rebalance calculates the amount of collateral and debt to rebalance based on the MCR buffer padding set by the user. A higher MCR buffer means the rebalancing vault will be healthier after the rebalance, though it will also require more collateral and par debt to be moved from the starting vault to reach this padding. Each automated rebalance will withdraw just enough PAR to keep the to vault at this collateralization ratio (vault MCR + MCR buffer). * The rebalancing fees : users can configure how much they want to pay to incentivize each automated rebalance by setting a variable and/or a fixed fee. Rebalancing fees are paid in PAR borrowed from the vault that is rebalanced to. Setting higher fees incentivizes more people to monitor a vault for rebalances, but makes each rebalance more costly. The total fees paid per each rebalance is given as : totalFees=fixedFee+variableFee∗rebalanceValuetotalFees = fixedFee + variableFee * rebalanceValuetotalFees=fixedFee+variableFee∗rebalanceValue"} /> :::info To avoid substantial loss of collateral through multiple rebalances, Super Vault limits the amount of automated rebalances on any vault to one per day. ::: # Managed Rebalance :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The automated vault system is designed to provide users with confidence in each automated rebalance, ensuring that rebalances are done in a sensible manner and that costs in terms of slippage and fees are kept to a minimum. While this is ideal for allowing anyone to rebalance on behalf of the user, it does not allow for more profitable strategies to be implemented. In such cases, where a user wants to trust someone to make rebalancing decisions based on their predictions of future collateral value, they can use the managed rebalance feature. This gives a whitelisted manager address greater control over the rebalance calls, allowing for more custom and potentially profitable strategies to be employed. ### Managed Rebalance Configuration Similar to the automated rebalance feature, users must configure a vault to be managed by setting the following managed rebalance parameters : * The address of the whitelisted manager selected to manage the vault * The maximum allowed slippage on rebalancing swaps (see [Automated Rebalance](/products/parallel-v2/how-it-works/super-vaults-sv/automated-rebalance)) * The minimum vault ratio above which the starting vault be at the end of a rebalance operation : this allows user to set a limit on a how close to the vault MCR a manager can rebalance * The rebalancing fees (see [Automated Rebalance](/products/parallel-v2/how-it-works/super-vaults-sv/automated-rebalance)) * The rebalancing vault MCR buffer (see [Automated Rebalance](/products/parallel-v2/how-it-works/super-vaults-sv/automated-rebalance)) # Licensing :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Parallel V2 is licensed under MIT license. 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. # Proof of Solvency import { LinkCard } from '@/components/LinkCard' ## Introduction Unlike the majority of stablecoins protocols, Parallel V3 doesn't rely on multisigs or MCP vaults for its backing management but on onchain & permissionless smart contracts called [Parallelizer Module](/products/parallel-v3/how-it-works/parallelizer-module). The [Parallelizer Module](/products/parallel-v3/how-it-works/parallelizer-module) is handling mint, burn & redeem operations within DAO approved [parameters](/products/parallel-v3/stablecoins-and-savings/usdp-and-susdp/implementation), you can learn more about it [here](/products/parallel-v3/how-it-works/parallelizer-module). Users, keepers and anyone can freely interact with the backing of Parallel V3 Stablecoins without any cooldown. The DAO, nor protocol contributors have access to Parallel V3 stablecoins backing. Moreover the backing is held entirely onchain. ## Reserves Addresses | Blockchain | Contract Name | Contract Address | | ---------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Ethereum | ParallelizerUSDp | [0x6efeDDF9269c3683Ba516cb0e2124FE335F262a2](https://etherscan.io/address/0x6efeDDF9269c3683Ba516cb0e2124FE335F262a2#code) | | Base | ParallelizerUSDp | [0xC3BEF21Ea7dEB5C34CF33E918c8e28972C8048eD](https://basescan.org/address/0xC3BEF21Ea7dEB5C34CF33E918c8e28972C8048eD#code) | | HyperEVM | ParallelizerUSDp | [0x1250304F66404cd153fA39388DDCDAec7E0f1707](https://hyperevmscan.io/address/0x1250304F66404cd153fA39388DDCDAec7E0f1707#code) | | Avalanche | ParallelizerUSDp | [0x41d58951cbd12d4ef49b0437897677bbf5547c80](https://snowscan.xyz/address/0x41d58951cbd12d4ef49b0437897677bbf5547c80#code) | # Parallel Emergency Guardians As the protocol is deployed on 16 chains and brings a major innovation in the ecosystem, it is possible that, despite different audits, a minor or major problem could arise in the future. Considering the importance of timing in certain situations, a [proposal](https://gov.parallel.best/t/mip-11-mimo-emergency-guardians/258) has been approved to prepare the DAO for any potential emergency action that might have to be done by allowing any Multisig Signers to initiate transactions from the multisig to stop an emergency situation (and execute it after verification and signatures from others signers). :::info Since the [MIP-11](https://snapshot.org/#/mimo.eth/proposal/0x2ca4f1cbfa9d927eb8bc41546b02dbeaf5a54839e2846516273d2aeeb460b847) has been voted and accepted on Snapshot, all Multisig Signers can intervene in case of emergency situations on every chain where the Mimo Protocol is deployed. ::: ## **Tiers Risks** ### *Tier 1 Risk* **Scope:** User funds are at risk **Actions:** Immediate intervention by pausing the system, then a governance discussion 24h vote time for further actions. ### *Tier 2 Risk* **Scope:** Risk on protocol economic activity (eg: Bug on Parallel allowing to mint infinite of USDp etc, or any economic attack/exploit possible) **Actions:** 1-3h feedback emergency on the forum. If the attack happens 24h before the distribution, the reaction should be immediate and follows the same process as Tier-1. The action should be to pause the compromised module only, if possible. A post-mortem is also needed in this case. # Hypernative As the protocol is deployed on 16 chains and brings a major innovation in the ecosystem, it is possible that, despite different audits, a minor or major problem could arise in the future. Since the launch of Parallel V3 in September 2025, several issues have been detected, including bug reports from ImmuneFi and assets allowed in the backing of USDp. This required a rapid response in order to partially pause the protocol when necessary. Although the guardians reacted quickly, thanks to the presence of signers across multiple time zones, this is not optimal and may put the security of the protocol at risk. In order to automate the detection and pausing of the protocol in the event of a detected problem, Hypernative has been onboarded by the DAO following an approved [proposal](https://gov.parallel.best/t/pip-62-l-use-hypernative-for-real-time-protocol-security-monitoring/518) for real time protocol security monitoring for any potential emergency action that might have to be done. ## **Core Platform Capabilities** Hypernative is a leading real-time security platform that unites alerting and threat prevention with a sharp focus on early detection of on-chain threats and automated protective responses. It integrates real-time blockchain monitoring across +70 blockchains, curated threat intelligence, machine learning driven anomaly detection, and highly customizable automation modules to deliver comprehensive protection. Leading protocols across the industry trust Hypernative to identify exploits as they unfold, uncover hidden risks before they escalate, and automatically trigger safe-shutdown or mitigation procedures when necessary. ## **Automated Actions & Workflows** Parallel is leveraging Hypernative’s core solution, their security platform, which proactively detects and prevents a wide spectrum of onchain and offchain threats before they can cause damage. It continuously monitors the entire protocol, positions, dependencies and transactions to give contributors critical minutes to respond and, when desired, acts automatically to contain live incidents.​ Hypernative only have the possibility to pause the mint & burn of USDp on the Parallelizer & Bridging Module, as well as stake & unstake on the Savings Module which means that they will not have any admin function nor the possibility to remove & adjust collaterals or change DVNs. :::info Hypernative is only working on Parallel V3, Parallel V2 is not supported. ::: ## Hypernative Wallets | Blockchain | Wallet | | ---------- | -------------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://etherscan.io/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Base | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://basescan.org/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Sonic | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://sonicscan.org/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | HyperEVM | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://hyperevmscan.io/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Avalanche | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://snowscan.xyz/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Polygon | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://polygonscan.com/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Arbitrum | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://arbiscan.io/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Optimism | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://optimistic.etherscan.io/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Sei | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://seiscan.io/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | BSC | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://bscscan.com/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Berachain | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://berascan.com/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Scroll | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://scrollscan.com/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Gnosis | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://gnosisscan.io/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Unichain | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://uniscan.xyz/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Ink | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://explorer.inkonchain.com/address/0xCd6f2a5D4dDA89645ab463d38CA64b8a7309696f) | | Tac | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://explorer.tac.build/address/0xCd6f2a5D4dDA89645ab463d38CA64b8a7309696f) | | Linea | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://lineascan.build/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | X Layer | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://www.oklink.com/x-layer/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Plume | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://explorer.plume.org/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Plasma | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://plasmascan.to/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Katana | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://www.katanascan.com/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Fraxtal | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://fraxscan.com/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | | Hemi | [0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f](https://explorer.hemi.xyz/address/0xcd6f2a5d4dda89645ab463d38ca64b8a7309696f) | # Keepers ## What is a Keeper? A Keeper is a whitelisted actor designated by the Parallel DAO to perform critical off-chain-to-on-chain operations that cannot be executed automatically in a trustless and non-manipulative manner. Keepers ensure the smooth functioning of several core protocol mechanisms, including yield rate updates and fee distribution. In the Parallel V3 access control system, keepers are assigned the `KEEPER_ROLE` (role ID `30`), with an associated `KEEPER_ROLE_TIMELOCK` (role ID `31`). ## Responsibilities ### Savings Rate Updates The yield rate paid by Savings module contracts (e.g., sUSDp) is derived from the returns generated by the protocol on its backing assets. However, this rate schedule cannot be implemented automatically in a non-manipulative way. Keepers are responsible for encoding and updating the inflation rate in the Savings module contracts. Depending on the stablecoin and the setup, governance may follow different update schedules. The frequency of updates can vary from every week to every several months. Between two updates, depositors in Savings module contracts are guaranteed to earn a fixed rate on their assets. ### Target Oracle Updates In the Parallelizer Module, each collateral asset has a target price used to assess whether the asset is depegging and whether conservative measures (such as adjusted fees or paused operations) should be taken. Keepers are responsible for updating these target oracles to reflect accurate market conditions. This is essential for the proper functioning of the mint, burn, and redeem operations, as the system relies on the deviation between the oracle price and the target price to determine adaptive fees and depeg protection behavior. ## Safety Mechanisms To prevent any potential keeper from acting maliciously, the protocol implements several safeguards: * **Maximum Rate Cap**: A maximum possible rate is enforced on each Savings module. For example, the maximum rate for sUSDp has been set at 35.00%. This prevents a keeper from uncontrollably increasing the savings rate. * **DAO Whitelisting**: Only keepers explicitly approved by the DAO governance can perform keeper operations. This ensures accountability and transparency. * **Timelock**: The `KEEPER_ROLE_TIMELOCK` adds a delay mechanism for sensitive keeper operations, providing an additional layer of security. ## Approved Keepers The following entities have been approved as keepers by the Parallel DAO: * [**Cooper Labs**](https://cooperlabs.xyz/) ## Keepers Addresses | Blockchain | Address | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A](https://etherscan.io/address/0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A) | | Ethereum | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://etherscan.io/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b) | | Base | [0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A](https://basescan.org/address/0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A) | | Base | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://basescan.org/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b) | | HyperEVM | [0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A](https://hyperevmscan.io/address/0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A) | | HyperEVM | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://hyperevmscan.io/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Avalanche | [0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A](https://snowscan.xyz/address/0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A) | | Avalanche | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://snowscan.xyz/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b) | | Sonic | [0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A](https://sonicscan.org/address/0x82f603CD2C2166C9D94b3cA78a16A754f0A6657A) | | Sonic | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://sonicscan.org/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b) | | Polygon | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://polygonscan.com/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Arbitrum | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://arbiscan.io/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Optimism | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://optimistic.etherscan.io/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Sei | [0xe1A4951E27f91dCC34c5C0B51eA53b46D6aD2566](https://seiscan.io/address/0xe1A4951E27f91dCC34c5C0B51eA53b46D6aD2566#code) | | BSC | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://bscscan.com/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Berachain | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://berascan.com/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Scroll | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://scrollscan.com/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b?tab=contract) | | Gnosis | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://gnosisscan.io/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Unichain | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://uniscan.xyz/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Ink | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://explorer.inkonchain.com/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b?tab=contract) | | Tac | [0x86e8f2347ba704a9a8fB8DBa57fE2680EB443962](https://explorer.tac.build/address/0x86e8f2347ba704a9a8fB8DBa57fE2680EB443962?tab=contract) | | Linea | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://lineascan.build/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | X Layer | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://www.oklink.com/x-layer/address/0xc351c917a7f7b267e86a5f5368be40fd1788c32b/contract) | | Plume | [0xa0e512E7244b47B49D68E16a418Fe0ee04b45c95](https://explorer.plume.org/address/0xa0e512E7244b47B49D68E16a418Fe0ee04b45c95) | | Plasma | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://plasmascan.to/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Katana | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://katanascan.com/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Fraxtal | [0x3E695846a6FE7e7dB00b24687Da17863AABbA10B](https://fraxscan.com/address/0x3E695846a6FE7e7dB00b24687Da17863AABbA10B#code) | | World | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://worldscan.org/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b#code) | | Hemi | [0xc351C917a7f7b267e86a5f5368Be40FD1788c32b](https://explorer.hemi.xyz/address/0xc351C917a7f7b267e86a5f5368Be40FD1788c32b?tab=contract) | # Bug Bounty Program Introduced & approved by the DAO in [PGP-28 l Immunefi Bug Bounty Program](https://gov.parallel.best/t/pgp-28-l-immunefi-bug-bounty-program/478), the Parallel Bug Bounty Program is live since June 30 2025 via ImmuneFi, and accessible here: ## Rules A maximum reward of $250,000 USD is available for the most critical impacts of Parallel Protocol’s bug bounty program. Reward amounts are adjusted depending on the impact and the volume of the funds at risk (e.g. the maximum reward would only be paid if it is proven that a vulnerability would allow exploitation of protocol’s total value locked). A minimum reward of $50,000 USD should be paid for other critical bugs in order to incentivize security researchers against withholding reports. Moreover, the validity of every single bug report is determined not by Immunefi, but by Parallel’s bug bounty program administrators. However, the Immunefi mediation team is available whenever there are any disputes in any of the bug report submissions. Cooper Labs, Mimo Labs, and the Immunefi teams determined these amounts according to industry best practices and by benchmarking the programs of similar projects on our platform. The complete program rules can be analyzed [here](https://immunefi.com/bug-bounty/parallel/information/). Mimo Labs and Cooper Labs have been appointed as administrators of the bug bounty program. They are responsible for validating bug reports and have the authority to transfer funds from the insurance fund without proposal, conditioned to a post detailing the bug found, the amount paid and its resolution. They can also update the program at any time. The bug bounty program service includes the hosting and design of the bounty program, a co-marketing plan, 24/7 coverage managed triage plan, one mitigation review, and free access to a Safe Harbor module. This means Immunefi’s internal triage team filter all spam and low-quality reports, and manage other initial engagements with the security researchers as per its [Time Saver plan](https://immunefi.com/managed-triage/), helping to minimize the time triaging reports by Parallel’s administrators. Immunefi’s Safe Harbor is a legal framework developed by the Security Alliance (SEAL) for protocols to empower whitehat security researchers to rescue funds during a blackhat attack and redirect those funds back to a protocol-controlled vault on Immunefi’s platform, in exchange for up to 60% of the max critical reward to deter against abuses. # Insurance Fund ## Summary Introduced with [MIP-28┃Ratify the Parallel Insurance Fund](https://gov.parallel.best/t/mip-28-ratify-the-parallel-insurance-fund/382) and updated with [PGP-31 | Update Insurance Fund Strategy](https://gov.parallel.best/t/pgp-31-update-insurance-fund-strategy/482) the Insurance Fund is covering losses in case of shortfall events: * **Smart contract risk:** Risk of a bug, design flaw or potential attack surfaces on the smart contract layer, managed via the bug bounty [program](/security/bug-bounty-program). * **Oracle failure risk:** Risk of the oracle system not properly updating the prices in case of extreme market downturn and network congestion; risk of the Oracle system not properly submitting prices, causing improper liquidations. ## Rules The DAO must decide, via governance votes, which deployment is covered, which chain is covered, or not, by the insurance fund, and at which % or $ value of the insurance fund the deployment & chain are covered. Assets held in the insurance fund must be liquid under a 16 weeks period. For Parallel V2: At least 10k PAR for PAR deployments and 1k paUSD for paUSD deployments must stay in the vaultsCore to cover very short term potential bad debts. DAO Multisig signers will have the right to rebalance assets from the deployed insurance fund to vaultsCore contracts in order to always have enough assets to cover very short term bad debts. The DAO approved to cover Parallel V3 with USDp deployment on Ethereum, Base, Sonic, HyperEVM & Avalanche; and PRL token on Ethereum, Arbitrum, Optimism, Base, Sonic & Polygon PoS. All this to up to 100% of the insurance fund via the bug bounty [program](/security/bug-bounty-program). ## Insurance Fund Assets | Multisig | Address | | ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Insurance Fund Multisig | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://etherscan.io/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c) | | VaultsCore - PAR (only PAR in the contract) | [0x173ae6283a717b6cdd5491eac5f82c082a8c674b](https://etherscan.io/address/0x173ae6283a717b6cdd5491eac5f82c082a8c674b#code) | | VaultsCore - paUSD (only paUSD in the contract) | [0xE26348D30694aa7E879b9335252362Df3df93204](https://etherscan.io/address/0xE26348D30694aa7E879b9335252362Df3df93204#code) | | Multisig | Address | | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Insurance Fund Multisig | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://polygonscan.com/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c) | | VaultsCore - PAR (only PAR in the contract) | [0x0a9202c6417a7b6b166e7f7fe2719b09261b400f](https://polygonscan.com/address/0x0a9202c6417a7b6b166e7f7fe2719b09261b400f#code) | | VaultsCore - paUSD (only paUSD in the contract) | [0xcABAbC1Feb7C5298F69B635099D75975aD5E6e5f](https://polygonscan.com/address/0xcABAbC1Feb7C5298F69B635099D75975aD5E6e5f#code) | | Multisig | Address | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Insurance Fund Multisig | [0x5826be671E80d5546f04886e3Fe19d4750201A99](https://hyperevmscan.io/address/0x5826be671E80d5546f04886e3Fe19d4750201A99#code) | | Multisig | Address | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Insurance Fund Multisig | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://sonicscan.org/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | | Multisig | Address | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Insurance Fund Multisig | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://basescan.org/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | | Multisig | Address | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Insurance Fund Multisig | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://snowscan.xyz/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ## Strategy * General: * Accumulated PAR/paUSD/USDp/USDC: Swapped to USDp and deposited into liquidity pools (DEX/Lending protocols), decided by DAO Multisig Signers with advice from Cooper Labs & Mimo Labs * Ethereum: * PAR VaultsCore contract: 10,000.00 PAR * paUSD VaultsCore contract: 1,000.00 paUSD * vlAURA: 1,113,709.10 * Aura-ECLP-PAR-EURA: 25,000.00 PAR * Aura-ECLP-paUSD-GYD: 25,000.00 paUSD * Polygon PoS: * PAR VaultsCore contract: 10,000.00 PAR * paUSD VaultsCore contract: 1,000.00 paUSD * Aura-ECLP-PAR-EURe: 25,000.00 PAR * Aura-ECLP-paUSD-stataUSDCn: 25,000.00 paUSD Accumulated rewards from [Aura](https://aura.finance/) & [Balancer](https://balancer.fi/) deposits would be swapped every 16 weeks for AURA tokens then locked as vlAURA for 16 weeks on [Aura](https://aura.finance/). vlAURA voting power will continue to be delegated to Mimo Labs, as voted previously. Accumulated rewards from other potential deposits in DEX/Lending protocols will be swapped for USDp. # Audits ## Security Reviews | Auditors | Scope | Date | Report | | -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Bail Security](https://bailsec.io/) | Parallel l Savings Fix Audit | 2026-07 | [bailsec-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/savings-fix/Bailsec%20-%20Parallel%20Protocol%20-%20Savings%20Fix%20-%20Final%20Report.pdf) | | [Cyfrin](https://www.cyfrin.io/) | Parallel l Savings Fix Formal Verification | 2026-06-10 | [cyfrin-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/savings-fix/Cyfrin%20-%20Parallel%20Protocol%20-%20Savings%20Fix%20-%20Formal%20Verification.pdf) | | [Cyfrin](https://www.cyfrin.io/) | Parallel l Savings Fix Audit | 2026-06-09 | [cyfrin-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/savings-fix/Cyfrin%20-%20Parallel%20Protocol%20-%20Savings%20Fix%20-%20Final%20Report.pdf) | | [Cyfrin](https://www.cyfrin.io/) | Parallel v3.2 l Agentic Payments Update Audit | 2026-05-24 | [cyfrin-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/v3.2/Cyfrin-Parallel%20Protocol%20-%20Upgrade-3.2%20-%20Final%20report.pdf) | | [Bail Security](https://bailsec.io/) | Parallel v3.2 l Agentic Payments Update Audit | 2026-05 | [bailsec-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/v3.2/Bailsec%20-%20Parallel%20Protocol%20-%20Upgrade%20V3.2%20-%20Final%20Report.pdf) | | [Cyfrin](https://www.cyfrin.io/) | Parallel v3.1 l Comprehensive Audit of the Protocol | 2026-03-04 | [cyfrin-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/v3.1/Cyfrin%20-%20Parallel%20Protocol%20-%202026-03-04.pdf) | | [Cyfrin](https://www.cyfrin.io/) | Parallel v3.1 l Comprehensive Formal Verification of the Protocol | 2026-03-04 | [cyfrin-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/v3.1/Cyfrin%20-%20Parallel%20Protocol%20-%20Formal%20Verification%20-%202026-03-04.pdf) | | [Bail Security](https://bailsec.io/) | Parallel v3.1 l Fee Claim Update Audit | 2026-02 | [bailsec-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/v3.1/Bailsec%20-%20Parallel%20Protocol%20-%20Fee%20Claim%20Update%20-%20Final%20Report.pdf) | | [Certora](https://www.certora.com/) | Parallel V3: parallel-core l parallel-tokens l parallel-parallelizer (only LibOracle, Swapper, Redeemer, RewardHandler) | 2025-04 | [certora-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/v3/Certora_Report_Parallel_Parallelizer_BridgeToken_final.pdf) | | [Bail Security](https://bailsec.io/) | Parallel V3: parallel-core l parallel-tokens l parallel-parallelizer | 2025-03 | [bailsec-report](https://github.com/parallel-protocol/parallel-parallelizer/blob/main/docs/audits/v3/Bailsec%20-%20Parallel%20Protocol%20-%20V3%20Core%20-%20Final%20Report.pdf) | | [Zenith](https://www.zenith.security/) | PRL Token l PRL Tokenomics | 2025-02-19 | [zenith-report](https://github.com/parallel-protocol/PRL-token/blob/main/docs/audits/Parallel%20Protocol%20-%20Zenith%20Audit%20Report.pdf) | | [Bail Security](https://bailsec.io/) | PRL Token l PRL Tokenomics | 2025-01 | [bailsec-report](https://github.com/parallel-protocol/PRL-token/blob/main/docs/audits/Bailsec%20-%20Parallel%20Protocol%20-%20PRL%20Token%20-%20Final%20Report%20-%20January%202025.pdf) | | [Bail Security](https://bailsec.io/) | Parallel Bridging Module l Parallel V2 VaultsCoreState | 2025-01-13 | [bailsec-report](https://github.com/parallel-protocol/bridging-module/blob/main/docs/audits/Bailsec%20-%20Parallel%20Bridge%20-%20BridgeableToken%20-%20Final%20Report%20-%20December%202024.pdf) | | [Bail Security](https://bailsec.io/) | Parallel Bridging Module | 2024-08-21 | [bailsec-report](https://github.com/parallel-protocol/bridging-module/blob/main/docs/audits/Bailsec%20-%20Parallel%20Bridge%20-%20BridgeableToken%20-%20Final%20Report%20-%20July%202024.pdf) | | [Code4rena](https://code4rena.com/) | SuperVaults V2 | 2022-08-07 | [code4rena-report](https://code4rena.com/reports/2022-08-mimo) | | [Code4rena](https://code4rena.com/) | Inception Vaults l Liquidity Mining V2 l LP Token Oracles l SuperVaults V1 | 2022-05-02 | [code4rena-report](https://code4rena.com/reports/2022-04-mimo) | | [Certik](https://www.certik.com/) | Parallel V2 | 2021-04-18 | [certik-report](https://github.com/code-423n4/2022-04-mimo/blob/main/core/audits/certik.pdf) | | [Quantstamp](https://quantstamp.com/) | Parallel V2 | 2021-01-29 | [quantstamp-report](https://certificate.quantstamp.com/full/ten-x-titan.pdf) | :::info Developers can access the [developers documentation](/developers-hub/developers-guide) for a technical description of the Parallel Protocol. ::: # Parallel Governance Token (PRL) PRL is the governance token of the Parallel Protocol, which is a DAO-governed protocol. Changes are made through proposals and voted by stakers of the PRL token. * **Name:** Parallel Governance Token * **Symbol:** PRL * **Native blockchain deployed:** Ethereum * **Total Supply:** 1,000,000,000 * **Decimals:** 18 * **Permit:** Yes * **Pause function:** No * **Admin function:** No * **Mint function:** No :::info PRL can be staked for sPRL to get voting power in the governance and receive fee sharing. Learn more [here](/governance/parallel-governance-token-prl/tokenomics). ::: ## PRL Contract Addresses | Blockchain | Contract Address | | ----------- | -------------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [0x6c0aeceeDc55c9d55d8B99216a670D85330941c3](https://etherscan.io/address/0x6c0aeceeDc55c9d55d8B99216a670D85330941c3) | | Polygon PoS | [0x7790dd69aa10eD3f1271E41CD7222D2a7d2D5948](https://polygonscan.com/address/0x7790dd69aa10eD3f1271E41CD7222D2a7d2D5948) | | Base | [0xfD28f108e95f4D41daAE9dbfFf707D677985998E](https://basescan.org/address/0xfD28f108e95f4D41daAE9dbfFf707D677985998E) | | Sonic | [0xfD28f108e95f4D41daAE9dbfFf707D677985998E](https://sonicscan.org/address/0xfD28f108e95f4D41daAE9dbfFf707D677985998E) | | Arbitrum | [0xfD28f108e95f4D41daAE9dbfFf707D677985998E](https://arbiscan.io/address/0xfD28f108e95f4D41daAE9dbfFf707D677985998E) | | Optimism | [0xfD28f108e95f4D41daAE9dbfFf707D677985998E](https://optimistic.etherscan.io/address/0xfD28f108e95f4D41daAE9dbfFf707D677985998E) | :::info PRL can be bridged to any supported chain listed above. Learn more [here](/governance/parallel-governance-token-prl/bridging-module). ::: ## Codebase & License The PRL codebase is publicly available [here](https://github.com/parallel-protocol/) and is released under the MIT License. The code has been audited by Bail Security & Zenith. Audit reports are available [here](/security/audits). More technical informations available in the [developers documentation](/developers-hub/parallel-governance-token-prl). # Issuance ## Issuance Overview Below is a general overview of the supply over time by incorporating the weekly reduction of the inflation as well as the supply generated by the [TenX and PAY token holder](https://medium.com/mimodefi-blog/claim-your-mimo-tokens-guide-e983bbc4558f) claim that started the 9 April 2021 and ended the 1st April 2022. ![Issuance Overview](/images/9HvEUhJOF7zov7uukQuu.png) ## Issuance Distribution Following [PIP-46 l Introducing Parallel Tokenomics v2.0](https://gov.parallel.best/t/pip-46-l-introducing-parallel-tokenomics-v2-0/460), the Parallel DAO decided to update the repartition of the PRL issuance distribution. Below is the approved PRL issuance distribution: | Blockchain | Issuance Receiver | Percentage Received (of total in %) | | ---------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------- | | Ethereum | [DAO l PRL Inflation Multisig](https://etherscan.io/address/0x29391a7a809aC7dEe6a7F9a014F7EaB606fAA4E5) | 100 | # Bridging Module The PRL bridging module is a secure, scalable, and decentralized bridging infrastructure which enable seamless transfer of PRL between supported chains. The module is designed to be highly flexible while maintaining robust security, allowing the Parallel Protocol to expand across multiple chains in a secure way. Built on LayerZero's infrastructure, it offers several key features: ## Security & Architecture * Utilizes LayerZero's decentralized message verification and execution infrastructure * Implements a modular security stack with configurable Decentralized Verifier Networks (DVNs) * Employs an "X of Y of N" security model allowing flexible combinations of validators * Includes fallback mechanisms through permissionless execution if automated systems fail * Follows the Omnichain Fungible Token (OFT) standard ## Key Features * **Emergency Controls**: Pause/unpause functionality for risk management * **Fully DAO Controlled**: All parameters and operations managed by governance ## Risk Management * Chain-specific isolation modes to prevent risk propagation * Multiple DVNs required for transaction verification * Automatic transaction reversal if required validators are unavailable * Full governance control over all security parameters :::info Learn how to bridge PRL across chains by following this guide. ::: # Specifications ## OFT Standard The PRL bridging module is following the Omnichain Fungible Token (OFT) Standard created by LayerZero. It means that the bridged PRL will be an OFT on every chain. You can find more information about it [here](https://docs.layerzero.network/v2/developers/evm/oft/quickstart). ## 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](https://layerzeroscan.com/) or the destination blockchain block explorer. ## Extensible Let’s say the PRL bridging module 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. ## Pause/Unpause: To make the protocol more secure in case of a problem, we've added the possibility to pause the PRL ‘burn’ function. This function can be called by[ emergency guardians](https://docs.mimo.capital/parallel-protocol/governance/parallel-emergency-guardians) as well as by the DAO via a vote. The ‘burn’ function can be deactivated and reactivated via the 'pause' and 'unpause' functions. # Implementation ## Ethereum: * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Canary * Horizen ## Polygon PoS * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Canary * Horizen ## Arbitrum * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Canary * Horizen ## Optimism * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Canary * Horizen ## Base * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Canary * Horizen ## Sonic * DVNs: (2 of 1 of 2) * Required: 2 * LayerZero Labs * Nethermind * Optionals: 1 of 2 * Canary * Horizen # Tokenomics The new Parallel protocol tokenomics is a complete overhaul of the way PRL is involved in the economic and social operations of the protocol, with the aim of aligning the short-term and long-term interests of PRL users, holders and the protocol. The biggest changes introduced are PRL staking; Parallel Boost (Paraboost), a new incentive model to reward positive externalities that benefit the protocol; and the distribution of revenues generated by the protocol to PRL stakers.

Parallel Tokenomics Overview

# Epoch Concept The epoch will serve as the central unit of time in the new tokenomics. An epoch consists of a number of 30 days. It will be used to determine the [ParaBoost](/governance/parallel-governance-token-prl/tokenomics/paraboost) calculation period, the duration of the cooldown during unstaking sPRL1 and sPRL2 and to manage the [fee sharing](/governance/parallel-governance-token-prl/tokenomics/fee-distribution) distribution to sPRL1 and sPRL2 holders. # Staking Mechanisms PRL holders have the option to stake their tokens in 2 different forms: sPRL1, single PRL staking; and sPRL2, PRL/wETH 80/20 BPT staking. Each option allows holders to choose the risk they are willing to take. :::warning sPRL1 & sPRL2 are represented in form of tokens and will be freely transferable, however in case of transfer, the accumulated Paraboost will be lost (more details about Paraboost [here](/governance/parallel-governance-token-prl/tokenomics/paraboost)). ::: :::info The PRL staking modules can be deployed on several blockchains at once. :::

Staking Mechanisms Summary

It is possible for sPRL1 and sPRL2 to initiate unstaking at any time, against a cooldown period of 1 epoch. However, they are able to bypass the vesting period by paying a penalty fee, starting at 50% and decreasing linearly over time. The penalty fee is taken from the amount of sPRL1 or sPRL2 being unstaked and is sent to the DAO Treasury.

Penalty Fee Over Time

### sPRL1: Single PRL Staking A basic single-sided staking for users who do not want to take an impermanent loss from tokens in liquidity pools. Each PRL staked as sPRL1 will count as x1 voting power, with a 1 epoch unstaking cooldown. sPRL1 is currently deployed on: * Ethereum * Polygon PoS * Base * Sonic :::info sPRL1 can technically be deployed on more chains in the future, conditioned to the availability of PRL on the chain. ::: ### sPRL2: Liquidity Pool Staking A PRL/wETH 80/20 Balancer Pool Token staking for users who want to get the maximum voting power. The staked LP as sPRL2 is itself staked on Aura under the hood, with rewards in $BAL and $AURA automatically sent to the DAO treasury. As these stakers help Parallel increase the PRL liquidity a x2.5 boost on the equivalent value of PRL tokens staked (in $) is applied. This boost ise applied for ParaBoost. sPRL2 holders are able to unstake their BPT tokens against a 1 epoch unstaking cooldown. sPRL2 is currently deployed on: * Ethereum :::info sPRL2 can technically be deployed on more chains in the future, conditioned to the availability of PRL, Balancer/Beets & Aura on the chain. :::
# ParaBoost Parallel Boost (ParaBoost) is a concept that distributes fees to PRL stakers who generate the most positive externalities that benefit the protocol. This new concept aligns the short and long-term interests of both the protocol, by encouraging more use of it; PRL holders, by encouraging them to stake their tokens and interact with it; and ordinary users, encouraged to buy and stake PRL tokens to obtain additional benefits.

ParaBoost Examples

The ParaBoost will be computed offchain by a keeper (Cooper Labs) at the end of an epoch and a merkle root is sent to the rewardDistributor contract. :::info Due to time constraints (to get V3 out faster) we decided to simplify Paraboost as much as possible for tokenomics v2.0. A more complete version of ParaBoost will be presented with the introduction of tokenomics v2.1, which will be released after Parallel V3. As ParaBoost is calculated entirely offchain, there will be no need to update smart contracts or perform new audits. ::: ### sPRL The weight of sPRL2 relatively to sPRL1 in the ParaBoost calculation is multiplied byu x2.5. The calculation is based on the dollar value of sPRL1 & sPRL2.

sPRL ParaBoost Overview

# Fee Distribution One of the major innovations implemented with the PRL new tokenomics is the redistribution of a portion of the fees generated by the protocol to [PRL stakers](/governance/parallel-governance-token-prl/tokenomics/staking-mechanisms) (sPRL1 & sPRL2). Fees accumulated during an epoch will be converted to PAR tokens on each chain where the protocol generates fees via a keeper (Cooper Labs); and then automatically bridged to the fee distribution chain (Polygon PoS). 15% of these fees are then be distributed to PRL stakers according to their ParaBoost. It means that PRL stakers are receiving 15% of generated protocol fees in PAR at the end of each epoch to be claimed on Polygon PoS.

Protocol Fees Distribution Overview

\ The fees distributed to the PRL stakers are distributed on the same chain, regardless of the chain where the PRL tokens are staked. Stakers will be able to claim their tokens during 12 epochs (≃1 year), after which the tokens will be automatically returned to the DAO treasury. # Governance sPRL1 and sPRL2 holders have voting power in the Parallel governance, calculated via the ParaBoost of the previous epoch. To learn more about Governance Process you can refer to the [Governance Process](/governance/governance-process). :::warning sPRL1 & sPRL2 are represented in form of tokens and will be freely transferable, however in case of transfer, the accumulated Paraboost, thus the voting power will be reset (more details about Paraboost [here](/governance/parallel-governance-token-prl/tokenomics/paraboost)). ::: # MIMO to PRL Migration On April 18th 2025 the DAO approved a migration of the MIMO Token (the previous governance token of the Parallel Protocol) for a new token, PRL. ## Specifications The total MIMO token supply is 1,000,000,000 tokens. As the PRL token is also having a supply of 1,000,000,000 tokens, a 1:1 migration (1 MIMO -> 1 PRL) has been approved. This means there will be no new token inflation, and no prejudice to current and future token holders. In order to not penalize any MIMO holders, we built the migration module without the possibility of setting a migration deadline, allowing MIMO token holders to migrate to the PRL token without any deadline. However, the MIMO -> PRL migration will be definitive, and it will be impossible to perform the reverse migration once it has been completed. The DAO will also be able to pause/unpause migration contracts on each chain. ## What happened to vMIMO? MIMO tokens locked as vMIMO on Ethereum & Polygon PoS have been unlocked in order to let holders migrate to the PRL token. ## Can i migrate my MIMO if i own them on Fantom? Following the multichain\[.]org hack in 2023, holders of MIMO tokens on Fantom found themselves unable to bridge their tokens back to Ethereum. Thanks to the crosschain PRL migration architecture, MIMO blocked on Fantom are also able to migrate to PRL on any chain, enabling holders to regain full possession of their tokens. :::info Learn how to migrate MIMO to PRL by following this [guide](https://blog.parallel.best/how-to-migrate-to-prl). ::: # sPRL and Voting Power ## sPRL1 & sPRL2 = Voting Power In order to participate in Parallel Protocol governance, token holders must stake their PRL tokens for sPRL. Users are receiving sPRL1 and/or sPRL2, which are transferable tokens depending on their preference. :::warning sPRL1 & sPRL2 are represented in form of tokens and will be freely transferable, however in case of transfer, the accumulated Paraboost will be lost (more details about Paraboost [here](/governance/parallel-governance-token-prl/tokenomics/paraboost)). :::

Staking Mechanisms Summary

It is possible for sPRL1 and sPRL2 to initiate unstaking at any time, against a cooldown period of 1 epoch. However, they are able to bypass the vesting period by paying a penalty fee, starting at 50% and decreasing linearly over time. The penalty fee is taken from the amount of sPRL1 or sPRL2 being unstaked and is sent to the DAO Treasury.

Penalty Fee Over Time

### sPRL1: Single PRL Staking A basic single-sided staking for users who do not want to take an impermanent loss from tokens in liquidity pools. Each PRL staked as sPRL1 will count as x1 voting power, with a 1 epoch unstaking cooldown. sPRL1 is currently deployed on: * Ethereum * Polygon PoS * Base * Sonic ### sPRL2: Liquidity Pool Staking A PRL/wETH 80/20 Balancer Pool Token staking for users who want to get the maximum voting power. The staked LP as sPRL2 is itself staked on Aura under the hood, with rewards in $BAL and $AURA automatically sent to the DAO treasury. As these stakers help Parallel increase the PRL liquidity a x2.5 boost on the equivalent value of PRL tokens staked (in $) is applied. This boost ise applied for ParaBoost. sPRL2 holders are able to unstake their BPT tokens against a 1 epoch unstaking cooldown. sPRL2 is currently deployed on: * Ethereum ## **Where to stake PRL?** You can increase your voting power by staking PRL [here](https://app.parallel.best//stake) and obtain sPRL1 and/or sPRL2. :::info If you don't know how to stake PRL, you can follow this guide. ::: ## What next? Now that you have sPRL, you can participate in the various governance proposals, published on the [governance forum](https://gov.parallel.best/). :::info Any user can choose to delegate all or a portion of his voting power to someone else on the Parallel [dApp](https://app.parallel.best//stake) by clicking on " change delegate". ::: :::warning Be sure to stake your PRL before the snapshot vote starts, or your PRL will not be available for voting! ::: # Governance Process The Parallel Protocol is controlled by sPRL token holders who vote on off-chain proposals (on Parallel [Snapshot](https://vote.parallel.best/#/)) that govern the protocol. Proposals getting a majority support (>50% of the votes and reach the quorum) are executed by the [DAO Multisig](/governance/dao-multisigs). ## Governance Proposals Process The steps for a successful governance proposal are: 1. Create a proposal by using the [Proposal Framework](/governance/proposal-framework) to share on the [Forum](https://gov.parallel.best/) and discuss with DAO members. 2. Exchange with DAO members for a minimum of 48 hours on the forum then update to proposal if it is needed. 3. Post the proposal on the Parallel [Snapshot](https://vote.parallel.best/#/) by following the [Proposal Framework](/governance/proposal-framework). If successful, the proposal payload will be executed and implemented by the [DAO Multisig](/governance/dao-multisigs). :::info A step by step guide for submitting a new asset listing can be found [here](/governance/proposal-framework/parallel-integration-request-pir). ::: ## **DAO Discussion** Discussion regarding changes in the protocol happen on the following channels: * [Governance Forum](https://gov.parallel.best/) * [Telegram](https://t.me/parallel_money) * [Discord](https://discord.gg/8zEYgupTyF) :::warning Following and participating in the various governance discussions is as important for you as it is for the protocol, we need to gather your opinions to best meet the needs of users and the protocol. ::: # Proposal Framework With the recent Parallel Governance Framework Proposal [update](https://gov.parallel.best/t/mip-29-l-update-the-governance-framework/384), the Parallel protocol and its governance are officially laid out, voted on, and put into action. While Parallel, since its inception, has operated by holding decisions to a vote, the updated framework brings a much clearer picture of how governance will take place and what this means for the protocol moving forward. The main components of this initial proposal are simply outlining how decisions are going to be proposed and executed. These are broken down into three categories: [PIR](/governance/proposal-framework/parallel-integration-request-pir), [PGP](/governance/proposal-framework/parallel-governance-proposal-pgp), and [PIP](/governance/proposal-framework/parallel-improvement-protocol-pip). :::info Posting a proposal on the governance forum and discussing it there and on discord first allow to get a sentiment check and some valuable feedback about the community ideas and upcoming snapshot votes. We could open a channel for each proposal on discord and archive it once voted. ::: ## Summary

Summary

## Required Informations for any Proposal: * **Governance forum post:** Each proposal should be posted on the governance forum for at least 48 hours before posting the snapshot, which allows the dao members to give feedbacks, propose changes, and vote on a sentiment poll. * **Proposal type, number and name:** Each proposal must be easily identifiable and correctly classified. * Type: [PIR](/governance/proposal-framework/parallel-integration-request-pir) - [PGP](/governance/proposal-framework/parallel-governance-proposal-pgp) - [PIP](/governance/proposal-framework/parallel-integration-request-pir) * Name: The name must be the same on the forum post and snapshot (Around 15 words) * Number: Each proposal must have a number that represents the post order on the forum and on snapshot * **Summary:** Short description of the proposal (1-2 sentences max) * **Rationale:** Detailed explanation of the proposal and milestones for its execution. * **Means:** Resources needed for this proposal * Human resources: Special skills required (dev or others) * Treasury ressources: Proposal cost (in PRL and in $), % of the treasury required * **Technical implementation:** Highlight the technical implementations of this proposal if any * **Voting options:** Mention the options that will be included on the snapshot vote, including an “Abstain” one. :::info The amount of sPRL (ParaBoost) required to publish a proposal on Snapshot would also be set to 100,000 sPRL (ParaBoost). ::: ## **Proposal Types** ### [Parallel Integration Request (PIR)](/governance/proposal-framework/parallel-integration-request-pir) PIR are proposals to add a token as a collateral. The surrounding decisions to be worked through include minimum collateral ratio, and any short term partnerships. Each request will require some information and details about the integration like the name of the token, audits, chain(s) requested, and any appropriate links. All integration requests go through a risk assessment process where we consider things like counterparty risk, smart contract risk, and community size. ### [Parallel Governance Proposal (PGP)](/governance/proposal-framework/parallel-governance-proposal-pgp) PGP are about common governance. These are topics related to the treasury of the protocol and the DAO organization. PGP may include things like liquidity mining votes, long term partnerships (i.e. DAO swaps), treasury allocation and budgets. The proposal also outlines how more conservative parameters are best for PGP since they relate to the treasury. ### [Parallel Improvement Protocol (PIP)](/governance/proposal-framework/parallel-improvement-protocol-pip) PIP are the most important modifications regarding both governance and the protocol directly. These proposals are going to provide context and explain in detail what this means for Parallel as a whole. Examples of PIP could be new version, smart contract modifications, governance framework updates, or updating signers on the treasury multisig. Since these are more critical to the protocol, it’s also important to include as much possible sPRL holders and increase the quorum so it’s a full and fair vote. :::info To get more involved, don’t forget to [stake PRL](/governance/parallel-governance-token-prl/tokenomics/staking-mechanisms) & join [Telegram](https://t.me/mimo_labs) and [Discord](https://discord.gg/8zEYgupTyF) for general information. ::: # Parallel Integration Request (PIR) ## New Asset Listing The Parallel protocol can support many different assets in many different markets. Each market operates as a segregated risk pool, with the addition of each new asset influencing the overall risk of that particular market. * The increased insolvency risk of the market it is listed in. * The potential to expose the market it is listed in to a single point of failure. * The risks associated with collateral currencies. * The benefits of protocol/market diversification. ## 1. Proposing the asset via the PIR Process As with all governance upgrades, PIR Template is recommended. * **Project Presentation:** (After summary) * Protocol name * Token requested * Token contract address * Audit(s) links * Chain requested: Ethereum/Base/Sonic * Relation with the project * X/Discord/Telegram links * **Token metrics:** (After project presentation) * **Risk assessment:** * Smart Contract risk: maturity, transactions * Counterparty risk: holders, permission * Market Risk: market cap, average volume, normalized volatility * Use the Parallel Methodology (more [here](https://docs.mimo.capital/parallel-protocol/risk/parallels-risk-framework)) * Community size on Twitter/Discord/Telegram * **Sentiment poll:** (After voting options) * A poll on the governance forum post to get a first sentiment at least 48 hours before submitting a snapshot proposa ## 2. Submission of Proposal The proposal can now be submitted on [Snapshot](https://snapshot.box/#/s:mimo.eth), including all the information from the above steps. Considering that the integrations proposals can happen quite often and that the risk for the protocol is lower than other proposal types, we could consider the following parameters: * Admin: DAO Multisig * Quorum: 100,000 sPRL (ParaBoost) * Voting Duration: 5 days # Parallel Governance Proposal (PGP) ## 1. Writing a PGP PGP are about common governance proposals, especially the ones related to the treasury of the protocol and the DAO organization. * **The PGP would concern but wouldn’t be limited to:** * Treasury allocation strategy & budgets * Liquidity mining votes * Grant program if any * Contributors/Dao committees rewards * Long term partnerships (i.e Dao Swaps) ## 2. Submission of Proposal PGP concern the protocol treasury directly, which is why it might be best to define more conservative parameters than PIR ones: * Admin: DAO Multisig * Quorum: 200,000 sPRL (ParaBoost) * Voting Duration: 7 days # Parallel Improvement Protocol (PIP) ## 1. Writing a PIP PIP are about the most important modifications either to the governance framework, or to the protocol directly. PIP should include all the relevant information as well as links to the forum discussion and snapshot vote. * **This type of proposal should include, in addition to all the points mentioned in the first part:** * Context: What’s the modification and why it’s needed. * **PIP would concern but wouldn’t be limited to:** * New version of the protocol * Modification of a smart contract * Updates on the initial parameters * Modification of the governance framework * Add/Remove a signer on the treasury multisig PIP are the most critical and important types of proposals, as it’s directly about the core product of Parallel or a major change in the functioning of governance. ## 2. Submission of Proposal It’s very important to get as many DAO members aware of this kind of proposal for them to vote accordingly, which is why we should consider more conservative parameters, and a longer voting period: * Admin: DAO Multisig * Quorum: 300,000 sPRL (ParaBoost) * Voting Duration: 9 days # DAO Multisigs DAO multisigs controls several functions of the protocol including the treasury, protocol parameters and the blog. The DAO multisig will require 5/8 signatures to execute a transaction. ## Who participates in the multisig ? DAO Multisigs are composed by 8 members and require at least 5 signatures to execute a transaction. Signers are coordinating via a channel used solely for this purpose on the Parallel [discord](https://discord.gg/mimodao). Being a multisig signer is not something to be taken lightly. Multisigs signers have full control over the protocol, the slightest mistake can have very important consequences for the users of the protocol as well as the protocol itself. ## DAO Signers Compensations DAO signers are compensated on a scale based on the % of signatures made per month: * 90 + signed: 150 USDp * 70 + signed: 105 USDp * 50 + signed: 75 USDp * 30 + signed: 45 USDp * 30 - signed: nothing :::info Find out the DAO Multisig Elections [here](/governance/dao-multisigs/dao-multisigs-elections). ::: ## Multisigs Addresses ### Ethereum | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0x25Fc7ffa8f9da3582a36633d04804F0004706F9b](https://etherscan.io/address/0x25Fc7ffa8f9da3582a36633d04804F0004706F9b) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://etherscan.io/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c) | ### Polygon | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Protocol & DAO Treasury | 5 out 8 signers | [0x2046c0416A558C40cb112E5ebB0Ca764c3C5c32a](https://polygonscan.com/address/0x2046c0416A558C40cb112E5ebB0Ca764c3C5c32a) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://polygonscan.com/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c) | ### HyperEVM | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://hyperevmscan.io/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://hyperevmscan.io/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | ### Base | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://basescan.org/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://basescan.org/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | ### Sonic | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://sonicscan.org/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://sonicscan.org/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | ### Arbitrum | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://arbiscan.io/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://arbiscan.io/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | ### Optimism | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://optimistic.etherscan.io/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://optimistic.etherscan.io/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | ### Gnosis | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://gnosisscan.io/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Linea | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://lineascan.build/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Scroll | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://scrollscan.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Avalanche | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://snowscan.xyz/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://snowscan.xyz/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | ### Binance Smart Chain | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://bscscan.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Ink | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://explorer.inkonchain.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95?tab=contract) | ### Berachain | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://berascan.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Unichain | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://uniscan.xyz/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | | Insurance Fund | 5 out 8 signers | [0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c](https://uniscan.xyz/address/0x6aF71a3723D3c0Ed69f84EE259c9De3019C2a77c#code) | ### Sei | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0x1AD681fa147f35AB7B35c7a289B1938Bc0171e8b](https://seitrace.com/address/0x1AD681fa147f35AB7B35c7a289B1938Bc0171e8b?tab=contract) | ### Tac | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0x1AD681fa147f35AB7B35c7a289B1938Bc0171e8b](https://explorer.tac.build/address/0x1AD681fa147f35AB7B35c7a289B1938Bc0171e8b?tab=contract) | ### X Layer | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://www.oklink.com/fr/x-layer/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95/contract) | ### Plume | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xd22b9E8eE5B6490C667D90c6819E53e9503EE139](https://explorer.plume.org/address/0xd22b9E8eE5B6490C667D90c6819E53e9503EE139?tab=contract) | ### Plasma | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://plasmascan.to/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Linea | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://lineascan.build/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Katana | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://katanascan.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Fraxtal | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xF6Cd93af204947c9aAF55B15d907f8F4D08b91A3](https://fraxscan.com/address/0xF6Cd93af204947c9aAF55B15d907f8F4D08b91A3#code) | ### World | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://worldchain-mainnet.explorer.alchemy.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95?tab=contract) | ### Hemi | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://explorer.hemi.xyz/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95?tab=contract) | ### Fantom | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0x174162ddecE9d0b7B68fd945e38c3372C4C818ba](https://ftmscan.com/address/0x174162ddecE9d0b7B68fd945e38c3372C4C818ba/transactions) | # DAO Multisigs Elections Multisigs DAO signers are elected every 6 months. Find out about previous elections here: ### History: * [Election 1 ](/governance/dao-multisigs/dao-multisigs-elections/election-1) * [Election 2](/governance/dao-multisigs/dao-multisigs-elections/election-2) * [Election 3](/governance/dao-multisigs/dao-multisigs-elections/election-3) * [Election 4](/governance/dao-multisigs/dao-multisigs-elections/election-4) * [Election 5](/governance/dao-multisigs/dao-multisigs-elections/election-5) * [Election 6](/governance/dao-multisigs/dao-multisigs-elections/election-6) * [Election 7](/governance/dao-multisigs/dao-multisigs-elections/election-7) * [Election 8](/governance/dao-multisigs/dao-multisigs-elections/election-8) # Election 1 Discussion: [MIP-1┃DAO Multisig Election 1 ](https://gov.parallel.best/t/mip-1-dao-multisig-election-1/157)\ Vote: [Snapshot](https://vote.parallel.best/#/proposal/0x3fde565cf8e6b8505efbf7c7a76c4535c7e36d7a992f92411607f18b665d6f9e) ## **DAO Members Elected** * Adriennejko: [wallet](https://etherscan.io/address/0x3f41a1cfd3c8b8d9c162de0f42307a0095a6e5df) * Georgeous: [wallet](https://etherscan.io/address/0x35b3e718aAfd5F932450eeb8690D022a96AAd78a) * Beudeuleu: [wallet](https://etherscan.io/address/0xDDA8B734620108A8c22f3d7a03CB7Ffa5b868dd3) * Arjpet: [wallet](https://etherscan.io/address/0xd758e17c0d96a6c753995d86e891e07286858130) ## **Mimo Labs Member Elected** * Klodio (CEO): [wallet](https://etherscan.io/address/0x27a56858b02cA4867eBfb17F67D8618CBf91e26b) * Bad (CTO): [wallet](https://etherscan.io/address/0xaC3203D77823496E421aA7E88CDC2F6C387d6182) * Martijn (Developer): [wallet](https://etherscan.io/address/0xBCa2ef443E78464802445634B3c1f525488f4ECF) * Jean Brasse (DeFi Strategist): [wallet](https://etherscan.io/address/0xBabB038737A7Ae0DcA02075E79ed5B7704C29827) # Election 2 Discussion: [MIP-10┃DAO Multisig Election 2](https://gov.parallel.best/t/mip-10-dao-multisig-election-2/215)\ Vote: [Snapshot](https://vote.parallel.best/#/proposal/0x2be8d0f2156478f6ac55b66ba3ca66b907e723df1e39ffd08f2e695fac7b460a) ## **DAO Members Elected** * Georgeous: [wallet](https://etherscan.io/address/0x35b3e718aAfd5F932450eeb8690D022a96AAd78a) * Arjpet: [wallet](https://etherscan.io/address/0xd758e17c0d96a6c753995d86e891e07286858130) * Dossy: [wallet](https://etherscan.io/address/0x3346Ef6d672C5729D2BdA3108d5EDD43De8788E7) * Squirrely: [wallet](https://etherscan.io/address/0x8222624ae36fa6d21e32801cca2b5af54669e290) ## **Mimo Labs Member Elected** * Klodio (CEO): [wallet](https://etherscan.io/address/0x27a56858b02cA4867eBfb17F67D8618CBf91e26b) * \*NEW\* Fred (COO): [wallet](https://etherscan.io/address/0xAfb96AFae3f780565406E42aC4A20165ecf99883) * Martijn (Developer): [wallet](https://etherscan.io/address/0xBCa2ef443E78464802445634B3c1f525488f4ECF) * Jean Brasse (DeFi Strategist): [wallet](https://etherscan.io/address/0xBabB038737A7Ae0DcA02075E79ed5B7704C29827) # Election 3 Discussion: [MIP-15┃DAO Multisig Election 3](https://gov.parallel.best/t/mip-15-dao-multisig-election-3/279)\ Vote: [Snapshot](https://vote.parallel.best/#/proposal/0x62fd7e2bc87ecaccea859725ef652cbd72d1fcacc1eddbd783fcd6ac8f1be9df) ## **DAO Members Elected** * Georgeous: [wallet](https://etherscan.io/address/0x35b3e718aAfd5F932450eeb8690D022a96AAd78a) * Arjpet: [wallet](https://etherscan.io/address/0xd758e17c0d96a6c753995d86e891e07286858130) * Squirrely: [wallet](https://etherscan.io/address/0x8222624ae36fa6d21e32801cca2b5af54669e290) * 0xEvix: [wallet](https://etherscan.io/address/0xCAA713508eD800c75808ad51f035881Fb422a9E1) ## **Mimo Labs Member Elected** * Klodio (CEO): [wallet](https://etherscan.io/address/0x27a56858b02cA4867eBfb17F67D8618CBf91e26b) * Fred (COO): [wallet](https://etherscan.io/address/0xAfb96AFae3f780565406E42aC4A20165ecf99883) * Martijn (Developer): [wallet](https://etherscan.io/address/0xBCa2ef443E78464802445634B3c1f525488f4ECF) * Jean Brasse (DeFi Strategist): [wallet](https://etherscan.io/address/0xBabB038737A7Ae0DcA02075E79ed5B7704C29827) # Election 4 Discussion: [MIP-18┃DAO Multisig Election 4](https://gov.parallel.best/t/mip-18-dao-multisig-election-4/312)\ Vote: [Snapshot](https://vote.parallel.best/#/proposal/0x87b41ed131b490daed529fd50de65d0b23fc7f20df3eb37bbb84eaa7a4745f74) ## **DAO Members Elected** * Georgeous: [wallet](https://etherscan.io/address/0x35b3e718aAfd5F932450eeb8690D022a96AAd78a) * Arjpet: [wallet](https://etherscan.io/address/0xd758e17c0d96a6c753995d86e891e07286858130) * Squirrely: [wallet](https://etherscan.io/address/0x8222624ae36fa6d21e32801cca2b5af54669e290) * 0xEvix: [wallet](https://etherscan.io/address/0xCAA713508eD800c75808ad51f035881Fb422a9E1) ## **Mimo Labs Member Elected** * Klodio (CEO): [wallet](https://etherscan.io/address/0x27a56858b02cA4867eBfb17F67D8618CBf91e26b) * Fred (COO): [wallet](https://etherscan.io/address/0xAfb96AFae3f780565406E42aC4A20165ecf99883) * Martijn (Developer): [wallet](https://etherscan.io/address/0xBCa2ef443E78464802445634B3c1f525488f4ECF) (replaced by Bad (CTO): [wallet](https://etherscan.io/address/eth:0xaC3203D77823496E421aA7E88CDC2F6C387d6182)) * Jean Brasse (DeFi Strategist): [wallet](https://etherscan.io/address/0xBabB038737A7Ae0DcA02075E79ed5B7704C29827) # Election 5 Discussion: [MIP-26 l DAO Multisig Election 5](https://gov.parallel.best/t/mip-26-l-dao-multisig-election-5/361)\ Vote: [Snapshot](https://vote.parallel.best/#/proposal/0x981e20b5f35713ed8b7c011ccd749e557536b1a0d8bc96c576b8b5708598054b) ## **Elected Signers** * Jean Brasse: [wallet](https://etherscan.io/address/0xBabB038737A7Ae0DcA02075E79ed5B7704C29827) * Boka: [wallet](https://etherscan.io/address/0x4C5d1029C2c64fC6477529d5A391cA667a514B4C) * Starny: [wallet](https://etherscan.io/address/0x79603115Df2Ba00659ADC63192325CF104ca529C) * Squirrely: [wallet](https://etherscan.io/address/0x8222624ae36fa6d21e32801cca2b5af54669e290) * Arjpet: [wallet](https://etherscan.io/address/0xd758e17c0d96a6c753995d86e891e07286858130) * 0xEvix: [wallet](https://etherscan.io/address/0xCAA713508eD800c75808ad51f035881Fb422a9E1) * Fred: [wallet](https://etherscan.io/address/0xAfb96AFae3f780565406E42aC4A20165ecf99883) * Sogiw: [wallet](https://etherscan.io/address/0xd7F639F56bc91DE6a7f9a2Fe981d9894553a6469) # Election 6 Discussion: [PIP-38 l DAO Multisig Election 6](https://gov.parallel.best/t/pip-38-l-dao-multisig-election-6/423)\ Vote: [Snapshot](https://vote.parallel.best/#/proposal/0xcc2690978503366a7cd519ac63ec84f48b7b0fc438e5811d7f16254cee1fa049) ## **Elected Signers** * Jean Brasse: [wallet](https://etherscan.io/address/0xBabB038737A7Ae0DcA02075E79ed5B7704C29827) * Sogiw: [wallet](https://etherscan.io/address/0xd7F639F56bc91DE6a7f9a2Fe981d9894553a6469) * Starny: [wallet](https://etherscan.io/address/0x79603115Df2Ba00659ADC63192325CF104ca529C) * Boka: [wallet](https://etherscan.io/address/0x4C5d1029C2c64fC6477529d5A391cA667a514B4C) * Squirrely: [wallet](https://etherscan.io/address/0x8222624ae36fa6d21e32801cca2b5af54669e290) * George: [wallet](https://etherscan.io/address/0x35b3e718aAfd5F932450eeb8690D022a96AAd78a) * Arjpet: [wallet](https://etherscan.io/address/0xd758e17c0d96a6c753995d86e891e07286858130) * Lelba: [wallet](https://etherscan.io/address/0x06C24D990EaAC2659565827788BDDb8c8fe31142) # Election 7 Discussion: [PIP-49 l DAO Multisig Election 7](https://gov.parallel.best/t/pip-49-l-dao-multisig-election-7/470)\ Vote: [Snapshot](https://vote.parallel.best/#/proposal/0x94ccc5b7521d94169caf5d896c6ec24447d086131af9280093aac59cb7f89314) ## **Elected Signers** * Jean Brasse: [wallet](https://etherscan.io/address/0xBabB038737A7Ae0DcA02075E79ed5B7704C29827) * Alex: [wallet](https://etherscan.io/address/0x244a875233a8898aA97753CD919857271079682c) * Starny: [wallet](https://etherscan.io/address/0x79603115Df2Ba00659ADC63192325CF104ca529C) * Boka: [wallet](https://etherscan.io/address/0x4C5d1029C2c64fC6477529d5A391cA667a514B4C) * Squirrely: [wallet](https://etherscan.io/address/0x8222624ae36fa6d21e32801cca2b5af54669e290) * George: [wallet](https://etherscan.io/address/0x35b3e718aAfd5F932450eeb8690D022a96AAd78a) * Arjpet: [wallet](https://etherscan.io/address/0xd758e17c0d96a6c753995d86e891e07286858130) * Lelba: [wallet](https://etherscan.io/address/0x06C24D990EaAC2659565827788BDDb8c8fe31142) # Election 8 Discussion: [PIP-53 l DAO Multisig Election 8](https://gov.parallel.best/t/pip-53-l-dao-multisig-election-8/498)\ Vote: [Snapshot](https://vote.parallel.best/#/proposal/0x082a0b916a6a3e14aaa3480dfa3626dc8f8c87a6a778fc04dd08498c20cff867) ## **Elected Signers** * Jean Brasse: [wallet](https://etherscan.io/address/0xBabB038737A7Ae0DcA02075E79ed5B7704C29827) * Alex: [wallet](https://etherscan.io/address/0x244a875233a8898aA97753CD919857271079682c) * Starny: [wallet](https://etherscan.io/address/0x79603115Df2Ba00659ADC63192325CF104ca529C) * Boka: [wallet](https://etherscan.io/address/0x4C5d1029C2c64fC6477529d5A391cA667a514B4C) * Squirrely: [wallet](https://etherscan.io/address/0x8222624ae36fa6d21e32801cca2b5af54669e290) * George: [wallet](https://etherscan.io/address/0x35b3e718aAfd5F932450eeb8690D022a96AAd78a) * Arjpet: [wallet](https://etherscan.io/address/0xd758e17c0d96a6c753995d86e891e07286858130) * Lelba: [wallet](https://etherscan.io/address/0x06C24D990EaAC2659565827788BDDb8c8fe31142) # DAO Treasury ## Overview To support the growth of the Parallel Protocol a protocol treasury has been set up, funded by the [fees](/products/parallel-v2/how-it-works/vaults/fees) generated by the protocol. Aggregated DAO Treasury can be seen using Octav in real time thanks to their analytics feature: ## Strategy Initiated by [MGP-12](https://gov.parallel.best/t/mgp-12-launch-mimo-treasury-strategy/264) and updated with [MGP-15](https://gov.parallel.best/t/mgp-15-update-treasury-strategy/294), [PGP-24](https://gov.parallel.best/t/pgp-24-l-update-treasury-strategy/434) & [PGP-30](https://gov.parallel.best/t/pgp-30-l-update-dao-treasury-strategy/481) a strategy treasury has been implemented by the Parallel DAO. The strategy is performed by the DAO Multisig. * General: * Every month, swap net accumulated (after service providers payment, etc…) paUSD, PAR & USDp to get a 30/70 split in $ equivalent in wETH (30%) and USDp * Every month, deposit and stake wETH with PRL from the treasury in PRL/wETH pools. chains, protocols and pools will be determined by the DAO multisigs with the advisory of Cooper Labs & Mimo Labs. This in order to bring greater flexibility in terms of management. * Every month, if there are not enough PRL in the treasury to get correct PRL/wETH ratio for LP, the DAO will buyback PRL tokens at the market via TWAP in order to get the right ratio to deposit in liquidity pools * Every month, deposit and stake USDp from the treasury in USDp/XYZ pools. Chains, protocols and pools will be determined by DAO multisig signers with advice from Cooper Labs & Mimo Labs. However pools must be non-IL, which means that USDp tokens can only be deposited in pools with another USD stablecoin. This in order to bring greater flexibility in terms of management. * Every 4 months, claim SPECTRA from sdSPECTRA staking → Deposit and stake them for sdSPECTRA * If there are funds deposited & staked on [Aura](https://aura.finance/): * Every month, claim BAL and AURA tokens from Aura * Every month, swap claimed BAL for AURA * Every month, lock AURA tokens and relock current vlAURA * If there are funds deposited & staked on [Beets](https://beets.fi/): * Every month, claim BEETS tokens from Beets * Every month,stake BEETS as maBEETS * If there are funds deposited & staked on [Shadow](https://www.shadow.so/): * Every month, claim SHADOW tokens from Shadow * Every month, lock xSHADOW * If there are funds deposited in another protocol not listed above we propose to let DAO Multisig signers manage what to do with rewards, with advice from Cooper Labs & Mimo Labs. This in order to bring greater flexibility in terms of management. Voting power from vlAURA, sdSPECTRA, xSHADOW, maBEETS & potential additional governance tokens has been delegated to Mimo Labs. At least 5,000,000 liquid PRL must stay in the DAO treasury. :::info If liquidity pools are to change over time, but retain the same tokens, multisig signers get the right to migrate liquidity to the new pools without the need for a DAO vote. ::: ## Multisigs Addresses ### Ethereum | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0x25Fc7ffa8f9da3582a36633d04804F0004706F9b](https://etherscan.io/address/0x25Fc7ffa8f9da3582a36633d04804F0004706F9b) | ### Polygon | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Protocol & DAO Treasury | 5 out 8 signers | [0x2046c0416A558C40cb112E5ebB0Ca764c3C5c32a](https://polygonscan.com/address/0x2046c0416A558C40cb112E5ebB0Ca764c3C5c32a) | ### HyperEVM | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://hyperevmscan.io/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Base | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://basescan.org/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Sonic | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://sonicscan.org/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Arbitrum | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://arbiscan.io/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Optimism | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://optimistic.etherscan.io/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Gnosis | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://gnosisscan.io/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Linea | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://lineascan.build/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Scroll | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://scrollscan.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Avalanche | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://snowscan.xyz/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Binance Smart Chain | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://bscscan.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95) | ### Ink | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://explorer.inkonchain.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95?tab=contract) | ### Berachain | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://berascan.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Unichain | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://uniscan.xyz/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Sei | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0x1AD681fa147f35AB7B35c7a289B1938Bc0171e8b](https://seitrace.com/address/0x1AD681fa147f35AB7B35c7a289B1938Bc0171e8b?tab=contract) | ### Tac | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0x1AD681fa147f35AB7B35c7a289B1938Bc0171e8b](https://explorer.tac.build/address/0x1AD681fa147f35AB7B35c7a289B1938Bc0171e8b?tab=contract) | ### X Layer | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://www.oklink.com/fr/x-layer/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95/contract) | ### Plume | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xd22b9E8eE5B6490C667D90c6819E53e9503EE139](https://explorer.plume.org/address/0xd22b9E8eE5B6490C667D90c6819E53e9503EE139?tab=contract) | ### Plasma | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://plasmascan.to/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Linea | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://lineascan.build/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Katana | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://katanascan.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95#code) | ### Fraxtal | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xF6Cd93af204947c9aAF55B15d907f8F4D08b91A3](https://fraxscan.com/address/0xF6Cd93af204947c9aAF55B15d907f8F4D08b91A3#code) | ### World | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://worldchain-mainnet.explorer.alchemy.com/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95?tab=contract) | ### Hemi | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95](https://explorer.hemi.xyz/address/0xC5201FFE258a95Af986E7cD1fcaD54f3f63f2C95?tab=contract) | ### Fantom | Multisig | Signatures Threshold | Address | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Protocol & DAO Treasury | 5 out 8 signers | [0x174162ddecE9d0b7B68fd945e38c3372C4C818ba](https://ftmscan.com/address/0x174162ddecE9d0b7B68fd945e38c3372C4C818ba/transactions) | # DAO Treasury Reports | Date | Holdings (USD) | Report | | --- | --- | --- | | July 2026 | $468,364.78 | | | June 2026 | $457,322.72 | | | May 2026 | $507,016.92 | | | April 2026 | $676,121.07 | | | March 2026 | $697,368.75 | | | February 2026 | $680,832.70 | | | January 2026 | $983,415 (5) | | | December 2025 | $931,019.92 (4) | | | November 2025 | $917,394.28 (3) | | | October 2025 | $1,012,227.06 (2) | | | September 2025 | $1,089,158.82 | | | August 2025 | $1,190,486.01 (1) | | | July 2025 | $1,145,622.10 | | | June 2025 | $936,816.45 | | | May 2025 | $1,275,075.08 | | | April 2025 | $1,237,004.60 | | | March 2025 | $1,210,407.92 | | | February 2025 | $982,361.42 | | | January 2025 | $1,045,416.56 | | | December 2024 | $1,021,455.67 | | | November 2024 | $812,255.48 | | :::warning 1. The August 2025 DAO Treasury Report doesn't count the value of 249,991 USDp. Thus the real DAO Treasury value is $1,190,486. 2. The October 2025 DAO Treasury Report doesn't count the value of 3,183,765.29 sdSPECTRA. Thus the real DAO Treasury value is $1,058,133. 3. The November 2025 DAO Treasury Report doesn't count the value of 3,183,765.29 sdSPECTRA. Thus the real DAO Treasury value is $944,232.28. 4. The December 2025 DAO Treasury Report doesn't count the value of 3,183,765.29 sdSPECTRA. Thus the real DAO Treasury value is $949,733.26. 5. The January 2026 DAO Treasury Report doesn't count the value of 3,183,765.29 sdSPECTRA. Thus the real DAO Treasury value is $1,001,189.96. ::: # Introduction Coming Soon ([https://github.com/orgs/parallel-protocol/repositories](https://github.com/orgs/parallel-protocol/repositories)) # Parallel Governance Token (PRL) ## Overview This document details features related to the new [PRL](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/PRL.sol) token and the migration from Mimo token to PRL. 3 types of contracts: * The [`PRL`](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/PRL.sol) token contract that inherit of Openzeppelin ERC20 and ERC20Permit standards. * The Migrations contracts handled by the [`PrincipalMigrationContract`](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/PrincipalMigrationContract.sol) and [`PeripheralMigrationContract`](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/peripheral/PeripheralMigrationContract.sol) contracts that leveraging on [LayerZero's OApp standard](https://docs.layerzero.network/v2/home/protocol/contract-standards#oapp) for migrating Mimo from anychain to PRL on anychain. * The Bridging of PRL, handled by the [`LockBox`](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/LockBox.sol) and [`PeripheralPRL`](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/peripheral/PeripheralPRL.sol) contracts that leveraging on fork of [LayerZero's OFT standard](https://docs.layerzero.network/v2/home/protocol/contract-standards#oft) for allow PRL to be omnichain. ## Key features The architecture allows: * Omnichain migration from MIMO to PRL * Omnichain PRL ## High level Design

High Level Architecture

## Contracts ### PRL Token The [`PRL`](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/PRL.sol) contract is an immutable contract that inherit of Openzeppelin [ERC20](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20) and [ERC20Permit](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Permit) standards. ### PrincipalMigrationContract The [PrincipalMigrationContract](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/PrincipalMigrationContract.sol) is the main migration contract that will be deployed on the same chain as the PRL token. It will own the total supply of PRL at deployment and will allow users to migrate their Mimo to PRL on the same chain or by receiving omnichain messages from other chains. This contract inherits from LayerZero's OAppReceiver. :::warning Known Issue: * Incorrect Refund Address in Multihop Migration Causes Permanent Fund Loss. When a multihop migration (Initial Chain → Mid Chain → Final Chain) fails in the Mid Chain due to insufficient fees, the contract incorrectly sends refunds to the user's Final Chain(dest chain) address on the Mid Chain(intermediate chain) instead of the proper refund address. This outcome assumes that the destination address does not exist on Ethereum, which is highly unlikely. ::: ### LockBox The [LockBox](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/LockBox.sol) will be deployed on the same chain as the PRL token and will allow user to bridge to/from different chain their PRL. This contract inherit of LayerZero's OFTAdapter that allow tokens' bridged on other chains to be lock into this contract. ### PeripheralMigrationContract The [PeripheralMigrationContract](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/peripheral/PeripheralMigrationContract.sol) is the contract deployed on other chains that allow user to migrate Mimo to PRL from any chain. This contract inherit of LayerZero's OAppSender. ### PeripheralPRL The [PeripheralPRL](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/peripheral/PeripheralPRL.sol) will be deployed on other chains than where the PRL token is and will allow user to bridge to/from different chain their PRL. This contract inherit of LayerZero's OFTAdapter. ## Technical Details ### LayerZero standards The omnichain part is handled by LayerZero that allows cross chain messages. We are using two standard : * [OApp standard](https://docs.layerzero.network/v2/home/protocol/contract-standards#oapp) used by the MigrationContract to send/receive message link Mimo to PRL token migration. * [OFT standard](https://docs.layerzero.network/v2/home/protocol/contract-standards#oft) used to make the PRL token bridgeable between chains. Each Omnichain contract inherits a specific type of the LayerZero standard : * Migration contracts : * [PrincipalMigrationContract](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/PrincipalMigrationContract.sol) is an OAppReceiver as its goal is to receive migration message. * [PeripheralMigrationContract](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/peripheral/PeripheralMigrationContract.sol) is an OAppSender as its goal is to send migration message to the main chain. * Omnichain PRL: * [LockBox](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/principal/LockBox.sol) is an OFTAdapter that allow to lock PRL token that has been bridged to other chains and to send/receive messages. * [PeripheraPRL](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/peripheral/PeripheralPRL.sol) is an OFT that will mint/burn PRL on its chain and to send/receive messages. :::info By default LayerZero's OFT standard implement shareDecimals/decimalConversionRate to allow amount to be accepted on chains like Solana which are not uint256 but uint64. We fork the standard and removed all code related to shareDecimals/decimalConversionRate. Forked code is under [layerZero fork](https://github.com/parallel-protocol/parallel-prl/blob/main/contracts/layerZero) folder. ::: ### Migrate from MIMO to PRL Thanks to the architecture, users will be able to migrate from Mimo to PRL without friction on the chain to send/receive. Below you will find the possible scenarios: * Migrate on Main
In this case we just transfer Mimo to the contract from the user and send him PRL. * Migrate from Main to chain A
In this case we swap Mimo to PRL on the main chain and send the PRL to the LockBox (OFT) that will lock the PRL and send a message to the PeripheralPRL contract on the destination chain. * Migrate from chain A to Main
In this case we are using the PrincipalMigrationContract to transfer user's Mimo to itself and send a migration message to the main chain. Then the PrincipalMigrationContract will receive the message and send PRL to the user. * Migrate from chain A to chain X
In this case we are using the full architecture to send message from A to X link in the previous case. Then the PrincipalMigrationContract will create a new message that will be send to the LockBox. The LockBox will transfer PRL from the PrincipalMigrationContract to itself and send the message to the final chain that will mint PRL to the user. ### Pause A `pause` function exists to prevent new `send()` and `migrateToPRL()` calls from being executed. This is useful in the event of a bug or security vulnerability. Only the **Owner** can call pause ### Unpause An `unpause` function exists to unpause the contract. Only the **Owner** can call unpause. ### EmergencyRescue A `emergencyRescue()` function exists on migration contract to withdraw any tokens owned by the contract. Only the **Owner** can call emergencyRescue and the contract must be in pause. ## Deployment Check the [DeployedAddresses.md](https://github.com/parallel-protocol/parallel-prl/blob/main/docs/DeployedAddresses.md) file for the deployed addresses on different networks. ## Documentation for Audits For more details on the contract, refer to the [Audit details](https://github.com/parallel-protocol/parallel-prl/blob/main/docs/AuditDetails.md). # Tokenomics ## Overview The Parallel Tokenomics is a set of contracts that allows : * to send the fees to the main fee distributor on the destination chain (SideChainFeeDistributor) * to distribute fees generated by the protocol to the listed fee receivers (MainFeeDistributor) * users to stake their PRL tokens to earn rewards either in single staking (sPRL1) or in a 80PRL/20WETH balancer pool (BPT) that is deposited into aura.finance (sPRL2). * distribute rewards to sPRL1/sPRL2 users using off-chain calculation and merkle proofs (RewardMerkleDistributor)

high level architecture

## Security Point * OpenZeppelin AccessManged dependency is used to manage the access to the contracts. * Emergency pause mechanisms are implemented in the contracts using the `pause()` and `unpause()` functions from the OpenZeppelin library. * OpenZeppelin ReentrancyGuard is used to prevent reentrancy attacks. * Slippage protection on deposit/withdraw that will go through Balancer during sPRL2 flow. ## Deployment Check the [DeployedAddresses.md](https://github.com/parallel-protocol/parallel-tokenomics/blob/main/docs/Deployment.md) file for the deployed addresses on different networks. ## Documentation for Audits For more details on the contract, refer to the Audit [details](https://github.com/parallel-protocol/parallel-tokenomics/tree/main/docs/audits). # Key Operations Flows ## 1. Key Operation Flows ### 1.1 Staking Flow This section contains the flows related to the staking part of the protocol. #### **1.1.1 sPRL1 Flow** **1.1.1.1 sPRL1 Deposit** * Transfer PRL tokens to the sPRL1 contract * Mint sPRL1 tokens to the user equivalent to the amount of PRL tokens transferred **1.1.1.2 sPRL1 Request Withdraw** * Burn the amount of sPRL1 tokens that the user wants to withdraw * Set the unlocking time for this request **1.1.1.3 sPRL1 Withdraw** * Calculate the penalty based on the time left before the unlocking time. * Send the PRL tokens to the user * mint sPRL1 tokens to the fee receiver equal to the amount slashed from the penalty. **1.1.1.4 sPRL1 EmergencyWithdraw** * Burn the amount of sPRL1 tokens that the user wants to withdraw * Send the PRL tokens to the user without penalties. #### **1.1.2 sPRL2 Flow** This section contains the flows related to the sPRL2 contract. **1.1.2.1 sPRL2 Deposit PRL/WETH or PRL/ETH** * Transfer PRL/WETH or PRL/ETH to the sPRL2 contract * Deposit ETH to WETH if needed * Add PRL/WETH liquidity into the Balancer pool (80PRL/20WETH) * Receive BPT tokens * Stake BPT tokens in Aura * mint sPRL2 tokens to the user equivalent to the amount of Aura BPT lp tokens received **1.1.2.2 sPRL2 Deposit BPT 80PRL/20WETH** * Transfer BPT to the sPRL2 contract * Deposit BPT into Aura pool and stake it * Mint sPRL2 tokens to the user equivalent to the amount of BPT transferred **1.1.2.3 sPRL2 Request Withdraw** * Burn the amount of sPRL2 tokens that the user wants to withdraw * Set the unlocking time for this request **1.1.2.4 sPRL2 Withdraw PRL/ETH or PRL/WETH** * Calculate the penalty based on the time left before the unlocking time. * Withdraw and unwrap the amount of Aura BPT * Receive Balancer BPT tokens from Aura * Withdraw the amount of PRL/WETH from the Balancer pool * Send the PRL/WETH to the user or PRL/ETH to the user * Send the BPT lp penalty to the fee receiver **1.1.2.5 sPRL2 Withdraw BPT 80PRL/20WETH** * Calculate the penalty based on the time left before the unlocking time. * Withdraw the amount of Aura BPT from Aura * Receive Balancer BPT tokens from Aura * Send the BPT lp tokens to the user * Send the BPT lp penalty to the fee receiver **1.1.2.6 sPRL2 EmergencyWithdraw** * Burn the amount of sPRL2 tokens that the user wants to withdraw * Withdraw the amount of Aura BPT from Aura * Receive Balancer BPT tokens from Aura * Send the BPT tokens to the user without penalties. ### **1**.2 Reward Distribution Flow * RewardMerkleDistributor will receive the fees from the MainFeeDistributor at any time. * Using off-chain events and calculations, the protocol retrieve the total amount received during a specific period. * Protocol will generate a merkle root based on the total amount received and the amount of rewards that will be distributed to the users. * The merkle root will be updated in the RewardMerkleDistributor contract. * Users will be able to claim their rewards using the merkle proof. # Contracts ## 1. Contracts ### 1.1 Fees This section contains the contracts related to the fees distribution and collection. #### 1**.1.1** [**FeeCollectorCore**](https://github.com/parallel-protocol/parallel-tokenomics/blob/main/contracts/fees/FeeCollectorCore.sol) This abstract contract is used to handle the common logic between the MainFeeDistributor and the SideChainFeeDistributor contracts. All the functions are restricted to the AccessManager. **function details**: * `emergencyRescue(address _token, address _to, uint256 _amount)` | **Restricted** : Allow to rescue tokens from the contract. * `pause()` | **Restricted** : Allow to pause the contract. * `unpause()` | **Restricted** : Allow to unpause the contract. #### 1**.1.2** [**MainFeeDistributor**](https://github.com/parallel-protocol/parallel-tokenomics/blob/main/contracts/fees/MainFeeDistributor.sol) This contract is deployed on the chain that distributes the fees to users and fees receivers. Inherits from FeeCollectorCore. It will receive the fee token bridge from the SideChainFeeDistributor and distribute it to the fee receivers. As Parallel Tunnel can transfer lz-XXX instead of the fee token if credit limits are reached, this contract can call the bridgeableToken contract to swap the lz-XXX to the fee token. **function details**: * `release()` | **Permissionless** : Allow to release the fees to the fee receivers. * `swapLzToken()` | **Permissionless** : Will swap as much lz-XXX as possible to the fee token by calling the bridgeableToken contract. * `updateBridgeableToken(address _newBridgeableToken)`| **Restricted** : Allow to update the bridgeable token contract (parallel tunnel). * `updateFeeReceivers(address[] memory _feeReceivers, uint256[] memory _shares)` | **Restricted** : Allow to update the list of the fee receivers and their shares. #### 1**.1.3** [**SideChainFeeDistributor**](https://github.com/parallel-protocol/parallel-tokenomics/blob/main/contracts/fees/SideChainFeeDistributor.sol) This contract is deployed on side chains and is used to distribute the fees to the MainFeeDistributor by bridging them using Parallel Tunnel. Inherits from FeeCollectorCore. **function details**: * `release()` | **Restricted** : Will create a LayerZero message and transfer the balance of fee token owned by the contract to the BridgeableToken contract. * `updateBridgeableToken(address _newBridgeableToken)`| **Restricted** : Allow to update the bridgeable token contract (parallel tunnel). * `updateDestinationReceiver(address _newDestinationReceiver)` | **Restricted** : Allow to update the destination receiver address. ### 1.2 Staking This section contains the contracts related to the staking part of the protocol. #### 1**.2.1** [**TimeLockPenaltyERC20**](https://github.com/parallel-protocol/parallel-tokenomics/blob/main/contracts/sPRL/TimeLockPenaltyERC20.sol) This abstract contract is used to handle commun logic between sPRL1 and sPRL2. The main feature of it, it's to apply a lock time duration for withdrawals. Users is also able to withdraw their tokens before the lock time but will be penalized by a penalty fee on the withdraw amount that is calculated based on the time left before the lock time. **Parameters**: * Lock Duration: Configurable * Penalty Start Percentage: Configurable * Penalty Decay: Linear **function details**: * `requestWithdraw(uint256 _unlockingAmount)` | **Permissionless** : Request a withdrawal of the deposited underlying ERC20. * `cancelWithdrawalRequests(uint256[] calldata _ids)` | **Permissionless** : Allow to cancel single and multiple withdrawal requests. * `updateTimeLockDuration(uint64 _newTimeLockDuration)` | **Restricted** : Allow to update the time lock duration. * `updateStartPenaltyPercentage(uint256 _newStartPenaltyPercentage)` | **Restricted** : Allow to update the start penalty percentage. * `updateFeeReceiver(address _newFeeReceiver)` | **Restricted** : Allow to update the fee receiver. * `pause()` | **Restricted** : Allow to pause the contract. * `unpause()` | **Restricted** : Allow to unpause the contract. #### 1**.2.2** [**sPRL1**](https://github.com/parallel-protocol/parallel-tokenomics/blob/main/contracts/sPRL/sPRL1.sol) This contract allow users to stake their PRL tokens to receive sPRL1 tokens and be able to get rewards from the RewardMerkleDistributor. Inherits from TimeLockPenaltyERC20 without addidtional features. **function details**: * `deposit(uint256 _amount)` | **Permissionless** : Allow to deposit PRLs and mint the equivalent amount of sPRL1. * `depositWithPermit(uint256 _amount, uint256 _deadline, uint8 _v, bytes32 _r, bytes32 _s)` | **Permissionless** : Allow to deposit PRLs using ERC20Permit and mint the equivalent amount of sPRL1. * `withdraw(uint256[] calldata _ids)` | **Permissionless** : Allow to withdraw single and multiple withdrawal requests. If the user withdraw before the lock time, the penalty will be applied. * `emergencyWithdraw(uint256 _unlockingAmount)` | **Permissionless** : Allow to emergency withdraw assets without penalties. Only callable when the contract is paused. #### 1**.2.3** [**sPRL2**](https://github.com/parallel-protocol/parallel-tokenomics/blob/main/contracts/sPRL/sPRL2.sol) This contract allow users to stake either their Balancer BPT or their PRL/ETH. BPT will be staked into Aura.finance and user will receive sPRL2 tokens equal to their BPT amount. This contract is also able to directly deposit PRL and ETH (or WETH) into the Balancer pool and to deposit the BPT into the Aura.finance pool. On the withdraw side, users can withdraw their the BPT or the amount of PRL/ETH or PRL/WETH linked to the BPT. **function details**: * `depositBpt(uint256 _amount)` | **Permissionless** : Allow to deposit BPT and mint the equivalent amount of sPRL2 to the user. * `depositPRLAndWeth(uint256 _maxPrlAmount, uint256 _maxWethAmount, uint256 _exactBptAmount, uint256 _deadline, uint8 _v, bytes32 _r, bytes32 _s)` | **Permissionless** : Allow to deposit PRL and WETH and mint the equivalent amount of sPRL2 to the user. * `depositPRLAndEth(uint256 _maxPrlAmount, uint256 _exactBptAmount, uint256 _deadline, uint8 _v, bytes32 _r, bytes32 _s)` | **Permissionless** : Allow to deposit PRL and ETH and mint the equivalent amount of sPRL2 to the user. * `withdrawPRLAndWeth(uint256[] calldata _requestIds, uint256 _minPrlAmount, uint256 _minWethAmount)` | **Permissionless** : Allow to withdraw single and multiple requests of PRL and WETH from the Balancer pool attached to the sPRL2 token. * `withdrawBpt(uint256[] calldata _requestIds, uint256 _minBptAmount)` | **Permissionless** : Allow to withdraw single and multiple requests of BPT from the Aura.finance pool attached to the sPRL2 token. * `claimRewards()` | **Permissionless** : Allow to claim the rewards generated by the BPT staked into Aura.finance and to send them to the fee receiver. * `emergencyWithdraw(uint256 _unlockingAmount)` | **Permissionless** : Allow to emergency withdraw assets without penalties. Only callable when the contract is paused. ### 1.3 Rewards This section contains the contracts related to the rewards distribution of the protocol. #### 1**.3.1** [**RewardMerkleDistributor**](https://github.com/parallel-protocol/parallel-tokenomics/blob/main/contracts/rewardMerkleDistributor/RewardMerkleDistributor.sol) This contract will receive fees from the MainFeeDistributor and distribute them to users using merkle proofs managed by the protocol. **Functions Details** * `claim(ClaimCallData[] calldata _claimsData)` | **Permissionless** : Allow user to claim the rewards using a merkle proof. * `forwardExpiredRewards(uint64[] calldata _epochIds)` | **Permissionless** : Allow to forward the expired rewards to the expiredRewardsRecipient. * `updateMerkleDrop(uint64 _epoch, MerkleDrop memory _merkleDrop)` | **Restricted** : Allow to update the merkle drop for a specific epoch. * `updateExpiredRewardsRecipient(address _newExpiredRewardsRecipient)` | **Restricted** : Allow to update the destination receiver of the expired rewards. * `emergencyRescue(address _token, address _to, uint256 _amount)` | **Restricted** : Allow to rescue tokens from the contract. * `pause()` | **Restricted** : Allow to pause the contract. * `unpause()` | **Restricted** : Allow to unpause the contract. # Parallel V3 ## AccessManager Roles | Role Name | Role ID | | ---------------------------- | ------- | | ADMIN\_ROLE | 0 | | GOVERNOR\_ROLE | 10 | | GOVERNOR\_ROLE\_TIMELOCK | 11 | | GUARDIAN\_ROLE | 20 | | GUARDIAN\_ROLE\_TIMELOCK | 21 | | KEEPER\_ROLE | 30 | | KEEPER\_ROLE\_TIMELOCK | 31 | | EURp\_MINTER\_ROLE | 100 | | EURp\_MINTER\_ROLE\_TIMELOCK | 105 | | USDp\_MINTER\_ROLE | 110 | | USDp\_MINTER\_ROLE\_TIMELOCK | 115 | | ETHp\_MINTER\_ROLE | 120 | | ETHp\_MINTER\_ROLE\_TIMELOCK | 125 | | BTCp\_MINTER\_ROLE | 130 | | BTCp\_MINTER\_ROLE\_TIMELOCK | 135 | # Parallelizer Module :::warning Known Issue: * parallelizer/facets/Swapper.sol: Incorrect handling of deadline causes reverts and breaks documented swap behavior. The Parallelizer Module is a licensed fork of the Angle Protocol's Transmuter contract, and the comment originates from the original Angle codebase. However, during our audit with Bailsec, a vulnerability related to a 0 deadline was identified, and they recommended blocking it to protect users. The change has been implemented the original comment has not been removed. ::: # Savings Module # Flashloan Module # Bridging Module # Onchain Tools # Oracles # DIA Following the approval of [PGP-34 l Launch Parallel Stablecoins Price Feeds using DIA](https://gov.parallel.best/t/pgp-34-l-launch-parallel-stablecoins-price-feeds-using-dia/488), DIA has deployed fundamental & markets price feeds across several chains. All deployed price feeds are ChainlinkAggregatorV3Interface compatible adapter contracts. :::info More details on DIA oracles are available [here](/developers-hub/parallel-v3/onchain-tools/oracles/dia/fundamental) & [here](/developers-hub/parallel-v3/onchain-tools/oracles/dia/market). ::: | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------- | -------- | | USDp/USD | [0x2eEF8970d6dC0fa4f6F86385407439b45DF59e99](https://snowscan.xyz/address/0x2eEF8970d6dC0fa4f6F86385407439b45DF59e99#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0x45FFE3F65C58983dfC8Fb10Ce046fDa6E1EC231a](https://snowscan.xyz/address/0x45FFE3F65C58983dfC8Fb10Ce046fDa6E1EC231a#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | USDp/USD | [0xd826C5F7be24b33Cc825A9b9E9AcD8C5a2bD71F7](https://snowscan.xyz/address/0xd826C5F7be24b33Cc825A9b9E9AcD8C5a2bD71F7#code) | Market | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0x4D165058332a39F2E2C32F438f4897BcF7694Fbd](https://snowscan.xyz/address/0x4D165058332a39F2E2C32F438f4897BcF7694Fbd#code) | Market | 0.5% & 120 Seconds | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | ----------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------- | -------- | | USDp/USD | [0x5975994e5009e2b7fC348dD94a36E7C86958D795](https://hyperevmscan.io/address/0x5975994e5009e2b7fC348dD94a36E7C86958D795#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0xEf06cffeCD2c76762279Fc1b8C37E67bB6d2c18c](https://hyperevmscan.io/address/0xEf06cffeCD2c76762279Fc1b8C37E67bB6d2c18c#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | USDp/USD | [0x2189f3d9Be89808Dfe6C34446FE7aaDA7A5aD1b6](https://hyperevmscan.io/address/0x2189f3d9Be89808Dfe6C34446FE7aaDA7A5aD1b6#code) | Market | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0xdcA437D1492Db6E9438A82Ad31Cab92E2eE159E1](https://hyperevmscan.io/address/0xdcA437D1492Db6E9438A82Ad31Cab92E2eE159E1#code) | Market | 0.5% & 120 Seconds | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------- | -------- | | USDp/USD | [0xE2b51a6c951B81499Ca4602d548ff2f701bfdc24](https://basescan.org/address/0xE2b51a6c951B81499Ca4602d548ff2f701bfdc24#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0xB45f03799F26168699c1909f58bE380eAC735B4b](https://basescan.org/address/0xB45f03799F26168699c1909f58bE380eAC735B4b#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | USDp/USD | [0x048710167827e4bd7286384653baa0be7d22e638](https://basescan.org/address/0x048710167827e4bd7286384653baa0be7d22e638#code) | Market | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0xA6c34e47088331C0348bFe58fe97314A4567071A](https://basescan.org/address/0xA6c34e47088331C0348bFe58fe97314A4567071A#code) | Market | 0.5% & 120 Seconds | 12 hours | :::warning USDp & sUSDp price feeds on Sonic are deprecated. ::: | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------- | -------- | | USDp/USD | [0xF43dd82a870a176e2Cd392c2d9d51e31D0d694b1](https://sonicscan.org/address/0xF43dd82a870a176e2Cd392c2d9d51e31D0d694b1#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0x026ffC812e12a30658727467246757944F76eB48](https://sonicscan.org/address/0x026ffC812e12a30658727467246757944F76eB48#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | USDp/USD | [0xf20f32c481ae55531ec3d923c03306d2d6dc294e](https://sonicscan.org/address/0xf20f32c481ae55531ec3d923c03306d2d6dc294e#code) | Market | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0x06d6c926EF90260B71Bb3d9431958b8DA0C365F5](https://sonicscan.org/address/0x06d6c926EF90260B71Bb3d9431958b8DA0C365F5#code) | Market | 0.5% & 120 Seconds | 12 hours | # Fundamental ## Oracles Implementation ### Contracts The contracts fetch datas from: | Blockchain | Contract Address | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Base | [0x05552ab897fd8ae2a0acdfa9275cc189f3832a6f](https://basescan.org/address/0x05552ab897fd8ae2a0acdfa9275cc189f3832a6f#code) | | Sonic (Deprecated) | [0x70a58a01c6211ae6b5a1c53b6753f412480bfb44](https://sonicscan.org/address/0x70a58a01c6211ae6b5a1c53b6753f412480bfb44#code) | | HyperEVM | [0x77Fbc522AD920f81799b0c3a71d207d4565c5DA8](https://hyperevmscan.io/address/0x77Fbc522AD920f81799b0c3a71d207d4565c5DA8#code) | | Avalanche | [0x94E88fb255FBD0EcEf829098687f5B27f02a12ba](https://snowscan.xyz/address/0x94E88fb255FBD0EcEf829098687f5B27f02a12ba#code) | ### Gas Wallets Gas wallets are used to push data to oracle contracts. To ensure uninterrupted oracle operation, Cooper Labs is maintaining sufficient gas in them. Anyone can monitor the wallets below to ensure they remain adequately funded at all times. | Blockchain | Contract Address | | ------------------ | ------------------------------------------------------------------------------------------------------------------------ | | Base | [0x8cdc088a6b19f58f7613cb65af03c7496adad893](https://basescan.org/address/0x8cdc088a6b19f58f7613cb65af03c7496adad893) | | Sonic (Deprecated) | [0xd35087bb5fa7c4d1a87050cabf73ee4f1649f666](https://sonicscan.org/address/0xd35087bb5fa7c4d1a87050cabf73ee4f1649f666) | | HyperEVM | [0x14566aeb825a3f0605eecd65144dacc52d675b36](https://hyperevmscan.io/address/0x14566aeb825a3f0605eecd65144dacc52d675b36) | | Avalanche | [0xe9847Afb5564B221A079f66F3EF9cBa6D4954a4b](https://snowscan.xyz/address/0xe9847Afb5564B221A079f66F3EF9cBa6D4954a4b) | ### Oracles Configuration Settings that dictate how the oracle computes and updates data. | | | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Pricing Methodology | Volume Weighted Average Price with Interquartile Range Filter (more details [here](https://www.diadata.org/docs/nexus/reference/pricing-methodologies/vwapir-volume-weighted-average-price-with-interquartile-range-filter)) | | Deviation (%) & Refresh Frequency | 0.5% & 120 Seconds | | Heartbeat | 12 Hours | ### Assets Data Available assets on the oracles and the ChainlinkAggregatorV3Interface compatible contracts for each asset feed. | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------- | -------- | | USDp/USD | [0x2eEF8970d6dC0fa4f6F86385407439b45DF59e99](https://snowscan.xyz/address/0x2eEF8970d6dC0fa4f6F86385407439b45DF59e99#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0x45FFE3F65C58983dfC8Fb10Ce046fDa6E1EC231a](https://snowscan.xyz/address/0x45FFE3F65C58983dfC8Fb10Ce046fDa6E1EC231a#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | ----------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------- | -------- | | USDp/USD | [0x5975994e5009e2b7fC348dD94a36E7C86958D795](https://hyperevmscan.io/address/0x5975994e5009e2b7fC348dD94a36E7C86958D795#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0xEf06cffeCD2c76762279Fc1b8C37E67bB6d2c18c](https://hyperevmscan.io/address/0xEf06cffeCD2c76762279Fc1b8C37E67bB6d2c18c#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------- | -------- | | USDp/USD | [0xE2b51a6c951B81499Ca4602d548ff2f701bfdc24](https://basescan.org/address/0xE2b51a6c951B81499Ca4602d548ff2f701bfdc24#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0xB45f03799F26168699c1909f58bE380eAC735B4b](https://basescan.org/address/0xB45f03799F26168699c1909f58bE380eAC735B4b#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | :::warning USDp & sUSDp price feeds on Sonic are deprecated. ::: | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------- | -------- | | USDp/USD | [0xF43dd82a870a176e2Cd392c2d9d51e31D0d694b1](https://sonicscan.org/address/0xF43dd82a870a176e2Cd392c2d9d51e31D0d694b1#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0x026ffC812e12a30658727467246757944F76eB48](https://sonicscan.org/address/0x026ffC812e12a30658727467246757944F76eB48#code) | Fundamental | 0.5% & 120 Seconds | 12 hours | :::info The pricing methodology fetches the fair redemption price of the USDp. In order to maximize security, this pricing methodology is deliberately pessimistic to ensure that no manipulation is possible. This means that the price of the USDp reported by the oracle may be slightly below its actual price. ::: ### Data Sources | Data Source | Contract Address | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | | USDp/USD | [0x41d58951cbd12d4ef49b0437897677bbf5547c80](https://snowscan.xyz/address/0x41d58951cbd12d4ef49b0437897677bbf5547c80#code) | | sUSDp/USD | [0x9d92c21205383651610f90722131655a5b8ed3e0](https://snowscan.xyz/address/0x9d92c21205383651610f90722131655a5b8ed3e0#code) | | Price Feed | Contract Address | | ------------ | ----------------------------------------------------------------------------------------------------------------------------- | | USDp/USD | [0x1250304f66404cd153fa39388ddcdaec7e0f1707](https://hyperevmscan.io/address/0x1250304f66404cd153fa39388ddcdaec7e0f1707#code) | | sUSDp/USD | [0x9b3a8f7cec208e247d97dee13313690977e24459](https://hyperevmscan.io/address/0x9b3a8f7cec208e247d97dee13313690977e24459#code) | | Price Feed | Contract Address | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | | USDp/USD | [0xc3bef21ea7deb5c34cf33e918c8e28972c8048ed](https://basescan.org/address/0xc3bef21ea7deb5c34cf33e918c8e28972c8048ed#code) | | sUSDp/USD | [0x472ed57b376fe400259fb28e5c46eb53f0e3e7e7](https://basescan.org/address/0x472ed57b376fe400259fb28e5c46eb53f0e3e7e7#code) | | Price Feed | Contract Address | | ------------- | --------------------------------------------------------------------------------------------------------------------------- | | USDp/USD | [0xbefbae2330186f031b469e26283acc66bb5f8826](https://sonicscan.org/address/0xbefbae2330186f031b469e26283acc66bb5f8826#code) | | sUSDp/USD | [0xe8a3da6f5ed1cf04c58ac7f6a7383641e877517b](https://sonicscan.org/address/0xe8a3da6f5ed1cf04c58ac7f6a7383641e877517b#code) | ## How the Oracle Works The fair value oracle aggregates the fair USDp price from where the Parallelizer & Savings Modules are deployed and derives a chain-specific USDp/USD & sUSDp/USD value from it. The detailed data flow looks like this: 1. Each of the chains from which the aggregated USDp feed is comprised is queried for its current fair redemption value based on its backing assets and on the amount of USDp minted on that chain. 2. After collecting the chain-specific USDp redemption values and volumes, the average USDp redemption value (or price) is calculated by weighting the individual data points by the respective on-chain volume. 3. This aggregated USDp/USD value is then written into each deployed oracle and can be retrieved by calling the `getValue()` function with USDp/USD as parameter. 4. The aggregated USDp/USD value can also be retrieved using the chainlink-compatible adapter smart contract for USDp/USD. 5. The chain-local sUSDp/USD price (i.e. the redemption value of sUSDp on the chain where the query happens, based on the aggregated USDp price) can be queried by calling the `getSusdpPrice()` function. :::info The sUSDp/USD value can also be retrieved using the chainlink-compatible adapter [smart contract](#assets-data) for sUSDp/USD. ::: ## How to Access Data ### DIAParallelOracle (Solidity) The following is the list of available methods on the `DIAParallelOracle` contract. #### getValue() ``` function getValue(string memory key) public view returns (uint128 price, uint128 timestamp) ``` * For USDp/USD: Returns the global USDp price (aggregated fair value from all chains) in USD. * For sUSDp/USD: Returns the chain-specific sUSDp price in USD using the specific chain's vault exchange rate based on the global USDp price (equivalent to calling `getSusdpPrice()`). Parameters: * `key (string)`: the exchange pair identifier (\`USDp/USD\` or \`sUSDp/USD\`) Return Values: * `price (uint128)`: The asset price in 18 decimals. * `timestamp (uint128)`: Unix timestamp of the latest price update. #### getSusdpPrice() ``` function getSusdpPrice() public view returns (uint256) ``` Calculates the chain-specific sUSDp price using the global USDp price across all chains and the specific chain's vault exchange rate. This is automatically called when using `getValue("sUSDp/USD")`. `Return Value (uint256)`: The chain-specific sUSDp price in 18 decimals. ### Adapter Contracts To consume price data from oracles, you can use the adapter [smart contracts.](/developers-hub/parallel-v3/onchain-tools/oracles/dia) This allows to access the same methods on the AggregatorV3Interface such as `getRoundData` & `latestRoundData`. # Market ## Oracles Implementation ### Gas Wallets Gas wallets are used to push data to oracle contracts. To ensure uninterrupted oracle operation, Cooper Labs is maintaining sufficient gas in them. Anyone can monitor the wallets below to ensure they remain adequately funded at all times. | Blockchain | Contract Address | | ------------------ | ------------------------------------------------------------------------------------------------------------------------ | | Base | [0x8cdc088a6b19f58f7613cb65af03c7496adad893](https://basescan.org/address/0x8cdc088a6b19f58f7613cb65af03c7496adad893) | | Sonic (Deprecated) | [0xd35087bb5fa7c4d1a87050cabf73ee4f1649f666](https://sonicscan.org/address/0xd35087bb5fa7c4d1a87050cabf73ee4f1649f666) | | HyperEVM | [0x14566aeb825a3f0605eecd65144dacc52d675b36](https://hyperevmscan.io/address/0x14566aeb825a3f0605eecd65144dacc52d675b36) | | Avalanche | [0xe9847Afb5564B221A079f66F3EF9cBa6D4954a4b](https://snowscan.xyz/address/0xe9847Afb5564B221A079f66F3EF9cBa6D4954a4b) | ### Oracles Configuration Settings that dictate how the oracle computes and updates data. | | | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Pricing Methodology | Volume Weighted Average Price with Interquartile Range Filter (more details [here](https://www.diadata.org/docs/nexus/reference/pricing-methodologies/vwapir-volume-weighted-average-price-with-interquartile-range-filter)) | | Deviation (%) & Refresh Frequency | 0.5% & 120 Seconds | | Heartbeat | 12 Hours | ### Assets Data Available assets on the oracles and the Chainlink AggregatorV3Interface compatible contracts for each asset feed. | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | ------ | --------------------------------- | -------- | | USDp/USD | [0xd826C5F7be24b33Cc825A9b9E9AcD8C5a2bD71F7](https://snowscan.xyz/address/0xd826C5F7be24b33Cc825A9b9E9AcD8C5a2bD71F7#code) | Market | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0x4D165058332a39F2E2C32F438f4897BcF7694Fbd](https://snowscan.xyz/address/0x4D165058332a39F2E2C32F438f4897BcF7694Fbd#code) | Market | 0.5% & 120 Seconds | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | ----------------------------------------------------------------------------------------------------------------------------- | ------ | --------------------------------- | -------- | | USDp/USD | [0x2189f3d9Be89808Dfe6C34446FE7aaDA7A5aD1b6](https://hyperevmscan.io/address/0x2189f3d9Be89808Dfe6C34446FE7aaDA7A5aD1b6#code) | Market | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0xdcA437D1492Db6E9438A82Ad31Cab92E2eE159E1](https://hyperevmscan.io/address/0xdcA437D1492Db6E9438A82Ad31Cab92E2eE159E1#code) | Market | 0.5% & 120 Seconds | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | ------ | --------------------------------- | -------- | | USDp/USD | [0x048710167827e4bd7286384653baa0be7d22e638](https://basescan.org/address/0x048710167827e4bd7286384653baa0be7d22e638#code) | Market | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0xA6c34e47088331C0348bFe58fe97314A4567071A](https://basescan.org/address/0xA6c34e47088331C0348bFe58fe97314A4567071A#code) | Market | 0.5% & 120 Seconds | 12 hours | :::warning USDp & sUSDp price feeds on Sonic are deprecated. ::: | Price Feed | Contract Address | Type | Deviation (%) & Refresh Frequency | Hearbeat | | ------------- | --------------------------------------------------------------------------------------------------------------------------- | ------ | --------------------------------- | -------- | | USDp/USD | [0xf20f32c481ae55531ec3d923c03306d2d6dc294e](https://sonicscan.org/address/0xf20f32c481ae55531ec3d923c03306d2d6dc294e#code) | Market | 0.5% & 120 Seconds | 12 hours | | sUSDp/USD | [0x06d6c926EF90260B71Bb3d9431958b8DA0C365F5](https://sonicscan.org/address/0x06d6c926EF90260B71Bb3d9431958b8DA0C365F5#code) | Market | 0.5% & 120 Seconds | 12 hours | ### Data Sources | Price Feed | API Endpoint | | ------------ | -------------------------------------------------------------------------------------------------------- | | USDp/USD | [USDp on Base](https://www.diadata.org/app/price/asset/Base/0x76A9A0062ec6712b99B4f63bD2b4270185759dd5/) | | sUSDp/USD | | | Price Feed | API Endpoint | | ---------- | ---------------------------------------------------------------------------------------------------------- | | USDp/USD | [USDp on Sonic](https://www.diadata.org/app/price/asset/Sonic/0x08417cdb7F52a5021bB4eb6E0deAf3f295c3f182/) | | sUSDp/USD | | :::warning USDp & sUSDp price feeds on Sonic are deprecated. ::: ## How the Oracle Works The market-based oracle aggregates trades from decentralized exchanges across multiple chains (Base, Sonic, etc.) using the VWAPIR methodology over a 1-hour window. Price updates are triggered when market prices deviate by 0.5% or every 12 hours as configured [here](#oracles-configuration). :::info The sUSDp/USD value can also be retrieved using the chainlink-compatible adapter [smart contract](#assets-data) for sUSDp/USD. ::: # RedStone Following the approval of [PGP-33 l Launch Parallel Stablecoins Price Feeds using Redstone](https://gov.parallel.best/t/pgp-33-l-launch-parallel-stablecoins-price-feeds-using-redstone/487), RedStone has deployed fundamental price feeds across several chains. All deployed price feeds are ChainlinkAggregatorV3Interface compatible adapter contracts. :::info More details on RedStone oracles are available [here](/developers-hub/parallel-v3/onchain-tools/oracles/redstone/fundamental). ::: | Price Feed | Contract Address | Type | Deviation (%) | Hearbeat | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- | -------- | | USDp/USD | [0xFB1267A29C0aa19daae4a483ea895862A69e4AA5](https://snowscan.xyz/address/0xFB1267A29C0aa19daae4a483ea895862A69e4AA5#code) | Fundamental | 0.2% | 12 hours | | sUSDp/USD | [0x5ED849a45B4608952161f45483F4B95BCEa7f8f0](https://snowscan.xyz/address/0x5ED849a45B4608952161f45483F4B95BCEa7f8f0#code) | Fundamental | 0.2% | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) | Hearbeat | | ------------ | ------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- | -------- | | USDp/USD | [0xf0DEbDAE819b354D076b0D162e399BE013A856d3](https://hyperevmscan.io//address/0xf0DEbDAE819b354D076b0D162e399BE013A856d3?#code) | Fundamental | 0.2% | 12 hours | | sUSDp/USD | [0xD15862FC3D5407A03B696548b6902D6464A69b8c](https://hyperevmscan.io//address/0xD15862FC3D5407A03B696548b6902D6464A69b8c?#code) | Fundamental | 0.2% | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) | Hearbeat | | ------------ | --------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- | -------- | | USDp/USD | [0xD15862FC3D5407A03B696548b6902D6464A69b8c](https://basescan.org/address/0xD15862FC3D5407A03B696548b6902D6464A69b8c?#code) | Fundamental | 0.2% | 12 hours | | sUSDp/USD | [0x58fa68A373956285dDfb340EDf755246f8DfCA16](https://basescan.org/address/0x58fa68A373956285dDfb340EDf755246f8DfCA16?#code) | Fundamental | 0.2% | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) | Hearbeat | | ------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- | -------- | | USDp/USD | [0xE23eCA12D7D2ED3829499556F6dCE06642AFd990](https://sonicscan.org//address/0xE23eCA12D7D2ED3829499556F6dCE06642AFd990?#code) | Fundamental | 0.2% | 12 hours | | sUSDp/USD | [0x31a36CdF4465ba61ce78F5CDbA26FDF8ec361803](https://sonicscan.org//address/0x31a36CdF4465ba61ce78F5CDbA26FDF8ec361803?#code) | Fundamental | 0.2% | 12 hours | a # Fundamental ## Oracles Implementation ### Gas Wallets Gas wallets are used to push data to oracle contracts. To ensure uninterrupted oracle operation, Cooper Labs & RedStone are maintaining sufficient gas in them. Anyone can monitor the wallets below to ensure they remain adequately funded at all times. | Blockchain | Contract Address | | ---------- | ------------------------------------------------------------------------------------------------------------------------ | | Base | [0xF5659859aA2E19187A58695eF854643852b8C3Ba](https://basescan.org/address/0xF5659859aA2E19187A58695eF854643852b8C3Ba) | | Sonic | [0xF0547b3E44b904FeE2569ACf5107769dD28a17C3](https://sonicscan.org/address/0xF0547b3E44b904FeE2569ACf5107769dD28a17C3) | | HyperEVM | [0x2327C3cdC64cf32C6b5414e280B147BCa83E3A2C](https://hyperevmscan.io/address/0x2327C3cdC64cf32C6b5414e280B147BCa83E3A2C) | | Avalanche | [0xD0f83B7975505295413CeA06F9ad0482AA9AE08c](https://snowscan.xyz/address/0xD0f83B7975505295413CeA06F9ad0482AA9AE08c) | ### Oracles Configuration Settings that dictate how the oracle computes and updates data. | | | | ------------------- | --------------------- | | Pricing Methodology | Fair Redemption Price | | Deviation (%) | 0.2% | | Heartbeat | 12 Hours | ### Assets Data Available assets on the oracles and the ChainlinkAggregatorV3Interface compatible contracts for each asset feed. | Price Feed | Contract Address | Type | Deviation (%) | Hearbeat | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- | -------- | | USDp/USD | [0xFB1267A29C0aa19daae4a483ea895862A69e4AA5](https://snowscan.xyz/address/0xFB1267A29C0aa19daae4a483ea895862A69e4AA5#code) | Fundamental | 0.2% | 12 hours | | sUSDp/USD | [0x5ED849a45B4608952161f45483F4B95BCEa7f8f0](https://snowscan.xyz/address/0x5ED849a45B4608952161f45483F4B95BCEa7f8f0#code) | Fundamental | 0.2% | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) | Hearbeat | | ------------ | ------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- | -------- | | USDp/USD | [0xf0DEbDAE819b354D076b0D162e399BE013A856d3](https://hyperevmscan.io//address/0xf0DEbDAE819b354D076b0D162e399BE013A856d3?#code) | Fundamental | 0.2% | 12 hours | | sUSDp/USD | [0xD15862FC3D5407A03B696548b6902D6464A69b8c](https://hyperevmscan.io//address/0xD15862FC3D5407A03B696548b6902D6464A69b8c?#code) | Fundamental | 0.2% | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) | Hearbeat | | ------------ | --------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- | -------- | | USDp/USD | [0xD15862FC3D5407A03B696548b6902D6464A69b8c](https://basescan.org/address/0xD15862FC3D5407A03B696548b6902D6464A69b8c?#code) | Fundamental | 0.2% | 12 hours | | sUSDp/USD | [0x58fa68A373956285dDfb340EDf755246f8DfCA16](https://basescan.org/address/0x58fa68A373956285dDfb340EDf755246f8DfCA16?#code) | Fundamental | 0.2% | 12 hours | | Price Feed | Contract Address | Type | Deviation (%) | Hearbeat | | ------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- | -------- | | USDp/USD | [0xE23eCA12D7D2ED3829499556F6dCE06642AFd990](https://sonicscan.org//address/0xE23eCA12D7D2ED3829499556F6dCE06642AFd990?#code) | Fundamental | 0.2% | 12 hours | | sUSDp/USD | [0x31a36CdF4465ba61ce78F5CDbA26FDF8ec361803](https://sonicscan.org//address/0x31a36CdF4465ba61ce78F5CDbA26FDF8ec361803?#code) | Fundamental | 0.2% | 12 hours | :::info The pricing methodology fetches the fair redemption price of the USDp. In order to maximize security, this pricing methodology is deliberately pessimistic to ensure that no manipulation is possible. This means that the price of the USDp reported by the oracle may be slightly below its actual price. ::: ### Data Sources | Data Source | Contract Address | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | | USDp/USD | [0x41d58951cbd12d4ef49b0437897677bbf5547c80](https://snowscan.xyz/address/0x41d58951cbd12d4ef49b0437897677bbf5547c80#code) | | sUSDp/USD | [0x9d92c21205383651610f90722131655a5b8ed3e0](https://snowscan.xyz/address/0x9d92c21205383651610f90722131655a5b8ed3e0#code) | | Price Feed | Contract Address | | ------------ | ----------------------------------------------------------------------------------------------------------------------------- | | USDp/USD | [0x1250304f66404cd153fa39388ddcdaec7e0f1707](https://hyperevmscan.io/address/0x1250304f66404cd153fa39388ddcdaec7e0f1707#code) | | sUSDp/USD | [0x9b3a8f7cec208e247d97dee13313690977e24459](https://hyperevmscan.io/address/0x9b3a8f7cec208e247d97dee13313690977e24459#code) | | Price Feed | Contract Address | | ------------ | -------------------------------------------------------------------------------------------------------------------------- | | USDp/USD | [0xc3bef21ea7deb5c34cf33e918c8e28972c8048ed](https://basescan.org/address/0xc3bef21ea7deb5c34cf33e918c8e28972c8048ed#code) | | sUSDp/USD | [0x472ed57b376fe400259fb28e5c46eb53f0e3e7e7](https://basescan.org/address/0x472ed57b376fe400259fb28e5c46eb53f0e3e7e7#code) | | Price Feed | Contract Address | | ------------- | --------------------------------------------------------------------------------------------------------------------------- | | USDp/USD | [0xbefbae2330186f031b469e26283acc66bb5f8826](https://sonicscan.org/address/0xbefbae2330186f031b469e26283acc66bb5f8826#code) | | sUSDp/USD | [0xe8a3da6f5ed1cf04c58ac7f6a7383641e877517b](https://sonicscan.org/address/0xe8a3da6f5ed1cf04c58ac7f6a7383641e877517b#code) | ## How the Oracle Works The fair value oracle aggregates the fair USDp price from where the Parallelizer & Savings Modules are deployed and derives a chain-specific USDp/USD & sUSDp/USD value from it. The detailed data flow looks like this: 1. Each of the chains from which the aggregated USDp feed is comprised is queried for its current fair redemption value based on its backing assets and on the amount of USDp minted on that chain. 2. After collecting the chain-specific USDp redemption values and volumes, the average USDp redemption value (or price) is calculated by weighting the individual data points by the respective on-chain volume. 3. This aggregated USDp/USD value is then written into each deployed oracle and can be retrieved by calling the chainlink-compatible adapter smart contract for USDp/USD. # Offchain Tools # Subgraphs | Blockchain | Subgraph API | | ---------- | -------------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-mainnet/v2.1/g) | | Base | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-base/v2.1/gn) | | Sonic | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-sonic/v2.1/gn) | | HyperEVM | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmc3fgenfgh7s01ufa19pgvvx/subgraphs/parallel-v3-hyperevm/v1.0/gn) | | Avalanche | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-avalanche/v1.0/gn) | | Polygon | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-polygon/v2.2/gn) | | Arbitrum | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-arbitrum/v1.0/gn) | | Optimism | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-optimism/v1.0/gn) | | Sei | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-sei/v1.0/gn) | | BSC | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-bsc/v1.0/gn) | | Berachain | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-berachain/v1.0/gn) | | Scroll | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-scroll/v1.0/gn) | | Gnosis | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-gnosis/v1.0/gn) | | Unichain | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-unichain/v1.0/gn) | | Ink | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmgzmeqlk00b05np2hd3n5x9d/subgraphs/parallel-v3-ink/v1.0/gn) | | Tac | [GoldSky Subgraph](https://api.goldsky.com/api/public/project_cmc3fgenfgh7s01ufa19pgvvx/subgraphs/parallel-v3-tac/v1.0/gn) | # Dune Coming soon # Build on Parallel The goal of these guides is to help developers, such as third-party protocols, arbitrageurs or keepers; understand and build on-top of Parallel. In these integration guides you'll find details about: * Parallelizer Module [Integration](/developers-hub/parallel-v3/build-on-parallel/parallelizer-module-integration) * Savings Module [Integration](/developers-hub/parallel-v3/build-on-parallel/savings-module-integration) * Flashloan Module [Integration](/developers-hub/parallel-v3/build-on-parallel/flashloan-module-integration) # Parallelizer Module Integration The Parallelizer module serves as the core minting and burning engine for Parallel stablecoins. The contract works as a [Diamond Proxy](https://eips.ethereum.org/EIPS/eip-2535) with multiple implementation facets. This [repo](https://github.com/parallel-protocol/parallel-parallelizer/tree/main/contracts/parallelizer) contains the contract implementation with all its facets. In this guide, we explain how to interact with the Parallelizer Module and fetch basical information from it. For more in depth information on how the Parallelizer and its functions work, you can directly look into the code. :::info The Parallelizer Module can be used for any Parallel stablecoins: find its deployment addresses [here](/developers-hub/contract-addresses/parallel-v3). ::: ## Overview The Parallelizer Module provides a unified interface for minting and burning Parallel stablecoins using various collateral assets. The system operates on oracle-based pricing with configurable fees, offering flexibility for different use cases. ### Key Features * **Unified Swap Interface**: Both minting and burning operations use the same swap-based functions * **Oracle-Based Pricing**: Real-time pricing through integrated oracles * **Flexible Fee Structure**: Dynamic fees that can be adjusted per collateral type * **Multiple Collateral Support**: Work with various supported assets (e.g., USDe for USDp) * **Gas-Efficient Operations**: Optimized for cost-effective transactions ### Operation Types The system distinguishes between mint, burn & redeem operations: * **Mint**: When `tokenIn` is a collateral asset → Allow the mint of stablecoins * **Burn**: When `tokenOut` is a collateral asset → Allow the burn of stablecoins for collateral * **Redeem**: `redeem` → Allow the redemption of stablecoins against a portion of the collateral in the backing ## Mint/Burn ### Getting Price Quotes Before executing any swap operation, you'll want to get accurate price quotes. The Parallelizer Module provides two quote functions that simulate the exact outcome of a swap at the current block. #### Input-Based Quotes (`quoteIn`) Use this when you know exactly how much input you want to provide: ```solidity function quoteIn(uint256 amountIn, address tokenIn, address tokenOut) external view returns (uint256 amountOut); ``` **Parameters:** * `amountIn`: The exact amount of input tokens you plan to swap * `tokenIn`: The token you're providing (collateral for mint, stablecoin for burn) * `tokenOut`: The token you want to receive (stablecoin for mint, collateral for burn) **Returns:** * `amountOut`: The exact amount of output tokens you'll receive #### Output-Based Quotes (`quoteOut`) Use this when you need a specific amount of output tokens: ```solidity function quoteOut(uint256 amountOut, address tokenIn, address tokenOut) external view returns (uint256 amountIn); ``` **Parameters:** * `amountOut`: The exact amount of output tokens you need * `tokenIn`: The token you're providing * `tokenOut`: The token you want to receive **Returns:** * `amountIn`: The exact amount of input tokens required :::warning * Quote functions will revert if insufficient liquidity is available (e.g., during burn operations when funds are deployed in strategies) * All conditions that would cause swap functions to revert will also cause quote functions to revert * Operations may be paused for specific collateral types - quotes will reflect this status ::: ### Executing Swaps Once you have your quotes and slippage parameters ready, you can execute the actual swap. The Parallelizer Module offers four main swap functions to handle different scenarios. #### Exact Input Swaps (`swapExactInput`) Perfect when you know exactly how much you want to spend: ```solidity function swapExactInput( uint256 amountIn, uint256 amountOutMin, address tokenIn, address tokenOut, address to, uint256 deadline ) external returns (uint256 amountOut); ``` **Parameters:** * `amountIn`: Exact amount of input tokens to swap * `amountOutMin`: Minimum acceptable output (slippage protection) * `tokenIn`: Input token address * `tokenOut`: Output token address * `to`: Recipient address for output tokens * `deadline`: Timestamp before which the redemption should have occured (0 = no deadline check) **Returns:** * `amountOut`: Actual amount of tokens received **Prerequisites:** * For mint operations: Approve the contract to spend your input tokens * For burn operations: No approval needed (you're burning your own tokens) #### Exact Output Swaps (`swapExactOutput`) Use this when you need a specific amount of output tokens: ```solidity function swapExactOutput( uint256 amountOut, uint256 amountInMax, address tokenIn, address tokenOut, address to, uint256 deadline ) external returns (uint256 amountIn); ``` **Parameters:** * `amountOut`: Exact amount of output tokens needed * `amountInMax`: Maximum input tokens you're willing to spend * `tokenIn`: Input token address * `tokenOut`: Output token address * `to`: Recipient address for output tokens * `deadline`: Timestamp before which the redemption should have occured (0 = no deadline check) **Returns:** * `amountIn`: Actual amount of input tokens consumed **Prerequisites:** * For mint operations: Approve the contract for at least `amountInMax` * For burn operations: No approval needed ### Executing Gasless Swaps For enhanced user experience, the Parallelizer Module supports gasless minting operations using Uniswap Permit2 signatures. This eliminates the need for separate approval transactions, allowing users to mint stablecoins in a single transaction. #### Key Benefits * **Single Transaction**: Combine approval and swap in one operation * **Better UX**: Users don't need to wait for approval confirmations * **Gas Efficiency**: Reduces overall transaction costs * **Security**: Leverages battle-tested Permit2 infrastructure #### Permit-Based Functions The system provides two permit-enabled functions that mirror the standard swap functions: **Exact Input Swaps with Permit (`swapExactInputWithPermit`)** ```solidity function swapExactInputWithPermit( uint256 amountIn, uint256 amountOutMin, address tokenIn, address to, uint256 deadline, bytes calldata permitData ) external returns (uint256 amountOut); ``` **Parameters:** * `amountIn`: Exact amount of input tokens to swap * `amountOutMin`: Minimum acceptable output (slippage protection) * `tokenIn`: Input token address * `to`: Recipient address for output tokens * `deadline`: Timestamp before which the redemption should have occured (0 = no deadline check) **Returns:** * `amountOut`: Actual amount of tokens received **Prerequisites:** * For mint operations: Approve the contract using Permit2 to spend your `AmountIn` tokens **Exact Output Swaps with Permit (`swapExactOutputWithPermit`)** ```solidity function swapExactOutputWithPermit( uint256 amountOut, uint256 amountInMax, address tokenIn, address to, uint256 deadline, bytes calldata permitData ) external returns (uint256 amountIn); ``` **Parameters:** * `amountOut`: Exact amount of output tokens needed * `amountInMax`: Maximum input tokens you're willing to spend * `tokenIn`: Input token address * `to`: Recipient address for output tokens * `deadline`: Timestamp before which the redemption should have occured (0 = no deadline check) **Returns:** * `amountIn`: Actual amount of input tokens consumed **Prerequisites:** * For mint operations: Approve the contract using Permit2 for at least `amountInMax` :::warning * These functions are **mint-only** operations (no `tokenOut` parameter needed) * The `permitData` contains the Permit2 signature and authorization details * All other parameters follow the same patterns as their non-permit counterparts * Users must have previously allowed the Permit2 contract to spend their tokens ::: ## Redemptions The Parallelizer Module enables redeeming stablecoins against a portion of the collateral in the backing. This feature exists per se and does not need to be activated by governance to be used. ### Quote a Redemption Like the swap functions, redemptions come with a quote function that simulates the exact output that a redemption of stablecoins would give at a given block. ```solidity function quoteRedemptionCurve( uint256 amount ) external view returns (address[] memory tokens, uint256[] memory amounts); ``` **Parameters:** * `amount`: Amount of stablecoins to redeem **Return Values:** * `tokens`: List of tokens that would be given * `amounts`: Amount that would be obtained for each token in the `tokens` array :::info This function does not revert if redemptions have been temporarily paused. ::: In normal conditions, the amount of tokens outputted by this function is the amount of collateral assets supported by the system, following their order in the `collateralList`. Yet, if one collateral has its liquidity managed through strategies, then it's possible that this asset has sub-collaterals with it. In this situation, these sub-collaterals may be sent during the redemption process and the `minAmountOuts` array length will be bigger than the `collateralList` length. If there are 3 collateral assets and the 2nd collateral asset in the list (at index 1) consists of 3 sub-collaterals, then the ordering of the token list will be as follows: `[collat 1, sub-collat 1 of collat 2, sub-collat 2 of collat 2, sub-collat 3 of collat 2, collat 3]` ### Execute a Redemption The main function to process a redemption with the Parallelizer is the `redeem` function. ```solidity function redeem( uint256 amount, address receiver, uint256 deadline, uint256[] memory minAmountOuts ) external returns (address[] memory tokens, uint256[] memory amounts); ``` **Parameters:** * `amount`: Amount of stablecoins to redeem * `receiver`: Address which should be receiving the output tokens * `deadline`: Timestamp before which the redemption should have occured * `minAmountOuts`: Minimum amount of each token given back in the redemption to obtain. The function reverts if the redemption brings less than what was specified for a given token. The order of the amounts given in this list must reflect the order of `tokens` returned by the `quoteRedemptionCurve` function. **Return Values:** * `tokens`: List of tokens returned (exactly the same as `quoteRedemptionCurve`) * `amounts`: Amount given for each token in the `tokens` array To correctly order the elements in the `minAmountOuts` array, it is recommended to call the `quoteRedemptionCurve` function. If the Parallelizer does not have enough tokens at hand (because these are invested in another contract), but redemption computations estimate that tokens must still be sent, then the `redeem` call will revert when the contract is trying to process the token transfer. It is possible to instruct the system to forfeit some tokens in the redemption process by using the `redeemWithForfeit` function. ```solidity function redeemWithForfeit( uint256 amount, address receiver, uint256 deadline, uint256[] memory minAmountOuts, address[] memory forfeitTokens ) external returns (address[] memory tokens, uint256[] memory amounts); ``` If a token is forfeited because its address is in the `forfeitTokens` array, then the Parallelizer will not try to send the tokens to `receiver` even if it has enough at hand to do so. The length and the ordering of the addresses in the `forfeitTokens` array can be set at will: before sending a token, the `redemptionWithForfeit` function just checks whether this token address can be found in the `forfeitTokens` array. :::info No approval is needed before calling redemption functions. ::: :::warning Redemptions can be extraordinarily paused by governance. In which case, all the redemption functions would revert (but not the `quoteRedemptionCurve` function). ::: ## Get the Parallelizer Module facet addresses As a Diamond Proxy, the Parallelizer Module is a proxy contract which delegates calls that are made to it to corresponding facets. The contract has a dummy implementation facet which enables anyone to directly call the Parallelizer functions on block explorers, just like you'd do with a `TransparentUpgradeableProxy` contract. As such when clicking on block explorers to view the implementation contract of the Parallelizer, you'll be directed to this dummy implementation. To get the facet addresses of a Parallelizer implementation, you can simply call the `facetAddresses` function of the contract which gives the list of all supported facets. ## Get the Parallelizer Module supported collateral assets The Parallelizer Module supports different collateral assets to mint a stablecoin. Many functions in the contract take as argument a supported collateral and revert if the address given does not correspond to a collateral. The `getCollateralList` function returns the list of all valid collateral assets. For all the collateral assets supported here, you may then call any of the view functions to get information about how they are setup in the system: * `getCollateralMintFees`, `getCollateralBurnFees`: mint and burn fee parameters for a collateral asset * `isWhitelistedCollateral`, `getCollateralWhitelistData`: whether burns and redemptions are whitelisted for a collateral asset and how the whitelist is setup. To understand why and how whitelists are operated in Parallelizer, check out [this page](/products/parallel-v3/how-it-works/parallelizer-module#collateral-whitelist) * `getIssuedByCollateral`: to get how many stablecoins were issued from a collateral and overall * `getOracle`, `getOracleValues`: how oracles are setup for a specific collateral (which feeds are read) and what values would be used for a mint, a burn or redemption operation * `isPaused`: whether minting with or burning for a collateral asset is paused * `getManagerData`: whether a collateral is invested externally in other strategies ## Collateral Whitelists The Parallelizer Module includes the possibility for governance to whitelist collateral assets, meaning that they can only be sent to addresses during a burn or a redemption to an address which has been whitelisted in some way. If the Parallelizer includes one collateral that requires a whitelist, and someone tries to redeem without forfeiting any tokens to an address which has not been whitelisted, then the redemption will revert. In fact, if there are n collateral assets, with m of them requiring a whitelist, if all the whitelists are different, for a full redemption to occur successfully, the `to` address would need to be whitelisted for all the m collateral assets. Otherwise, to still be able to redeem something out of your stablecoins, you need to forfeit the tokens for which the `to` address is not whitelisted through the `redeemWithForfeit` function. On a similar note, burn operations involving collateral assets requiring a whitelist revert if the `to` address is not whitelisted. The quote functions (`quoteIn`, `quoteOut`, `quoteRedemptionCurve`) do not revert however if there are collateral assets with whitelists involved. # Savings Module Integration The Savings module provides a yield-bearing vault system built on the ERC4626 standard, allowing users to deposit Parallel stablecoins and earn interest through a configurable inflation rate mechanism. These are simple ERC4626 contracts which do not invest the tokens deposited in it, but simply mint new tokens based on a rate defined by governance. This [repo](https://github.com/parallel-protocol/parallel-parallelizer/tree/main/contracts/savings) contains the contract implementation. As such, apart from the savings module contract smart contract risk, there is no extra trust assumption between owning a stablecoin and owning a stablecoin in a staking contract to earn a yield from it. :::info Savings Module contracts addresses for Parallel stablecoins across all chains can be obtained [here](/developers-hub/contract-addresses/parallel-v3). ::: ## Overview Savings module contracts act as interest-bearing vaults where users can deposit their Parallel stablecoins and automatically earn yield over time. The system uses a sophisticated inflation rate mechanism that compounds interest continuously, providing predictable returns for depositors. ### Key Features * **ERC4626 Standard**: Full compatibility with the industry-standard vault interface * **Continuous Compounding**: Interest accrues continuously based on a configurable rate * **Governance-Controlled**: Interest rates are managed by trusted addresses and governance * **Pause Functionality**: Emergency pause mechanism for security * **Upgradeable**: UUPS proxy pattern for future improvements ### How It Works 1. **Deposit**: Users deposit Parallel stablecoins (eg. USDp) and receive vault shares (eg. sUSDp) 2. **Interest Accrual**: The vault continuously mints new tokens based on the inflation rate 3. **Share Value Growth**: As the total assets increase, each share becomes more valuable 4. **Withdrawal**: Users can redeem shares for the underlying assets plus accrued interest ## Core Functions ### Depositing Assets #### **Deposit Exact Amount (`deposit`)** ```solidity function deposit(uint256 assets, address receiver) external returns (uint256 shares); ``` **Parameters:** * `assets`: Exact amount of underlying tokens to deposit * `receiver`: Address that will receive the vault shares **Returns:** * `shares`: Number of vault shares minted to the receiver **Prerequisites:** * Approve the Savings module contract to spend your underlying tokens * Contract must not be paused #### **Mint Exact Shares (`mint`)** ```solidity function mint(uint256 shares, address receiver) external returns (uint256 assets); ``` **Parameters:** * `shares`: Exact number of vault shares to mint * `receiver`: Address that will receive the vault shares **Returns:** * `assets`: Amount of underlying tokens required for the deposit **Use Case:** When you want a specific number of shares rather than a specific asset amount ### Withdrawing Assets #### **Withdraw Exact Amount (`withdraw`)** ```solidity function withdraw( uint256 assets, address receiver, address owner ) external returns (uint256 shares); ``` **Parameters:** * `assets`: Exact amount of underlying tokens to withdraw * `receiver`: Address that will receive the underlying tokens * `owner`: Address that owns the shares being redeemed **Returns:** * `shares`: Number of vault shares burned #### **Redeem Exact Shares (`redeem`)** ```solidity function redeem( uint256 shares, address receiver, address owner ) external returns (uint256 assets); ``` **Parameters:** * `shares`: Exact number of vault shares to redeem * `receiver`: Address that will receive the underlying tokens * `owner`: Address that owns the shares being redeemed **Returns:** * `assets`: Amount of underlying tokens received ## View Functions ### **Get Total Assets (`totalAssets`)** ```solidity function totalAssets() external view returns (uint256); ``` Returns the total amount of underlying assets held by the vault, including accrued interest. ### **Estimate Annual Percentage Yield (`estimatedAPR`)** The contract comes with a wrapper `estimatedAPR` function which gives the estimated APY in base 18 for depositing in this contract. A 1% APY for this function would correspond to a value of 10000000000000000. ```solidity function estimatedAPR() external view returns (uint256 apr); ``` :::info Despite the function name, this returns the **Annual Percentage Yield (APY)** based on the current inflation rate, not the Annual Percentage Rate (APR). The function name is misleading but the return value represents the compounded yield. ::: ### **Compute Updated Assets (`computeUpdatedAssets`)** You can anticipate (assuming the inflation rate does not change) how much you'll earn for a period of time by depositing in the contract by calling the `computeUpdatedAssets` function: ```solidity function computeUpdatedAssets(uint256 _totalAssets, uint256 exp) external view returns (uint256); ``` **Parameters:** * `_totalAssets`: Current total assets amount * `exp`: Time period in seconds **Returns:** * Updated asset amount after the specified time period ### Integration Patterns #### Basic Deposit Flow ```solidity // 1. Get current yield information uint256 currentAPY = savings.estimatedAPR(); // Note: function name is misleading, returns APY // 2. Approve tokens IERC20(underlyingAsset).approve(address(savings), depositAmount); // 3. Deposit assets uint256 shares = savings.deposit(depositAmount, msg.sender); // 4. Track the deposit emit Deposit(msg.sender, depositAmount, shares); ``` #### Withdrawal Flow ```solidity // 1. Check current share value uint256 totalAssets = savings.totalAssets(); uint256 totalShares = savings.totalSupply(); uint256 shareValue = totalAssets * 1e18 / totalShares; // 2. Calculate shares needed for desired amount uint256 sharesNeeded = (desiredAmount * 1e18) / shareValue; // 3. Redeem shares uint256 assetsReceived = savings.redeem(sharesNeeded, msg.sender, msg.sender); // 4. Track the withdrawal emit Withdrawal(msg.sender, assetsReceived, sharesNeeded); ``` #### Monitoring Interest Accrual ```solidity // Track user's position over time struct UserPosition { uint256 shares; uint256 depositTime; uint256 lastCheckpoint; } function getUserYield(address user) external view returns (uint256) { UserPosition memory position = userPositions[user]; uint256 currentAssets = savings.totalAssets(); uint256 currentShares = savings.totalSupply(); // Calculate current value of user's shares uint256 currentValue = (position.shares * currentAssets) / currentShares; // Calculate original deposit value (approximate) uint256 originalValue = position.shares; // Assuming 1:1 at deposit return currentValue - originalValue; } ``` ## Rate modifications The inflation rate in a Savings module contract is encoded by keepers whitelisted by the DAO. As such, **it is non dilutive** and does not vary as people deposit more capital or withdraw their assets. Depending on the stablecoin and on the setup, governance may follow different update schedules. And the frequency of updates may vary from every week to every several months. Between two updates, depositors in Savings module contract are guaranteed to earn a fixed rate on their assets. # Flashloan Module Integration The Flashloan module serves as the core minting and burning engine for Parallel stablecoins. This [repo](https://github.com/parallel-protocol/parrallel-tokens/tree/main/contracts/flashloan) contains the contract implementation. In this guide, we explain how to interact with the Flashloan Module and fetch basical information from it. For more in depth information on how the Flashloan Module and its functions work, you can directly look into the code. :::info The Flashloan Module can be used for any Parallel stablecoins: find its deployment addresses [here](/developers-hub/contract-addresses/parallel-v3). ::: ## What is a Flashloan? Flashloans (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. ## What's similar/different with Parallel? The innovation with Parallel is that stablecoins given out in flashloans are minted during the flashloan transaction and burnt at the end of it: this means that the size of the flashloans taken is not capped by an amount of liquidity in a pool but rather by a parameter chosen by governance. This is similar to what Sky is doing in its [flash-mint module](https://docs.makerdao.com/smart-contract-modules/flash-mint-module). Like done elsewhere, flashloan transactions are only valid when the amount borrowed by the address taking the flashloan 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. There is only one simple `flashLoan` implementation in Parallel: it allows borrowers to get liquidity of a single stablecoin. Different stablecoins may be supported by the same `FlashParallel` contract. ## Execution Flow For developers, the following needs to be considered when building your flashloan solutions: 1. Your contract calls the `FlashParallel` contract requesting a certain `amount` of `token` to be sent to a `receiver` address of your choice. 2. After some elementary sanity checks, the `FlashParallel` contract transfers the tokens to the `receiver` contract address and then calls the `onFlashLoan` method of this contract. 3. Your contract now holding the flash-loaned `amount` executes any arbitrary operation in its code. These operations can be specified directly in the call to the `flashLoan` function through the `data` parameter. * When your code has finished, you need to approve the `FlashParallel` contract on the token for the flash-loaned amount plus the fee and then return `keccak256("ERC3156FlashBorrower.onFlashLoan")`. * If the amount due is not available (due to a lack of balance for instance), then the transaction is reverted 4. All of the above happens in 1 transaction and hence in a single block (on the chain you're on). ## Applications of Flashloans Flashloans 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. ## Flashloan Fee and Cap Parallel introduces for each stablecoin different parameters defining the fees that can be taken at each flashloan and the maximum size allowed for a flashloan. These parameters can be modified by governance votes. If you are building flashloans on top of Parallel, you may want to check these amounts prior to your call by calling the `flashFee` and `maxFlashLoan` function for your token of interest in the `FlashParallel` contract. ## Step by Step Guide ### 1. Setting up The first thing needed to make a flash-loan is a `receiver` contract which must conform to the `IERC3156FlashBorrower` [interface](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/interfaces/IERC3156FlashBorrower.sol). :::info Since the owed amounts will be pulled from your contract, your contract must give allowance to the pool to pull those funds to pay back the flashloan amount + premiums. ::: ### 2. Checking fees and maximum amount Prior to making a flashloan, you may want to check the fees induced and if the `amount` you want to take is inferior to the maximum amount allowed. The functions to call are `flashFee()` and `maxFlashLoan`. ### 3. Calling `flashLoan()` To call the `flashLoan` method on the `FlashParallel`, you need to pass the relevant parameters. In all cases, you need to make sure that the `receiver` address passed respects all the criteria from step 1. 1. From an EOA ('normal' ethereum account) or from a different contract: To use an EOA or a different contract, send a transaction to `FlashParallel` calling the `flashLoan` function. 2. From the same `receiver` contract: If you want to use the same contract as in step 1, use `address(this)` for the `receiver` address parameter in the flash-loan method. ### 4. Completing the flash-loan Once you have performed your logic with the flash loaned assets (in your `onFlashLoan()` function), you will need to pay back the flash loaned amount of tokens plus the eventual fees associated to the operation. You do not need to transfer the owed amount back to the `FlashParallel` contract. The funds will be automatically pulled at the conclusion of your operation. If your contract does not have the right amount on it, or if it has not approved the `FlashParallel` contract, then the whole operation will fail and the transaction will revert meaning you would have paid gas for nothing. # Parallel V2 :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: # Classic Vaults :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The Parallel Protocol's classic vaults smart contracts are open source on Github: * [https://github.com/mimo-capital/](https://github.com/mimo-capital/) But also below : * [VaultCore](/developers-hub/parallel-v2/classic-vaults/vaultscore) * [Opening a Vault](/developers-hub/parallel-v2/classic-vaults/opening-a-vault) * [Borrowing and minting PAR/paUSD](/developers-hub/parallel-v2/classic-vaults/borrowing-and-minting-par-pausd) # Architecture :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). :::
​The Parallel Protocol is a collection of decentralized and non-custodial smart contracts built to support the rest of the Decentralised Finance (DeFi) ecosystem: * **Vaults Core:** The main contract to interact with the Parallel protocol. All calculations happen here. * **Vaults Core State**: Owns the global state (cumulative rates & last refresh) for each collateral type available to borrow against. All state updates & calculations happen here * **PAR**: PAR is a standard ERC20 tokens, whose value is pegged to the EUR fiat currency. * **paUSD**: paUSD is a standard ERC20 tokens, whose value is pegged to the USD fiat currency * **Rates Manager**: Stateless. Calculates debt and fees for each Vault. * **Liquidation Manager**: Stateless. Calculates health factors and liquidation variables. * **PriceFeed:** Responsible for retrieving collateral prices in fiat, for calculating Vault health factors. * **FeeDistributor:** Responsible for collecting and distributing protocol fees. * **AddressProvider:** Indexes all module addresses read by other modules. * **ConfigProvider:** Responsible for updating protocol config parameters. * **VaultsDataProvider:** Owns vault state, base debt, and vault related read functions. # VaultsCore :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The **VaultsCore** contract is the main interface for the user to interact with the Parallel protocol’s collateralized debt system, such as depositing, borrowing, repaying, and liquidating debt. It stores the collateral, manages the safety reserve, and handles all debt calculations. The VaultsCore contract has the following interface: ``` interface IVaultsCore { function deposit ( address _collateralType , uint256 _amount ) external ; function depositByVaultId ( uint256 _vaultId , uint256 _amount ) external ; function depositAndBorrow ( address _collateralType , uint256 _depositAmount , uint256 _borrowAmount ) external ; function withdraw ( uint256 _vaultId , uint256 _amount ) external ; function withdrawAll ( uint256 _vaultId ) external ; function borrow ( uint256 _vaultId , uint256 _amount ) external ; function repayAll ( uint256 _vaultId ) external ; function repay ( uint256 _vaultId , uint256 _amount ) external ; function liquidate ( uint256 _vaultId ) external ; ... } ``` In addition to ERC20 collateral types, VaultsCore supports ETH directly through functions such as depositETH, withdrawETH and depositAndBorrowETH. # Opening a vault :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: *As of July 2021, the Parallel Protocol Vaults supports the following collateral assets: WETH, WBTC, and USDC.* To create a vault and deposit WETH collateral equal to `DEPOSIT_AMOUNT` to it, follow these steps: * Approve the collateral ERC20 asset (WETH) to the [**VaultsCore** address](https://app.gitbook.com/@mimo-defi/s/mimo-defi/~/drafts/-MewpTJxUIffxdZakurk/developers/contract-addresses) equal to at least the `DEPOSIT_AMOUNT`. ``` WETH.approve(VaultsCore address, DEPOSIT_AMOUNT) ``` * Call the `VaultsCore.deposit()` function with the desired collateral address and deposit amount. ``` VaultsCore.deposit(WETH address, DEPOSIT_AMOUNT) ``` * You can view your vault details from the `VaultsCore.vaults()`view function. ``` myVaultId = VaultsDataProvider.vaultId(WETH address, your address); myVault = VaultsDataProvider.vaults(vaultId) ``` * Each Vault has the following information: ``` struct Vault { address collateralType; address owner; uint256 collateralBalance; uint256 baseDebt; uint256 createdAt; } ``` # Borrowing and minting PAR/paUSD :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: To borrow and mint PAR/paUSD equal to `BORROW_AMOUNT`, call the `VaultsCore.borrow()` function. ``` VaultsCore.borrow(myVaultId, BORROW_AMOUNT); ``` Your maximum borrow amount is equal to: ``` Max Borrow amount = collateral deposit amount * collateral price / collateralization ratio (e.g. 1.6) ``` Make sure you do not borrow beyond your maximum borrow amount to avoid getting liquidated. # Bridging Module :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## Overview [BridgeableToken.sol](https://github.com/parallel-protocol/bridging-module/blob/main/docs/bridgeableToken/contracts/BridgeableToken.sol) allows an already deployed ERC-20 token to be bridgeable by leveraging [LayerZero's OFT standard](https://docs.layerzero.network/v2/home/protocol/contract-standards#oft). The Parallel Bridging Module codebase is available [here](https://github.com/parallel-protocol/bridging-module/tree/main), licensed under [MIT License](https://github.com/parallel-protocol/bridging-module/blob/main/LICENSE) and has been audited by BailSecurity. You can find the report [here](https://github.com/parallel-protocol/bridging-module/blob/main/docs/audits/Bailsec%20-%20Parallel%20Bridge%20-%20BridgeableToken%20-%20Final%20Report.pdf). Deployed addresses can be seen [here](/developers-hub/contract-addresses). ## Key Features The key features of `BridgeableToken` are: * Ability to burn principal tokens (named `XXX`) and send a message to LayerZero to mint the mirrored token on the other chain. * Ability to mint principal tokens by receiving a message from LayerZero from the mirrored BridgeableToken contract on the other chain. * Ability to cap the principal token amount to mint and burn (per day and globally). Since minting tokens from a received message must not revert, when the mint limit is reached, the user will receive OFT tokens (named `lz-XXX`) instead of principal tokens. * Ability to swap OFT tokens to principal tokens if the limits are not reached. ## High level Design:

High Level Design

## LayerZero OFT standard The OFT standard from LayerZero allows fungible tokens to be transferred across multiple blockchains without asset wrapping or middlechains. The BridgeableToken contract is designed to comply with this standard to mint/burn the OFT tokens if the mint/burn limit is reached. More details about the OFT standard can be found [here](https://docs.layerzero.network/v2/home/protocol/contract-standards#oft). ## Why do we need an OFT token ? When the contract receives a message from LayerZero to mint principal tokens on its chain, it must not revert. Due to the mint limit on the principal token, we still have to credit the user with something. This is why we mint OFT tokens instead of principal tokens XXX. The user can then swap these OFT tokens for principal tokens if the limit is not reached. ## Receiving Credit Messages from LayerZero When the contract receives a message from LayerZero, it will mint tokens to the specified receiver address. Depending on the mint limits, the receiver will be credited with principal tokens and/or OFT tokens. ## Sending Messages to LayerZero Users can send principal tokens or OFT tokens to a receiver address on another chain by calling the `send` function. A check regarding burn limits and isIsolateMode is performed before sending the message to LayerZero. If any check fails, the function will revert. The user's tokens will be burned before sending the message to LayerZero. # Architecture :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## Bridge Transaction Lifecycle Overview

Bridge Transaction Lifecycle

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. ## Principal Token Mint/Burn Limits The protocol has the possiblity to set mint/burn limits at daily and global levels. Only the **Owner** has the possibility to call related functions: * `setMintDailyLimit` : Maximum amount of principal tokens that can be minted in a day. * `setBurnDailyLimit` : Maximum amount of principal tokens that can be burned in a day. * `setGlobalMintLimit` : Maximum amount of principal tokens that can be minted globally. * `setGlobalBurnLimit` : Maximum amount of principal tokens that can be burned globally. When a burn limit is reached, the contract will simply revert future send requests for principal tokens. When a mint limit is reached, the contract will mint OFT tokens instead of principal tokens. Daily and global mint/burn limits on the principal token can be seen via view functions: * `getMintDailyLimit` : Maximum amount of principal tokens that can be minted in a day. * `getBurnDailyLimit` : Maximum amount of principal tokens that can be burned in a day. * `getGlobalMintLimit` : Maximum amount of principal tokens that can be minted globally. * `getGlobalBurnLimit` : Maximum amount of principal tokens that can be burned globally. ## IsolateMode A `toggleIsolateMode` function exists to toggle the `isIsolateMode` variable. This variable is used to prevent the contract to burn more principal token than what it has minted. This is useful when the contract is in a state where it has minted more principal tokens than it has burned. Only the **Owner** can call the`toggleIsolateMode` function. ## 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 **Owner** via the `setFeesRate` function, and are automatically sent to the address provided via the `setFeesRecipient` function. ## Pause A `pause` function exists to prevent new send() calls from being executed. This is useful in the event of a bug or security vulnerability. Only the **Owner** can call the `pause` function. ## Unpause An `unpause` function exists to Only the **Owner** may call unpause ## Swap OFT tokens to principal tokens As users can receive OFT tokens instead of principal tokens when one of the mint limit is reached, the contract provides a `swapLzTokenToPrincipalToken` function to swap these OFT tokens for principal tokens according to the limits. # Sample Use Cases :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ## User scenario 1 In this scenario, no limit is reached, and the user sends principal tokens. The user wants to send 100 principal tokens to another chain. The contract will burn 100 principal tokens and send a message to LayerZero to mint 100 principal tokens on the other chain.

user scenario 1

## User scenario 2 In this scenario, no limit is reached, but the user sends OFT tokens. The user wants to send 100 OFT tokens to another chain. The contract will burn 100 OFT tokens and send a message to LayerZero to mint 100 principal tokens on the other chain.

user scenario 2

## User scenario 3 In this scenario, a mint limit is reached. The user wants to send 100 principal tokens XXX to another chain. The contract will burn 100 principal tokens XXX and send a message to LayerZero to mint 100 principal tokens XXX, but as the mint limit is reached, the user will receive OFT tokens lz-XXX on the other chain.

user scenario 3

# Super Vault (SV) :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The Super Vaults smart contracts are open source on Github: * [https://github.com/code-423n4/2022-04-mimo/tree/main/supervaults/docs](https://github.com/code-423n4/2022-04-mimo/tree/main/supervaults/docs) But also below : * Contract Initialization * User Interaction * External Interactions * Methods * [Leverage Max Amount Derivation](/developers-hub/parallel-v2/super-vault-sv/leverage-max-amount-derivation) # Proxy Design :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: # MIMOProxy :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: Super Vault utilizes a proxy pattern to enable users to make proxy calls on behalf of other users and interact with various contracts (e.g., Parallel core protocol, DEX aggregators, flash loan protocols) within a single transaction. This pattern also allows for the integration with external contracts (e.g., lending pools and DEX aggregators) to carry out complex on-chain vault operations while still preserving proper access control to access VaultsCore. While the design was largely inspired by the [PRB Proxy pattern](https://github.com/paulrberg/prb-proxy), there are some differences : * The MIMOProxy is completely stateless and only holds an immutable `proxyFactory` state variable. In contrast, the PRBProxy retains three non-immutable state variables (`owner`, `minGasReserve`, and `permissions`). As the `MIMOProxy` relies on delegate calls to execute actions through action contracts, retaining state variables within it increases the risk of storage collisions with target calls. As a result, the `owner` and `minGas` variables are maintained by the MIMOProxyFactory's `_proxyStates` mapping. * The management of MIMOProxy's permissions has been outsourced to the `MIMOProxyGuard`, which is deployed through the Openzeppelin Clones library in the MIMOProxyFactory for each `MIMOProxy`. This helps save gas on deployment and enables easy permission clearing in the event of a MIMOProxy ownership transfer. * The `PRBProxyFactory` uses the CREATE2 opcode to deploy proxies at deterministic addresses, whereas the `MIMOProxyFactory` does not. This decision was made to save gas and because there is no need to deploy proxies at deterministic addresses. * The `MIMOProxy` uses the `BoringBatchable` to carry out batch delegate calls to `address(this)`. This is useful for linking calls to owner-protected functions such as setPermission() and execute() to minimize user transactions. Users can create a proxy by calling deploy() on the MimoProxyFactory contract, which deploys both a new MIMOProxy and clones a MIMOProxyGuard. ### Write Methods #### `execute(address target, bytes calldata data)` Delegate calls to the target contract by forwarding the call data. Returns the data it gets back, including when the contract call reverts with a reason or custom error. Requirements : * The caller must be either an owner or an envoy * `target` must be a deployed contract * The owner cannot be changed during the `DELEGATECALL` **Call Params** | Name | Type | Description | | -------- | ------- | --------------------------------------- | | `target` | address | The address of the target contract | | `data` | bytes | Function selector plus ABI encoded data | **Return Values** | Name | Type | Description | | ---------- | ----- | ---------------------------------------------- | | `response` | bytes | The response received from the target contract | ### View Methods #### `proxyFactory()` Returns the `proxyFactory` address. # MIMOProxyGuard :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: As previously mentioned, the management of MIMOProxy's permissions has been delegated to the `MIMOProxyGuard`, which is deployed through the Openzeppelin Clones library in the `MIMOProxyFactory` for each `MIMOProxy`. Having the permission management outside the `MIMOProxy` reduces the risk of storage collision, and having a separate contract for it enables easy permission clearing. In the event of an ownership transfer of the `MIMOProxy`, a new owner will likely want to clear existing permissions for security reasons (e.g., malicious action contracts may have been granted permissions before the transfer). However, due to the granularity of permissions, it would be difficult and expensive to remove them one by one. With the `MIMOProxyGuard`, a user can simply clone a new `MIMOProxyGuard`, which will not have any permissions set. ### Write Methods #### `initialize(address proxyFactory, address proxy)` Initializer function to set state variables upon cloning. | Param Name | Type | Description | | -------------- | ------- | ------------------------------------------------- | | `proxyFactory` | address | `MIMOProxyFactory` address | | `proxy` | address | Address of the `MIMOProxy` linked to the contract | #### `setPermission(address envoy, address target, bytes4 selector, bool permission)` Gives or takes a permission from an envoy to call the given target contract and function selector on behalf of the owner. Requirements : * Caller must the owner of the set `MIMOProxy` or the `MIMOProxy` | Param Name | Type | Description | | ------------ | ------- | ---------------------------------------------------- | | `envoy` | address | The address of the envoy account | | `target` | address | The address of the target contract | | `selector` | bytes4 | The 4 bytes function selector on the target contract | | `permission` | bool | The boolean permission to set | ### View Methods #### `getPermission(address envoy, address target, bytes4 selector)` Returns the permission for specific `envoy`, `target` and `selector`. **Call Params** | Name | Type | Description | | ---------- | -------- | ---------------------------------------------------- | | `envoy` | address | The address of the envoy account | | `target` | target | The address of the target contract | | `selector` | selector | The 4 bytes function selector on the target contract | **Return Values** | Name | Type | Description | | ------------ | ---- | ------------------------------------------------------------------ | | `permission` | bool | `true` if envoys is allowed to perform the call and `false` if not | #### `getProxy()` Returns the address of the MIMOProxy associated with the `MIMOProxyGuard` contract. # MIMOProxyFactory :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `MIMOProxyFactory` handles : * MIMOProxys' deployments * MIMOProxys' ownerhip transfers * MIMOProxys' permission clearing ## Write Methods : ### `deploy()` Deploys a new `MIMOProxy` and `MIMOProxy` guard for the caller. The caller must not owner any other `MIMOProxy` ### `transferOwnership(address proxy, address newOwner)` Initiates the ownership transfer process to a new owner and must be followed by a `claimOwnership` call by the new owner to complete the transfer. Sets the `newOwner` address as a `pendingOwner` of the transferred `MIMOProxy`. Requirements : * Must be called by the transferred `MIMOProxy` owner * Cannot transfer ownership to `address(0)` * New owner must not own any other `MIMOProxy` | Param Name | Type | Description | | ---------- | ------- | -------------------------------------- | | `proxy` | address | Address of the `MIMOProxy` to transfer | | `newOwner` | address | Address of the new owner | ### `claimOwnership(address proxy, bool clear)` Completes the ownership transfer process. Requirements : * Must be called by the `pendingOwner` of `proxy` * Caller must not own any other `MIMOProxy` | Param Name | Type | Description | | ---------- | ------- | ------------------------------------------------------------------- | | `proxy` | address | Address of the `MIMOProxy` to claim | | `clear` | bool | Clear existing proxy permissions if true and maintain them if false | ### `clearPermissions(address proxy)` Deploys a new `MIMOProxyGuard` for the targeted `proxy` therefore clearing all existing permissions. Requirements : * Must be called by `proxy` owner | Param Name | Type | Description | | ---------- | ------- | --------------------------------------------------------- | | `proxy` | address | Address of the `MIMOProxy` for which to clear permissions | ### `setMinGas(address proxy, uint256 minGas)` Sets a new `minGas` value for the targeted `proxy`. Requirements : * Must be called by `proxy` owner | Param Name | Type | Descripton | | ---------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `proxy` | address | Address of the `MIMOProxy` to update | | `minGas` | uint256 | Gas to reserve for running the remainder of the `execute` function after the `delegatecall` in the `MIMOProxy`. Prevents the proxy from becoming unusable if EVM opcode gas costs change in the future. | ## View Methods ### `isProxy(address proxy)` Checks if an address is a valid `MIMOProxy`. **Call Params** | Name | Type | Description | | ------- | ------- | ----------------------------------- | | `proxy` | address | Address of the `MIMOProxy` to check | **Return Values** | Name | Type | Description | | -------- | ---- | ----------------------------------------------------- | | `result` | bool | `true` if proxy has been deployed and `false` if not. | ### `getProxyState(address proxy)` Returns the targeted `proxy` state. **Call Params** | Name | Type | Description | | ------- | ------- | ---------------------------------------------- | | `proxy` | address | Address of the `MIMOProxy` to fetch state from | **Return Values** | Name | Type | Description | | ------------ | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | `proxyState` | struct |

ProxyState :

  • address owner
  • IMIMOProxyGuard proxyGuard
  • uint256 minGas
| ### `getCurrentProxy(address owner)` Returns the `MIMOProxy` address for a specific `owner`. **Call Params** | Name | Type | Description | | ------- | ------- | ------------------------- | | `owner` | address | The address of the owner. | **Return Values** | Name | Type | Description | | ------- | ------------ | ----------------------------- | | `proxy` | `IMIMOProxy` | The `MIMOProxy` of the owner. | #### `getPendingOwner(address proxy)` Returns the pending owner of a specific `proxy`. **Call Params** | Name | Type | Description | | ------- | ------- | -------------------------- | | `proxy` | address | Address of the `MIMOProxy` | **Return Values** | Name | Type | Description | | -------------- | ------- | ------------------------------------------------------------------------------- | | `pendingOwner` | address | Pending owner who has yet to claim the ownership of the transferred `MIMOProxy` | #### `getProxy()` Returns the address of the `MIMOProxy` associated with the `MIMOProxyGuard`. #### `proxyFactory()` Returns the `proxyFactory` address. # Action Contracts :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: ### Super vault specific action contracts Just like with the `PRBProxy` you need a "target" contract to do anything meaningful with `MIMOProxy`. This is basically a collection of stateless scripts executing specific logic. In the case of super vaults there are 5 different action contracts (one for each functionality) : * [MIMOEmptyVault](/developers-hub/parallel-v2/super-vault-sv/action-contracts/mimoemptyvault) * [MIMOLeverage](/developers-hub/parallel-v2/super-vault-sv/action-contracts/mimoleverage) * [MIMORebalance](/developers-hub/parallel-v2/super-vault-sv/action-contracts/mimorebalance) * [MIMOAutoRebalance](/developers-hub/parallel-v2/super-vault-sv/action-contracts/mimoautorebalance) * [MIMOManagedRebalance](/developers-hub/parallel-v2/super-vault-sv/action-contracts/mimomanagedrebalance) All actions on the SuperVault contracts require flash loans and DEX aggregator swaps, and to perform these actions, the contracts must have permission to call back the delegate call through the `MIMOProxy` `execute` function. This is because the action contracts interact with other contracts, such as the Mimo core protocol or DEX aggregators, within the same transaction and are executed within the context of the `MIMOProxy`. However, when the AAVE Pool contract performs a callback through the `executeOperation` function, the logic switches from the `MIMOProxy` context to the action contract's context, preventing any access-controlled actions on `VaultsCore`. To reenter the `MIMOProxy` context, the action contract must perform a callback by calling the `MIMOProxy` `execute` with itself as the target. For this to happen, the action contract must be granted the correct permission by the `MIMOProxy` owner.
All of the above action contracts share 2 common struct passed in as arguments for flash loan and swaps : **`FlashLoanData`** | Param Name | Type | Description | | ------------- | ------- | -------------------------------------------------------- | | `asset` | address | Asset to flash loan | | `proxyAction` | address | Address of the action contract performing the flash loan | | `amount` | uint256 | Flash loan amount | **`SwapData`** | Param Name | Type | Description | | ----------- | ------- | -------------------------------------------- | | `dexIndex` | uint256 | Aggregator index in the `DexAddressProvider` | | `dexTxData` | bytes | Off chain route fetched from aggregator API | ### Non super vault specific action contracts The `MIMOProxy` also comes with non super vault specific action contracts : * [MIMOProxyActions](/developers-hub/parallel-v2/super-vault-sv/action-contracts/mimoproxyactions) * [MIMOVaultActions](/developers-hub/parallel-v2/super-vault-sv/action-contracts/mimovaultactions) # MIMOEmptyVault :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `MIMOEmptyVault` action contracts handle the super vault empty vault logic described in [Empty Vault](/products/parallel-v2/how-it-works/super-vaults-sv/emptyvault). ### Process Flow
### Write Methods #### `executeAction(bytes calldata _calldata) external` Uses a flashloan to repay all debts for a vault and send all collateral in the vault to the owner. Requirements : * Contract must be unpaused * Must be called through the `MIMOProxy` `execute()` function * Targeted vault must have been created by the `MIMOProxy` | Param Name | Type | Description | | ---------- | ----- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | \_callData | bytes |

Abi encoded bytes with :

  • uint256 vaultId
  • FlashloanData flData
  • SwapData swapData
| #### `executeOperation(address[] calldata assets, uint256[] calldata amounts, uint256[] calldata premiums, address initiator, bytes calldata params` AAVE `Pool` contract flash loan callback function. Requirements : * Contract must be unpaused * Can only be called by the AAVE `Pool` contract * Flash loan initiator must be the `MIMOProxy` | Param Name | Type | Description | | ----------- | ---------- | ---------------------------------------------------------------------------------------- | | `assets` | address\[] | Address array with one element corresponding to the address of the target vault asset | | `amounts` | uint256\[] | Uint array with one element corresponding to the amount of the target vault asset | | `premiums` | uint256\[] | Uint array with one element corresponding to the flashLoan fees | | `initiator` | address | Initiator of the flashloan; can only be MIMOProxy owner | | `params` | bytes | Bytes sent by this contract containing MIMOProxy owner, target vault id, SwapData struct | #### `emptyVaultOperation(address owner, IERC20 vaultCollateral, uint256 vaultId, uint256 swapAmount, uint256 flashLoanRepayAmount, SwapData calldata swapData)` Performs a empty vault logic within `MIMOProxy` context. Requirements : * Contract must be unpaused * Must be called through the `MIMOProxy` `execute()` function | Param Name | Type | Description | | ---------------------- | ------- | ---------------------------------------------------------------------------------- | | `owner` | address | Address of the `MIMOProxy` owner | | `vaultCollateral` | IERC20 | Collateral of the vault to empty | | `vaultId` | uint256 | Vault id of the vault to be emptied | | `swapAmount` | uint256 | Amount of collateral to swap to for par to repay vault debt | | `flashLoanRepayAmount` | uint256 | Amount of collateral to repay to flash loan protocol at the end of the transaction | | `swapData` | struct | SwapData passed from the flash loan call | ### View Methods `proxyFactory()` Returns the `MIMOProxyFactory` address. # MIMOLeverage :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `MIMOLeverage` action contract handle the super vault empty vault logic described in [Leveraging](/products/parallel-v2/how-it-works/super-vaults-sv/leveraging). ### Process Flow
### Write Methods #### `executeAction(bytes calldata _calldata) external` Uses a flashloan to repay all debts for a vault and send all collateral in the vault to the owner. Requirements : * Contract must be unpaused * Must be called through the `MIMOProxy` `execute()` function * Targeted vault must have been created by the `MIMOProxy` | Param Name | Type | Description | | ---------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | \_callData | bytes |

Abi encoded bytes with :

  • uint256 depositAmount
  • uint256 swapAmout
  • FlashloanData flData
  • SwapData swapData
| #### `executeOperation(address[] calldata assets, uint256[] calldata amounts, uint256[] calldata premiums, address initiator, bytes calldata params` AAVE `Pool` contract flash loan callback function. Requirements : * Contract must be unpaused * Can only be called by the AAVE `Pool` contract * Flash loan initiator must be the `MIMOProxy` | Param Name | Type | Description | | ----------- | ---------- | ---------------------------------------------------------------------------------------- | | `assets` | address\[] | Address array with one element corresponding to the address of the target vault asset | | `amounts` | uint256\[] | Uint array with one element corresponding to the amount of the target vault asset | | `premiums` | uint256\[] | Uint array with one element corresponding to the flashLoan fees | | `initiator` | address | Initiator of the flashloan; can only be MIMOProxy owner | | `params` | bytes | Bytes sent by this contract containing MIMOProxy owner, target vault id, SwapData struct | #### leverageOperation`(IERC20 token, uint256 swapAmount, uint256 flashLoanRepayAmount, SwapData calldata swapData)` Performs a leverage logic within MIMOProxy context. Requirements : * Contract must be unpaused * Must be called through the `MIMOProxy` `execute()` function | Param Name | Type | Description | | ---------------------- | ------- | ---------------------------------------------------------------------------------- | | `token` | IERC20 | Collateral of the vault to leverage | | `swapAmount` | uint256 | Stablex swap amount | | `flashLoanRepayAmount` | uint256 | Amount of collateral to repay to flash loan protocol at the end of the transaction | | `swapData` | struct | SwapData passed from the flash loan call | ### View Methods `proxyFactory()` Returns the `MIMOProxyFactory` address. # MIMORebalance :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `MIMOLeverage` action contract handle the super vault empty vault logic described in [Rebalancing](/products/parallel-v2/how-it-works/super-vaults-sv/rebalancing).
### Write Methods #### `executeAction(bytes calldata _calldata) external` Uses a flash loan to repay all debts for a vault and send all collateral in the vault to the owner. Requirements : * Contract must be unpaused * Must be called through the `MIMOProxy` `execute()` function * Targeted vault must have been created by the `MIMOProxy` | Param Name | Type | Description | | ---------- | ----- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | \_callData | bytes |

Abi encoded bytes with :

  • FlashloanData flData
  • RebalanceData rbData
  • SwapData swapData
| **`RebalanceData`** | Param Name | Type | Description | | -------------- | ------- | --------------------------------------------------------------------------- | | `toCollateral` | IERC20 | Collateral to rebalance to | | `vaultId` | uint256 | Id of the vault to rebalance | | `mintAmount` | uint256 | Amount of stableX to mint on rebalancing vault to swap and repay flash loan | #### `executeOperation(address[] calldata assets, uint256[] calldata amounts, uint256[] calldata premiums, address initiator, bytes calldata params` AAVE `Pool` contract flash loan callback function. Requirements : * Contract must be unpaused * Can only be called by the AAVE `Pool` contract * Flash loan initiator must be the `MIMOProxy`
Param NameTypeDescription
assetsaddress\[]Address array with one element corresponding to the address of the target vault asset
amountsuint256\[]Uint array with one element corresponding to the amount of the target vault asset
premiumsuint256\[]Uint array with one element corresponding to the flashLoan fees
initiatoraddressInitiator of the flashloan; can only be MIMOProxy owner
paramsbytesBytes sent by this contract containing MIMOProxy owner, target vault id, SwapData struct
#### rebalanceOperation`(IERC20 fromCollateral, uint256 swapAmount, uint256 flashLoanRepayAmount, uint256 fee, RebalanceData calldata rbData, SwapData calldata swapData)` Performs a rebalance logic within MIMOProxy context. Requirements : * Contract must be unpaused * Contract must be unpaused * Must be called through the `MIMOProxy` `execute()` function | Param Name | Type | Description | | ---------------------- | ------- | ---------------------------------------------------------------------------------------------------------- | | `fromCollateral` | IERC20 | Collateral of the vault to rebalance | | `swapAmount` | uint256 | The amount of collateral to swap to for stableX to repay vaultdebt | | `flashLoanRepayAmount` | uint256 | Amount of collateral to repay to flash loan protocol at the end of the transaction | | `fee` | uint256 | Optional fee to be passed in the context of a `ManagedRebalance` to mint additional stablex to pay manager | | `rbData` | struct | `RebalanceData` passed from the flashloan call | | `swapData` | struct | SwapData passed from the flash loan call | ### View Methods `proxyFactory()` Returns the `MIMOProxyFactory` address. # MIMOAutoRebalance :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `MIMOAutoRebalance` action contract handle the super vault empty vault logic described in [Automated Rebalance](/products/parallel-v2/how-it-works/super-vaults-sv/automated-rebalance). ### Process Flow
### Write Methods #### `setAutomation(uint256 vaultId, AutomatedVault calldata autoParams)` Sets a vault automation parameters. Requirements : * Caller must be the `MIMOProxy` owner the vault or the `MIMOProxy` owner | Param Name | Type | Description | | ------------ | ------- | ---------------------------------------------------------- | | `vaultId` | uint256 | | | `autoParams` | struct | AutomatedVault struct containing all automation parameters | **`AutomatedVault`** | Param Name | Type | Description | | ------------------ | ------- | ---------------------------------------------------------------------------------- | | `isAutomated` | bool | `true` if vault is automated `false` if not | | `toCollateral` | address | Collateral to rebalance to | | `allowedVariation` | uint256 | The maximum allowed slippage on rebalancing swaps | | `targetRatio` | uint256 | Target ratio that must be reach upon each rebalance operation | | `triggerRatio` | uint256 | Minimum vault ratio that must be reached in order to perform a rebalance operation | | `mcrBuffer` | uint256 | Rebalancing vault MCR buffer padding | | `fixedFee` | uint256 | Fixed fee paid to the keeper | | `varFee` | uint256 | Variable fee paid to the keeper | #### `rebalance(uint256 vaultId, IMIMOSwap.SwapData calldata swapData)` Performs a rebalance on a vault on behalf of a vault owner. Requirements : * Contract must be unpaused * Vault must have been created through the user's `MIMOProxy` * Vault must be automated * Maximum daily operation must have not been reached * Rebalanced vault ratio must lower or equal then set `triggerRatio` * The change in vault value due to the rebalance operation must be lower or equal then the `allowedVariation` set by the owner * The final vault ratio must be greater or equal then the `minRatio` set by the owner | Param Name | Type | Description | | ---------- | ------- | ------------------------------------------------------- | | `vaultId` | uint256 | Id of the vault to rebalance | | `swapData` | struct | `SwapData` struct containing aggregator swap parameters | #### `executeOperation(address[] calldata assets, uint256[] calldata amounts, uint256[] calldata premiums, address initiator, bytes calldata params` AAVE `Pool` contract flash loan callback function. Requirements : * Contract must be unpaused * Can only be called by the AAVE `Pool` contract * Flash loan initiator must be the `MIMOProxy`
Param NameTypeDescription
assetsaddress\[]Address array with one element corresponding to the address of the target vault asset
amountsuint256\[]Uint array with one element corresponding to the amount of the target vault asset
premiumsuint256\[]Uint array with one element corresponding to the flashLoan fees
initiatoraddressInitiator of the flashloan; can only be MIMOProxy owner
paramsbytesBytes sent by this contract containing MIMOProxy owner, target vault id, SwapData struct
### View Methods #### `getAmounts(uint256 vaultId, address toCollateral)` Returns the rebalance amounts for specific vault id. **Call Params** | Name | Type | Description | | -------------- | ------- | ---------------------------- | | `vaultId` | uint256 | Id of the vault to rebalance | | `toCollateral` | address | Collateral to rebalance to | **Return Values** | Name | Type | Description | | ----------------- | ------- | ------------------------- | | `rebalanceAmount` | uint256 | Amount to rebalance | | `mintAmount` | uint256 | Amount to mint on vault B | | `autoFee` | uint256 | Automation fee | `rebalanceAmount` calculation : rebalanceValue=targetRatio∗(vaultDebt+fixedFee)−collateralValuetargetRatio−(mcrB+mcrBuffer)∗flashLoanfeemcrB+mcrBuffer−targetRatio∗variableFee−1rebalanceValue = \\frac{targetRatio * (vaultDebt + fixedFee) - collateralValue}{\\frac{targetRatio - (mcrB + mcrBuffer) * flashLoanfee}{mcrB + mcrBuffer} - targetRatio * variableFee - 1}rebalanceValue=mcrB+mcrBuffertargetRatio−(mcrB+mcrBuffer)∗flashLoanfee​−targetRatio∗variableFee−1targetRatio∗(vaultDebt+fixedFee)−collateralValue​"} /> Where `mcrB` is the rebalancing vault (e.g. vault with the less volatile collateral) MCR. The rebalance value is then converted to a rebalance amount using the core protocol `PriceFeed` contract. #### `mimoRebalance()` Returns the `MIMORebalance` action contract address. # MIMOManagedRebalance :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `MIMOManagedRebalance` action contract handle the super vault empty vault logic described in [Managed Rebalance](/products/parallel-v2/how-it-works/super-vaults-sv/managed-rebalance). ### Process Flow
### Write Methods #### `setManagement(uint256 vaultId, ManagedVault calldata mgtParams)` Sets a vault management parameters. Requirements : * Caller must be the `MIMOProxy` owner the vault or the `MIMOProxy` owner * Selected manager must be whitelisted | Param Name | Type | Description | | ----------- | ------- | -------------------------------------------------------- | | `vaultId` | uint256 | | | mgt`Params` | struct | ManagedVault struct containing all management parameters | **`ManagedVault`** | Param Name | Type | Description | | ------------------ | ------- | ----------------------------------------------------------------------------------------- | | `isManaged` | bool | `true` if vault is under management `false` if not | | `manager` | address | Selected manager address | | `allowedVariation` | uint256 | The maximum allowed slippage on rebalancing swaps | | `minRatio` | uint256 | Minimum vault ratio above which the starting vault be at the end of a rebalance operation | | `fixedFee` | uint256 | Fixed fee paid to the manager | | `varFee` | uint256 | Variable fee paid to the manager | | `mcrBuffer` | uint256 | Rebalancing vault MCR buffer padding | #### `rebalance(uint256 vaultId,` IMIMORebalance.RebalanceData calldata rbData,`IMIMOSwap.SwapData calldata swapData)` Performs a rebalance on a vault by an appointed whitelisted manager on behalf of the vault owner. Requirements : * Contract must be unpaused * Vault must have been created through the user's `MIMOProxy` * Vault must be under management * Caller must be the appointed manager * Rebalance amount cannot be set to zero * Maximum daily operation must have not been reached * Set mint amount cannot be greater than vault debt * The change in vault value due to the rebalance operation must be lower or equal then the `allowedVariation` set by the owner * The final vault ratio must be greater or equal then the `minRatio` set by the owner | Param Name | Type | Description | | ---------- | ------ | ---------------------------------------------------------------- | | `flData` | struct | `FlashLoanData` struct containing flash loan parameters | | `rbData` | struct | `RebalanceData` struct containing rebalance operation parameters | | `swapData` | struct | `SwapData` struct containing aggregator swap parameters | #### `executeOperation(address[] calldata assets, uint256[] calldata amounts, uint256[] calldata premiums, address initiator, bytes calldata params` AAVE `Pool` contract flash loan callback function. Requirements : * Contract must be unpaused * Can only be called by the AAVE `Pool` contract * Flash loan initiator must be the `MIMOProxy`
Param NameTypeDescription
assetsaddress\[]Address array with one element corresponding to the address of the target vault asset
amountsuint256\[]Uint array with one element corresponding to the amount of the target vault asset
premiumsuint256\[]Uint array with one element corresponding to the flashLoan fees
initiatoraddressInitiator of the flashloan; can only be MIMOProxy owner
paramsbytesBytes sent by this contract containing MIMOProxy owner, target vault id, SwapData struct
### View Methods #### `mimoRebalance()` Returns the `MIMORebalance` action contract address. # MIMOProxyActions :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `MIMOProxyActions` contract can be seen as an extension of the `MIMOProxy`. It adds 2 main functionalities : * The ability for a `MIMOProxy` owner to transfer native tokens (ETH for example) back to his address through the `withdrawETH()` function. * The ability to chain calls within a single transaction through the `multicall()` function. These functions have been outsourced to an action contract in order to reduce the deployments costs of the `MIMOProxy`. ### `withdrawETH()` Sends ETH back to owner of the `MIMOProxy`. Requirements : * Caller must be the `MIMOProxy` owner ### `multicall(address[] calldata targets, bytes[] calldata data)` Call multiple functions and returns the data from all of them if they all succeed. Requirements : * Must be called through the `MIMOProxy` `execute()` function * Targets must all be contracts not EOA * `targets` length must be the same as `data` length | Param Name | Type | Description | | ---------- | ---------- | --------------------------------------------------------- | | `targets` | address\[] | Address array of all contracts to call | | `data` | bytes\[] | Bytes array of encoded function data for each target call | # MIMOVaultActions :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: The `MIMOVaultActions` actions contract is a mirror of the `VaultsCore` owner access restricted functionalities. Its sole purpose is to provide a readable way for `MIMOProxy` owners to interact with `VaultsCore` through their `MIMOProxy` :::info All functions non payable functions of the `MIMOVaultActions can be reproduced through the MIMOProxyActions multicall() function.` ::: ### Write Methods #### `function deposit(IERC20 collateral, uint256 amount)` Calls `VaultsCore` `deposit()`. | Param Name | Type | Description | | ------------ | ------- | -------------------------------------------------- | | `collateral` | IERC20 | The address of the collateral type to be deposited | | `amount` | uint256 | The amount of tokens to be deposited | #### `function depositETH()` Calls `VaultsCore` `depositETH()`. #### `depositAndBorrow(address _collateralType, uint256 _depositAmount, uint256 _borrowAmount)` Calls `VaultsCore` `depositAndBorrow()`. | Param Name | Type | Description | | ----------------- | ------- | -------------------------------------------------- | | `_collateralType` | address | The address of the collateral type to be deposited | | `_depositAmount` | uint256 | The amount of tokens to be deposited in WEI | | \_`borrowAmount` | uint256 | The amount of borrowed StableX tokens in WEI | #### `depositETHAndBorrow(uint256 borrowAmount)` Calls `VaultsCore` `depositETHAndBorrow()`. | Param Name | Type | Description | | -------------- | ------- | -------------------------------------------- | | `borrowAmount` | uint256 | The amount of borrowed StableX tokens in WEI | #### `withdraw(uint256 vaultId, uint256 amount)` Calls `VaultsCore` `withdraw()`. | Param Name | Type | Description | | ---------- | ------- | --------------------------------------------------------- | | `vaultId` | uint256 | The id of the vault from which to withdraw the collateral | | `amount` | uint256 | The amount of ERC20 tokens to be withdrawn | #### `withdrawETH(uint256 vaultId, uint256 amount)` Calls `VaultsCore` `withdrawETH()`. | Param Name | Type | Description | | ---------- | ------- | --------------------------------------------------------- | | `vaultId` | uint256 | The id of the vault from which to withdraw the collateral | | `amount` | uint256 | The amount of ETH to be withdrawn | #### `borrow(uint256 vaultId, uint256 amount)` Calls `VaultsCore` `borrow()`. | Param Name | Type | Description | | ---------- | ------- | ---------------------------------------- | | `vaultId` | uint256 | The id of the vault from which to borrow | | `amount` | uint256 | The amount of `stableX` to borrow | ### View Methods #### `contractAddress()` Returns the `MIMOVaultActions` address. This is to access the contract address within the delegate call. #### core`()` Returns the `VaultsCore` address. #### `vaultsData()` Returns the `VaultsDataProvider` address. #### `stablex()` Returns the `stableX` address. #### `proxyFactory()` Returns the `MIMOProxyFactory` address. # Leverage Max Amount Derivation :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: If we have a starting amount of collateral `S`, the Minimum Collateralization Ratio (MCR) of the collateral limits how much additional collateral `L` we can leverage: After leveraging, we will have a total of `S+L` of collateral in our vault. The protocol enforces that we can borrow a maximum of `(S+L)/MCR` collateral's worth of PAR from our vault. We will use this PAR to swap and repay the loan at the end of the leverage transaction, so the amount of PAR we withdraw must also be worth at least `L` collateral, neglecting flashloan fees (otherwise, we won't have enough to repay the loan) In other words, when we leverage the maximum amount of collateral, the amount of PAR we exchange must be simultaneously worth at most `(S+L)/MCR` of collateral (as dictated by the MIMO protocol) and at least `L` of collateral (as dictated by the flashloan protocol). Thus, we can set both expressions equal to each other to get the equation: `(L+S)/MCR = L` Solving the above equation for `L` gives us the maximum amount of additional collateral `L` we can leverage: `L = S/(MCR - 1)` We can additionally account for any flashloan fees by further dividing `L` by `1 + (flashloan fees)`. For example, if we assume: * We start out with 1 ETH; i.e. `S = 1` * We want to leverage an additional 1 ETH; i.e. `L = 1` * The PAR/USD exchange rate is `1 PAR = 1.1 USD` * The ETH/USD exchange rate is `1 ETH = 3000 USD` * The MCR for ETH is 1.3; i.e. `MCR = 1.3` The protocol enforces that we can borrow a maximum of `(S+L)/MCR`, or `(1+1)/(1.3)`, or `1.54` ETH's worth of PAR from our vault. That works out to `(1.54 ETH) * (3000 USD / 1 ETH) * (1 PAR / 1.1 USD)` or `4200` PAR. We will also need to have at least `1 ETH`'s worth of PAR to repay the flashloan. `1 ETH` works out to `(1 ETH) * ( 3000 USD / 1 ETH ) * (1 PAR / 1.1 USD)` or ~ 2727.27 PAR. Since the amount of PAR we can withdraw from our vault is higher than the amount of PAR we need to repay our loan, we can leverage this amount. Assuming the above numbers, the maximum amount of additional ETH we could have leveraged was `S/(MCR-1)` or `(1 ETH)/(1.3 - 1)` or ~ 3.33 ETH. # Addresses # Parallel V3 In this section you can find deployed Parallel V3 contract addresses: * [USDp](/developers-hub/contract-addresses/parallel-v3/usdp) * [PRL](/developers-hub/contract-addresses/parallel-v3/prl) # USDp Contract Addresses # PRL Contract Addresses # Parallel V2 :::warning You're reading the legacy **v2** documentation. For current Parallel features, see [v3](/products/parallel-v3). ::: In this section you can find deployed contract addresses for PAR & paUSD: * [PAR](/developers-hub/contract-addresses/parallel-v2/par) * [paUSD](/developers-hub/contract-addresses/parallel-v2/pausd-deprecated) # PAR Contract Addresses # PAUSD-DEPRECATED Contract Addresses # MIMO-DEPRECATED Contract Addresses # Build with Parallel Tools for accepting stablecoin payments and building agents that pay autonomously. ## How AI agents pay for APIs AI agents can't use credit cards. They can't fill out checkout forms. They need a protocol-level way to pay APIs autonomously — one request, one payment, no human in the loop. [x402](/agents/x402) is that protocol. An HTTP-native `402 Payment Required` flow: the API server requires payment, the agent signs a stablecoin transfer, the facilitator verifies and settles it, and the agent gets the response. Sub-second latency, sub-cent fees. Parallel runs an [x402 facilitator](/agents/x402/concepts) that: * Accepts USDp, USDC, and other major stablecoins * Sponsors the gas on Base, Arbitrum, HyperEVM, and Avalanche * Charges no platform fee * Settles directly to the merchant's wallet — no Parallel account required [Read the x402 quickstart →](/agents/x402/quickstart) ## Which one do you need? | You want to... | Use | |---|---| | Accept stablecoin payments in your API | [x402](/agents/x402) | | Build an AI agent that pays APIs autonomously | [x402 SDK](/agents/x402/quickstart) | | Migrate from another x402 facilitator | [Migration guide](/agents/recipes/migrate-from-coinbase-x402) | # What is x402? **x402** is an open standard for paying for an HTTP request with stablecoins. It is built on the long-reserved HTTP status code [`402 Payment Required`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402). The idea is simple: an API can require a payment for a route. When a client calls that route without paying, the server replies `402` and describes exactly what is owed and to whom. The client signs a stablecoin payment off-chain, retries the request with a payment header, and the server lets it through once the payment is verified. It was designed for the agent economy. AI agents can't hold credit cards or complete checkout forms — but they can sign a stablecoin transfer and attach it to a request. x402 gives them a native, one-request-one-payment way to pay for APIs. ## What Parallel provides Parallel runs an **x402 facilitator** and ships drop-in middleware so any API can accept stablecoin payments in a few lines: * **Drop-in middleware** for Express, Next.js, Fastify, and Hono. * **Accepts USDp, USDC, and other major stablecoins** — the SDK routes the payment automatically. * **Zero platform fee** — Parallel takes no cut of your revenue. * **Gas sponsored on L2** — Base, Arbitrum, HyperEVM, and Avalanche. * **Settles directly to your wallet** — non-custodial, no Parallel account. * **Open source, MIT licensed** — self-host if you want. ## Start here # Accept stablecoins in 5 minutes This guide adds stablecoin payment support to an API. The same pattern works for Express, Next.js, Fastify, and Hono. ## 1. Install the middleware ```bash npm install @parallel-protocol/x402 ``` Install your framework separately — they are optional peer dependencies: ```bash npm install express # or: next · fastify · hono ``` ## 2. Add the middleware Point the middleware at the facilitator, then declare which routes are paid, at what price, on which network, and where funds should settle. ```ts import express from "express"; import { paymentMiddleware } from "@parallel-protocol/x402/express"; const app = express(); app.use( paymentMiddleware({ facilitator: { url: "https://facilitator.parallel.best" }, routes: { "/api/data": { price: "0.01", network: "base", payTo: "0xYourAddress" }, }, }), ); app.get("/api/data", (req, res) => { res.json({ data: "protected content" }); }); app.listen(3000); ``` ```ts // app/api/data/route.ts import { withPayment } from "@parallel-protocol/x402/next"; const config = { facilitator: { url: "https://facilitator.parallel.best" }, routes: { "/api/data": { price: "0.10", network: "ethereum", payTo: "0xYourAddress" }, }, }; export const GET = withPayment(config, async (req) => { return Response.json({ data: "protected content" }); }); ``` ```ts import Fastify from "fastify"; import { paymentMiddleware } from "@parallel-protocol/x402/fastify"; const app = Fastify(); await app.register( paymentMiddleware({ facilitator: { url: "https://facilitator.parallel.best" }, routes: { "/api/data": { price: "0.05", network: "avalanche", payTo: "0xYourAddress" }, }, }), ); app.get("/api/data", async () => ({ data: "protected content" })); ``` ```ts import { Hono } from "hono"; import { paymentMiddleware } from "@parallel-protocol/x402/hono"; const app = new Hono(); app.use( paymentMiddleware({ facilitator: { url: "https://facilitator.parallel.best" }, routes: { "/api/data": { price: "0.01", network: "base", payTo: "0xYourAddress" }, }, }), ); app.get("/api/data", (c) => c.json({ data: "protected content" })); ``` That's it. Your API now charges $0.01 per request to `/api/data`. Agents pay in any [supported stablecoin](/agents/x402/concepts#supported-stablecoins) — funds settle directly to the wallet address you configured. **No signup. No platform fee. Funds settle straight to your wallet.** :::tip `price` is a string parsed at the token's decimals (18 for USDp by default). For a USDC-denominated price, set `decimals: 6` on the route. See the [route configuration](/agents/x402/api-reference#routeconfig). ::: ## 3. What happens behind the scenes When an agent calls your endpoint with a signed payment header: 1. The middleware sends the payload to the facilitator's `/x402/verify` endpoint — an instant, off-chain signature check. 2. If valid, **your handler runs** and produces the response. 3. If your handler returns a 2xx, the middleware calls `/x402/settle` — the on-chain transfer happens. 4. If your handler fails, **no settlement happens** — the agent is not charged. Read more: [The verify / settle flow](/agents/x402/verify-vs-settle). ## Next steps * [Concepts: how routing, fees, and gas work](/agents/x402/concepts) * [Migrate from Coinbase x402 in one line](/agents/recipes/migrate-from-coinbase-x402) * [API reference](/agents/x402/api-reference) # How the facilitator works The **facilitator** is the service that verifies and settles x402 payments on-chain. Your API never touches a smart contract — the middleware talks to the facilitator, and the facilitator does the on-chain work. You declare paid routes in your middleware; the facilitator handles the rest. ## The payment flow Every paid request goes through two phases: 1. **Verify** — the facilitator checks the agent's signed payment off-chain. Instant, no transaction. If it's valid, your handler runs. 2. **Settle** — once your handler returns a success response, the facilitator submits the transfer on-chain and returns a settlement proof. If verification fails, your handler never runs. If your handler fails, settlement never happens — the agent is only charged for a successful response. See [verify vs settle](/agents/x402/verify-vs-settle) for the full sequence. ## Supported stablecoins By default the facilitator accepts **USDp** and **USDC**, plus other major stablecoins depending on the network. The agent pays in whatever supported stablecoin it holds; you receive the token you configured. You can narrow or widen the accepted set per route with the [`acceptedTokens`](/agents/x402/api-reference#routeconfig) option. ## Smart routing You set a price. The agent holds some stablecoin. The facilitator picks the cheapest settlement path between the two automatically — neither you nor the agent has to choose. If an agent pays in a different stablecoin than the one you want to receive, conversion is handled in the same settlement, at no extra platform fee. ## Fees and gas * **Zero platform fee.** Parallel does not take a cut of your revenue. * **Gas sponsored on L2.** Transactions on Base, Arbitrum, HyperEVM, and Avalanche are gas-sponsored. On Ethereum mainnet, standard gas applies. ## Supported networks The facilitator settles on **Base**, **Ethereum**, **Avalanche**, and **HyperEVM**. Most builders use Base for the lowest cost and sponsored gas. You choose the network per route with the `network` field. ## Non-custodial settlement Funds settle directly to the `payTo` address you configure. There is no Parallel account, no holding period, and no withdrawal step — the protocol is non-custodial and Cooper Labs never holds your funds. ## Next steps * [Quickstart](/agents/x402/quickstart) * [API reference](/agents/x402/api-reference) * [Verify vs settle](/agents/x402/verify-vs-settle) # The verify / settle flow x402 payments settle in two phases: an off-chain **verify** before your handler runs, and an on-chain **settle** after it succeeds. This is what makes the payment safe — the agent is only charged when it actually receives a successful response. ## Sequence ``` Agent Merchant (the SDK) Facilitator | | | |── GET /api/data ──────────────>| | | | (route matches, no payment) | |<─ 402 + payment-required ──────| | | (base64 PaymentRequired) | | | | | | [agent signs authorization] | | | | | |── GET /api/data ──────────────>| | | payment-signature: |── POST /x402/verify ───────>| | |<─ { isValid: true } ────────| | | | | | [your handler runs] | | | | | |── POST /x402/settle ───────>| | |<─ { txHash, route, ... } ───| | | | |<─ 200 + payment-response ──────| | | (base64 settlement proof) | | ``` ## Guarantees * **The handler only runs after the signature is verified.** A request with a missing or invalid payment never reaches your code — it gets a `402`. * **Settlement happens after a 2xx.** The on-chain transfer is submitted only once your handler returns a success response. If your handler errors, nothing is charged. * **A failed settlement discards the response.** If the on-chain transfer reverts or the facilitator times out, the middleware returns `402` instead of your handler's output, so the agent can retry. * **CORS preflight passes through.** `OPTIONS` requests are never challenged. ## Headers involved | Phase | Header | Direction | |---|---|---| | Challenge | `payment-required` | server → client (on `402`) | | Payment | `payment-signature` (or `X-PAYMENT`) | client → server | | Receipt | `payment-response` | server → client (on `200`) | All three carry base64-encoded payloads. The full shapes are documented in [Schemas](/agents/x402/schemas). # API reference Reference for the `@parallel-protocol/x402` package: configuration, framework adapters, and the lower-level facilitator client. ## Configuration ### `PaymentMiddlewareConfig` ```ts interface PaymentMiddlewareConfig { facilitator: FacilitatorConfig; routes: Record; } ``` ### `FacilitatorConfig` | Field | Type | Required | Description | |---|---|---|---| | `url` | `string` | Yes | Base URL of the Parallel facilitator. The SDK appends `/x402/verify` and `/x402/settle` to this value. | | `apiKey` | `string` | No | Reserved for future use. Sent as an `X-API-Key` header when provided; not currently enforced. | ### `RouteConfig` | Field | Type | Required | Description | |---|---|---|---| | `price` | `string \| bigint` | Yes | Amount required. A string like `"0.01"` is parsed at `decimals` precision. Pass a `bigint` to skip parsing. | | `decimals` | `number` | No | Token decimals for string-price parsing. Default `18` (USDp). Use `6` for USDC-denominated prices. | | `network` | `string` | Yes | Chain slug: `"ethereum"`, `"base"`, `"avalanche"`, or `"hyperevm"`. | | `payTo` | `Address` | Yes | The merchant's receiving address. | | `acceptedTokens` | `Address[]` | No | Token addresses the route accepts. Defaults to the supported stablecoins for the network. | | `description` | `string` | No | Human-readable description of the resource, included in the `402` body. | Route matching is **longest-prefix-wins**: `/api/v1/users` matches a `/api/v1` config before a `/api` one. ## Framework adapters | Import path | Export | Framework | |---|---|---| | `@parallel-protocol/x402/express` | `paymentMiddleware(config)` | Express 4 / 5 | | `@parallel-protocol/x402/next` | `withPayment(config, handler)` | Next.js 14 / 15 | | `@parallel-protocol/x402/fastify` | `paymentMiddleware(config)` | Fastify 4 / 5 | | `@parallel-protocol/x402/hono` | `paymentMiddleware(config)` | Hono 4+ | See the [quickstart](/agents/x402/quickstart) for a working example of each. ## `FacilitatorClient` Low-level client for the facilitator's x402 endpoints. Use it directly if you are building a custom integration rather than using a framework adapter. ```ts import { FacilitatorClient } from "@parallel-protocol/x402"; const client = new FacilitatorClient({ url: "https://facilitator.parallel.best" }); // Phase 1: verify signature + reserve nonce (no on-chain tx) await client.verify(paymentHeader, paymentRequirements); // Phase 2: submit on-chain, return the settlement result const result = await client.settle(paymentHeader, paymentRequirements); if (result.success) { console.log(result.txHash, result.route, result.gasSponsored); } else { console.error(result.error.code); } ``` Both methods use a 10-second timeout. `verify` throws an [`X402RuntimeError`](/agents/x402/error-codes) on any failure; `settle` returns a result union on facilitator errors and throws only on connectivity issues. ## `createPaymentGate` For frameworks not covered by an adapter, the lower-level `createPaymentGate` exposes the verify step without running your handler: ```ts import { createPaymentGate } from "@parallel-protocol/x402"; const gate = createPaymentGate(config); const result = await gate({ getHeader: (name) => request.headers[name], getMethod: () => request.method, getPath: () => request.path, getUrl: () => request.url, }); if (result.type === "pass") { // route not configured for payment — proceed normally } else if (result.type === "error") { // send 402: result.result.status / headers / body } else { // result.type === "verified" — run your handler, then: const handlerStatus = await runHandler(); if (handlerStatus >= 200 && handlerStatus < 300) { const settlement = await result.settle(); } } ``` Use `createPaymentMiddleware` instead if you want the full verify → run → settle flow managed for you. ## Utilities | Function | Signature | Description | |---|---|---| | `parsePrice` | `(price, decimals?) => bigint` | `"0.01"` → `10000000000000000n` (18 decimals default) | | `validateAddress` | `(address) => boolean` | Checks `0x` + 40 hex chars | | `toEip155Network` | `(network) => string` | `"base"` → `"eip155:8453"` | | `encodeBase64` | `(obj) => string` | `JSON.stringify` → base64 | ## See also * [Schemas](/agents/x402/schemas) — wire formats for the payment headers * [Error codes](/agents/x402/error-codes) — SDK and facilitator errors # Payment schemas The three x402 headers each carry a base64-encoded JSON payload. These are the shapes the middleware and the facilitator exchange. ## `402` response — `payment-required` Returned when no valid payment is present. The `payment-required` header holds a base64-encoded `PaymentRequired` object: ```ts interface PaymentRequired { x402Version: 2; error?: string; // present on re-challenge, e.g. "INVALID_SIGNATURE" resource: { url: string; description?: string; mimeType: "application/json"; }; accepts: Array<{ scheme: "exact"; network: string; // EIP-155, e.g. "eip155:8453" asset: string; // token address amount: string; // wei string (18 decimals for USDp) payTo: string; maxTimeoutSeconds: 300; extra: Record; }>; } ``` ## Request header — `payment-signature` The agent attaches a `payment-signature` (or `X-PAYMENT`) header with a base64-encoded signed payload: ```ts const signedPayload = { scheme: "exact", network: "base", method: "transferWithAuthorization", payload: { signature: "0x...", authorization: { from: "0xAgentAddress", to: "0xMerchantAddress", value: "10000000000000000", // 0.01 USDp in wei validAfter: "0", validBefore: "1234567890", // Unix timestamp nonce: "0x...", }, }, }; const header = Buffer.from(JSON.stringify(signedPayload)).toString("base64"); ``` Agent-side signing helpers (EIP-3009 authorizations, EIP-712 signing) live in the `@parallel-protocol/payment-core` package. ## `200` response — `payment-response` On success, the middleware sets a `payment-response` header with a base64-encoded settlement confirmation: ```ts interface PaymentConfirmation { success: true; txHash: string; route: string; // internal settlement route id chain: string; // "base" gasSponsored: boolean; networkId: string; // "eip155:8453" } ``` The middleware sets `access-control-expose-headers` automatically so browser clients can read `payment-response`. # Error codes ## Thrown by the SDK | Error class | When | |---|---| | `X402ConfigError` | Invalid config at middleware setup — bad `payTo`, an unknown network with no `acceptedTokens`, or a malformed facilitator URL. | | `X402RuntimeError` | A runtime failure. The specific cause is in `.code` (below). | ### `X402RuntimeError.code` | Code | Meaning | |---|---| | `FACILITATOR_UNAVAILABLE` | The facilitator timed out (10s) or returned a non-JSON error. | | `FACILITATOR_INVALID_RESPONSE` | The facilitator returned an unexpected response shape. | | `INVALID_PAYMENT` | The `payment-signature` / `X-PAYMENT` header could not be base64-decoded. | ## Propagated from the facilitator When the facilitator rejects a payment, its error code is forwarded as the `error` field on the re-issued `402` body. Common values: | Code | Meaning | |---|---| | `INVALID_SIGNATURE` | Signature recovery failed. | | `INVALID_NONCE` | Nonce already used (replay detected). | | `PAYMENT_EXPIRED` | The authorization's `validBefore` has passed. | | `INSUFFICIENT_AMOUNT` | The signed amount is less than the required amount. | | `NETWORK_MISMATCH` | The payload's chain does not match the route's configured chain. | | `RATE_LIMIT_EXCEEDED` | The signer has exceeded the hourly transaction limit. | ## Handling errors A rejected payment is not an exception in your handler — the middleware re-issues a `402` with the `error` field set, and the agent can sign a corrected payment and retry. You only need to catch `X402RuntimeError` if you are calling the [`FacilitatorClient`](/agents/x402/api-reference#facilitatorclient) or [`createPaymentGate`](/agents/x402/api-reference) directly. # Self-host the facilitator The Parallel x402 facilitator is open source and MIT licensed. You can run your own instance and point your middleware at it instead of the hosted facilitator — your traffic is never gated by Cooper Labs. ```ts paymentMiddleware({ facilitator: { url: "https://your-facilitator.example.com" }, routes: { /* ... */ }, }); ``` :::info Full self-hosting instructions — the facilitator repository, container image, and required environment (RPC endpoints, relayer wallet, database) — are being finalized and will be published here. Need them now? [Ask in #builders on Discord](https://discord.gg/vuuAVAxpcF) and we'll get you set up. ::: # Webhooks Webhook delivery for merchants is planned for **V1.1 (Q3 2026)**. Until then, you can confirm payments in two ways: * **Read the `payment-response` header** on the successful response — it contains the on-chain `txHash` and settlement details ([schema](/agents/x402/schemas)). * **Watch your `payTo` wallet on-chain** for incoming transfers. When webhooks ship, this page will document the event types, payload format, and signature verification. # Migrate from Coinbase x402 to Parallel If you already use the Coinbase x402 facilitator, switching to Parallel is a one-line change. x402 is a standard — your routes, your pricing, and your existing agent clients keep working. ## The change ```diff - import { paymentMiddleware } from 'x402-express'; + import { paymentMiddleware } from '@parallel-protocol/x402/express'; app.use(paymentMiddleware({ - facilitator: { url: 'https://x402.org/facilitator' }, + facilitator: { url: 'https://facilitator.parallel.best' }, routes: { /* ... */ }, })); ``` That's it. Agents paying in USDC keep paying in USDC. Agents holding USDp can now pay you natively, with the facilitator handling conversion at no extra fee. ## What you gain * **Zero conversion fees** when the agent holds one stablecoin and you accept another. * **Gas sponsored on L2** — Base, Arbitrum, HyperEVM, and Avalanche. * **More stablecoins accepted** — USDp, USDC, and other major stables. * **Same x402 standard** — no API change, no breaking change, no agent migration required. ## What stays the same * Your handler signatures. * Your pricing configuration. * Your existing agent clients. * Your wallet address — funds still settle directly to it. ## Comparison | | Coinbase x402 | **Parallel x402** | |---|---|---| | Stablecoins accepted | USDC only | **USDC, USDp, and other major stables** | | Conversion fee | — | **0%** | | Gas on L2 | Standard | **Sponsored** | | Settles to | Your wallet | **Your wallet** | | Standard | x402 | **x402 (compatible)** | ## FAQ **Do I lose access to USDC payments?** No. USDC is fully supported. **Do I need to update my agent clients?** No. x402 is a standard — agents using the Coinbase facilitator on the other side keep working transparently. **Can I run both facilitators in parallel?** Yes. Some merchants A/B test by routing a percentage of traffic to each. # Frequently asked questions # User Guides Parallel is a protocol running on 16 blockchains. This means that you need a wallet to use the protocol. ### Where to start using Parallel ? Everything you need to know to use the protocol can be found below. * [How to Mint USDp?](https://blog.parallel.best/how-to-mint-usdp) * [How to Stake USDp into sUSDp?](https://blog.parallel.best/how-to-stake-usdp-into-susdp) * [How to Bridge Parallel Tokens?](https://blog.parallel.best/how-to-bridge-parallel-tokens) * [How to Stake PRL?](https://blog.parallel.best/how-to-stake-prl) * [How to Migrate to PRL?](https://blog.parallel.best/how-to-migrate-to-prl)