DOLA protocol is a decentralized omnichain liquidity aggregation protocol with single coin pools of each public chain as the core, cross-chain messaging protocols such as Wormhole, Layerzero as the bridge, and Sui public chain as the settlement center. Each public chain's single coin pool allows users on any chain to provide liquidity to the protocol. The cross-chain messaging protocol is responsible for interconnecting the single coin pools, and Sui public chain acts as the clearing house, bringing security, concurrency, and low fees to the protocol. Based on the DOLA protocol, we will develop a variety of financial applications. We will develop a omnichain lending application based on the omnichain single coin pool, which can meet the deposit and borrowing needs of different chain users. Compared to the Aave Protocol, which provides liquidity for lending on a single chain and borrows third-party cross-chain bridges for cross-chain lending, all lending operations for omnichain lending can be performed on any chain, which greatly increases lending protocol capital utilization and enables users to perform lending operations without perception of the chain. We will develop a new Dex application that differs from traditional AMM by allowing users to provide unilateral liquidity for unilateral market making. The new Dex application allows for efficient cross-chain Swap, low slippage and reduced impermanent losses. Also compared to the Stargate stablecoin cross-chain bridge, the new Dex application allows non-stablecoin cross-chain swaps, further aggregating chain-wide asset liquidity. Based on single-coin pool omnichain lending, we can extend to NFT omnichain lending in one step to meet the demand for collateralized lending of non-homogeneous assets. We can also plug DOLA protcol into the already live OmniSwap and other Web3 applications as a portal for omnichain liquidity. the original intention of DOLA protocol is to build a decentralized omnichain aggregation liquidity protocol that is scalable enough to allow us to introduce omnichain liquidity to different Web3 applications.
Since the rise of Web3 smart contract programming, various public chains have emerged. From the initial Evm-based public chains represented by Ether to the current Move-based public chains represented by Sui and Aptos. This phenomenon has led to a considerable degree of fragmentation of liquidity. Currently, 55% of the liquidity is concentrated in Ether, while the rest is scattered in the rest of the public chains. The fragmented liquidity makes it difficult for users of different public chains to access new public chains. Users are required to find Dex for tokens of the new public chain and use token bridges to swap across chains. Different token bridges have different user interfaces that users need to learn, navigate, and use and are not cheap. Users who own assets on different public chains at the same time have difficulty in finding the right project to earn excess revenue.
In order to solve the above problems, we propose DOLA Protocol, where users with different public chain assets can provide liquidity to the protocol and easily earn higher excess returns. The emergence of new public chains, the easy scalability of DOLA Protocol, provides time guarantee for the first access. Consistent user portal for better operational experience.
The single coin pool is the core of the protocol. The liquidity provided by the user is hosted by the single coin pool. The single-coin pool itself is stateless, and the state of the user is managed by the token pool manager aggregation at the core of the protocol. This approach makes the token pool very simple, brings great scalability, and facilitates rapid access to the protocol by new public chains. At the same time, user operations can be performed separately on different chains, greatly increasing the flexibility of user operations. Users can earn revenue by topping up to the protocol on chain A and withdrawing revenue on chain B. Main features of single coin pool:
- Asset ID: Assets of different public chains have unique IDs in the protocol, and similar assets of different public chains use the same ID for unified management (e.g. USDT on Evm and Optimism)
- User recharge: Allow users to initiate recharge to single pool, which is responsible for encoding user address, asset address and asset quantity, and then completing the protocol load delivery through the bridge to realize user's deposit operation.
- User withdrawals: allows users to initiate withdrawals to the single coin pool, which is responsible for encoding the user address and then completing the delivery of the protocol load through the bridge to achieve the user's withdrawal operation
- User recharge and withdrawal: allow users to complete recharge and withdrawal operations in one transaction, the Swap operation in the Dex application can be regarded as a recharge of T1 assets and withdrawal of T2 assets
Bridge is responsible for receiving messages from single coin pools and completing message transfer using Wormhole, Layerzero cross-chain messaging protocol. The bridge only allows calls from the single pool and the protocol core. The single coin pool receives user access operations and encodes addresses and quantities, providing the protocol with security for user access.
The bridge is an adapter for different cross-chain messaging protocols. In order to achieve the commonality of messages from different public chains, the protocol will develop a unified message specification. The type of the message attributes meet the unified conversion of numeric values to 64-bit integers, addresses to byte types, and other data to byte types. After the bridge receives the single coin pool message to complete the type conversion, it will call a different cross-chain message protocol interface to complete the message transmission.
Sui Clearing House's Pool Manager is a unified manager of single coin pools on different chains, responsible for asset classification and asset liquidity management of single coin pools. The Pool Manager provides a global view of the asset distribution of the pools on different chains. The Single Coin Pool Manager has a dynamic cross-chain fee algorithm that incentivizes the automatic rebalancing of single coin pool popularity by the available and desired liquidity on different chains. If the available liquidity of a single coin pool is lower than the desired liquidity, the cross-chain fee becomes higher. If the available liquidity of a single coin pool is higher than the desired liquidity, the cross-chain fee becomes lower.
Since providers such as USDC exist on multiple chains, the protocol will have USDC single coin pools on different chains. In order to avoid the depletion of the USDC single coin pool of a particular chain, the protocol utilizes a dynamic balancing algorithm to avoid the depletion of single chain liquidity. The purpose of the dynamic balancing algorithm is to maintain a desired distribution ratio for different chains. Suppose the a-chain USDC we expect a proportional distribution of
In order to meet the good characteristics of continuous withdrawal of USDC on the a-chain, the sum of withdrawal USDC remains unchanged, and the withdrawal fee remains unchanged. Calculate the dynamic balance rate calculus, and get the fees charged. In order to reduce the complexity, the fees charged will be allocated to the liquidity replenishers in proportion to
The application manager of Sui Clearing House is responsible for managing the applications supported by the protocol.When Omni Protocol introduces a new application, it needs to obtain permission and assign an application ID through the application manager.Each application in the protocol has a unique ID.Users can select the application they want to use by the application ID to provide liquidity to the protocol, or they can select it automatically based on the protocol recommendation algorithm, allowing Users have low learning cost and good user experience. The application manager is responsible for freezing and taking down applications for emergency situations. The Application Manager is responsible for developing or updating the message repository used by different public chain application layer interfaces.
Governance is one of the most important modules for the sustainability of the protocol. Through decentralized on-chain governance, the protocol can be continuously upgraded and optimized, and bring more benefits to the protocol participants. The governance module adopts the idea of DAOStack, which is co-governed on-chain through governance tokens and reputation system, and the governance scope includes the whole protocol. Early on, the development team will govern by proxy, and after the governance token is issued, it will gradually transition to decentralized governance and eventually be governed entirely by the community. The rules for the issuance of governance tokens will be determined in the near future.
Permissions management involves all permissions for the entire protocol. Permissions related to the single pool manager, which requires the single pool manager to be governed in order to introduce new assets and change the parameters of the dynamic cross-chain fee algorithm. Permissions related to the application manager, which requires the application manager to introduce new applications and freeze applications through governance. Through on-chain governance, the governance token holders can jointly develop and improve the protocol ecology.
The lending protocol, represented by Aave, provides the ability to lend to a few of the most liquid tokens. In a decentralized financial world, Aave offers the good features of no trust and no permission. While decentralized lending has proven to work well over time, there is a large unmet need for current lending protocols. aave only meets the ability to lend to the most liquid assets and needs to be further extended for other assets. aave is a single-chain model. Although cross-chain collateralized lending is achieved through a token bridge, it requires each public chain to deploy the Aave protocol, which is costly and complex for users to operate.
Interest Rate Model
Reserves: In lending agreements, in rare cases the value of a borrower's collateral may be less than the value of its liabilities, in which case the borrower's ability to repay is referred to as insolvency. When an insolvent borrower is liquidated, there will be remaining liabilities that are considered to be bad debt. If bad debts appear to accumulate, lenders may all come at once to withdraw funds to avoid becoming a bad debtor. To mitigate this risk, follow Compound's practice of agreeing to draw down a portion of the interest accumulated into a reserve. If bad debts arise and the reserve is used to make repayments, the lender can avoid becoming the bearer of bad debts as long as the reserve accumulates faster than the bad debts. The percentage of interest withdrawn to become a reserve is called the reserve factor and is noted as
Funding Utilization: Funding Utilization is the ratio of current borrowed funds to supplied funds.
Borrowing rate: Aave and Compound use a static linear interest rate model to determine the borrowing cost of the agreement. Simply put, when the demand for borrowing from the pool increases or the supply decreases, the interest rate increases, while when the supply increases or the demand for borrowing decreases, the interest rate decreases.
Liquidity Rate: The liquidity rate is the interest rate at which a lender should receive interest for providing a loan, funded by the borrowing rate, expressed as
Cumulative Debit Index: indicates the cumulative index of interest payable by the borrower as time accumulates.
Cumulative Liquidity Index: Indicates the cumulative index of interest due to the lender as time accumulates.
The interest rate model refers to the current established practice of Aave and Compound for interest rate modeling, with the difference that the interest earned on the reserve factor
Rights-based tokens (oToken)
The entitlement token oToken is a derivative token received by the depositor after making a deposit. The entitlement token oToken is automatically accumulated as
User Deposit：
User Withdraw：
Debt-enabled token (dToken)
The debtification token dToken is the debt incurred by the borrower to borrow money. The debtification token dToken automatically accumulates as
User Borrow：
User Repay：
Oracle price
We will use suppliers such as Pyth to provide on-chain price, and the price they provide is the average
Liquidation
Liquidation is when the value of a user's liabilities and collateral are less than the agreed upon over-collateralization requirements, and the user's collateral is liquidated to pay off the user's liabilities.
Health Factor: Different from aave, it only considers the risk of bad debts caused by the decrease of the value of the user's collateral. The agreement also considers the risk caused by the rise in the value of liabilities, which can be resisted by increasing the value of liabilities by
Liquidation cost: The process of liquidation is that the liquidator buys debt assets from the outside, and the liquidator obtains collateral of equivalent value at a certain discount. Liquidators need to bear certain price fluctuation risks. In order to solve this problem, on the one hand, the agreement encourages those who contribute a lot to the agreement's liquidity to act as liquidators, and will have a higher discount. On the other hand, a special liquidation pool can be established. When liquidation occurs, the liquidation pool can be directly used for liquidation, and the liquidation pool can be used to share the risk of price fluctuations.
Liquidation Discount: Base Discount
Soft Liquidation: In aave, the debt liquidated by the liquidator in one lump sum is fixed, currently 0.5, that is, the liquidator allows the liquidator to settle half of the debt in one lump sum. The disadvantage of this approach is that it is excessive and unfair to liquidate half the debt if a smaller liquidation can restore it to health. We use soft liquidation, and the maximum amount of liquidation depends on the solution of the following equation. Where, the target health factor
Equation:
Solve：
To solve
Isolated Assets
When new assets are listed, the entire liquidity pool is exposed, which means that users using newly collateralized assets may borrow the entire available liquidity. This significantly limits the ability of the protocol to add new assets, as each new asset increases liquidity and solvency risk. The protocol solves this problem through isolation mode.
Assets that have no supply in the protocol can be set as isolated assets through governance. Isolated assets can be set to normal assets through governance at any time. Isolated assets have a specific debt ceiling. Borrowers using isolated assets as collateral can only use that specific asset as collateral and cannot activate any other assets (including other isolated assets). Isolated assets can only lend stablecoin assets. Enter isolated mode by setting isolated assets as collateral. Exit isolated mode by prohibiting isolated assets from being used as collateral.
PMM is the active market maker algorithm, derived from the DODO protocol. Compared to traditional AMM, PMM allows users to make unilateral withdrawals, which fits very well with the omnichain single-coin pool of our protocol. By building PMM on top of the omnichain single-coin pool to form a new Dex application, users will have lower slippage and market makers will have lower unearned losses. Inevitably, PMM introduces higher algorithmic complexity, but the algorithmic logic built on top of Sui will effectively reduce additional fee consumption.
Marginal Price
The marginal price
As can be seen from the marginal price formula, when k is 0, the marginal price is constantly equal to the market price offered by the prophecy machine, with no slippage and high capital utilization. k is 1, degenerating to the traditional AMM, where both assets must be charged in proportion to the current price, with high slippage and low capital utilization. When the number of assets
Average price
The average price P is obtained by integrating the marginal price with the following formula, which gives the number of tokens a trader needs to pay to buy or sell a certain number of base tokens and quote tokens.
Regression target
Market makers top up base token when
Overall, the new Dex application uses the PMM algorithm to allow users to top up assets on any public chain for unilateral market making. Also the flexible parameter configuration leads to lower slippage, less impermanent losses, and a better user experience.
NFT lending, refers to borrowers going to lend cryptocurrency by using their NFT as collateral on the platform, with the lender or platform providing liquidity for the borrower. there are currently three main models for NFT lending, which are peer-to-peer, peer-to-peer pool and collateralized debt position. In the peer-to-peer NFT lending model, borrowers and lenders are matched directly, with borrowers applying for loans for a certain period of time and lenders offering different interest rate terms, with the borrower ultimately choosing the interest rate terms to complete the lending; in the peer-to-peer pool NFT lending model, users can pledge their NFT portfolios and receive other tokens such as USDT at variable interest rates, which is similar to Compound lending; in the collateralized debt position NTF lending model, users can mint stable coins after pledging a class of NFT collateral to create a vault, this model is derived from MakerDAO and is implemented in basically the same way. Currently NFT lending, NFTfi, BendDAO and X2Y2 occupy the vast majority of the market. Among them, NFTfi and X2Y2 are peer-to-peer lending models, and BendDAO is a peer-to-pool lending model. Peer-to-peer and peer-to-pool lending are derived from homogenized token lending and have many similarities. The difference lies in the uniqueness of NFTs, where the value of NFTs of the same type is different and more complex usage scenarios need to be considered.
Peer-to-Peer Model
Peer-to-peer model is for the NFT listed on the platform, the borrower to set the amount, term, APR, etc. on their own, after the lender and borrower agree, to conclude the transaction. The advantage of the peer-to-peer model is that it supports low liquidity assets and long-tail assets, while the disadvantage is that it has low capital utilization.
Peer-to-Pool Model
The peer-to-peer pool model is where the borrower borrows from a pool and the lender deposits funds into the pool in advance to receive the proceeds. There are three main entities in the peer-to-peer pool model: the borrower, the platform and the lender, with the platform acting as a lending reservoir and as a counterparty to the borrower and the lender. As the borrower, the appropriate NFTs are bundled into a unique NFT through the platform as a single unit of collateral and unavailable for any interaction. The cryptocurrency is then lent from the lending pool based on the floor price of the underlying and the collateral ratio set by the platform; the lender earns interest by depositing the cryptocurrency into the lending pool to provide liquidity. Liquidation is triggered when the borrower's health factor falls below 1 due to a significant drop in the floor price of the underlying. The advantages of peer-to-peer pooling are time efficiency and risk diversification through pooling, while the disadvantages are that it is not conducive to low liquidity assets and long-tail assets, and also suffers from poor capital utilization.
DOLA Protocol will support both peer-to-peer model and peer-to-pool model for omnichain NFT lending. By fusing the advantages of both models, users will have more options to support long-tail assets while bringing higher time efficiency.
OmniSwap is a one-click cross-chain Swap by aggregating liquidity across public chains. OmniSwap brings users a better Swap experience by effectively combining Dex and token bridges from different public chains to find the best route. At present, OmniSwap is already online to support EVM public chain led by Ether and Aptos public chain, using Stargate and Wormhole token bridges to combine Dex of different public chains to achieve one-click Swap.
The current OmniSwap is an effective improvement to the single-chain Swap. However, fusing OmniSwap into DOLA Protocol can have higher capital efficiency. By using the Dex application built with PMM, most of the cross-chain Swap is done within the protocol, and the advantage of PMM algorithm can be effectively used to bring lower slippage and lower gas operating experience to users.
The Web3 world is always evolving and changing day by day. Financial and non-financial Web3 applications are popping up all over the place. DOLA Protocol will leave enough room for expansion to meet the interfacing needs of these Web3 projects. By introducing these Web3 applications into DOLA Protocol, project parties can effectively access the user and capital liquidity of each public chain and promote the development of Web3 projects. Users have more choices and discover more value and fun.
Application messages are independent for different applications and need to be encoded by the application layer to be passed to the liquidity pool. Application messages are decoded and encoded by different application-defined messages, and with Sui protocol core to make application messages go to their respective corresponding settlement logic.
Liquidity pool messages mainly contain asset-related user addresses, asset addresses, asset quantities, etc. The liquidity pool messages are encoded in a uniform format on top of the application messages and eventually go into the bridge. This approach is to unify the management of the protocol assets and secure the protocol funds.
There are different cross-chain protocol messages for different cross-chain messaging protocols. Cross-chain protocol messages are the last layer of the messaging layer and contain application messages and liquidity pool messages, which are packaged and eventually propagated between bridges via cross-chain messaging protocols.
There are three parts to the protocol contract, which are the single coin pool, the message protocol bridge, and the protocol core.
The single coin pool needs to provide an external interface for recharging, and an interface for withdrawals to the messaging protocol bridge, and to package messages from the application before sending them to the bridge.
Message protocol bridges need to be compatible according to the accessed message protocols and are only responsible for the delivery of messages.
The protocol core is divided into 3 parts, which are message processing, application logic and governance. The first part is message processing, which is mainly responsible for decoding and distributing messages to the corresponding application logic contracts, and also responsible for coding messages from different applications to the message bridge; the second part is application logic, each application logic corresponds to the corresponding application messages, and updates the protocol user information and single coin pool accordingly; the third part is governance, which needs to control and manage the protocol global The third part is governance, which needs to control and manage the permissions of the protocol globally, including the authorization of Bridge, the addition of message types and the setting of application permissions.
The Chainwide Liquidity Protocol is an extensible protocol designed to aggregate liquidity from all chains and make it available to applications. Applications can use liquidity from any chain through the protocol. For developers, building applications on the upper layer of the protocol allows developers to spend more energy on application innovation and no longer need to focus on the chain and the lack of liquidity, which greatly reduces the threshold for developers and gives more opportunities for individual developers; for liquidity providers who want to earn coins, they have a unified portal for providing liquidity and no longer need to go to learn for each application, which greatly reduces This greatly reduces the learning cost for users and lowers the threshold for adding liquidity. For users, they have a chain-wide future because protocol-based applications are chain-wide and can be used to interact with applications on any chain without the need to exchange tokens on a chain to be able to use applications on that chain. I believe that the future of Web3 users must not be difficult to use Web3 applications, only need to be on an application should be able to operate most of the DeFi applications, and eventually do Web2 users are Web3 users. The future of the omnichain mobility protocol is the core of Web3, where most of Web3's money and applications are gathered, and is the foundation of the Web3 financial system.
The OmniChain Liquidity Protocol provides a way to aggregate liquidity for applications, while also giving applications the opportunity to use OmniChain Liquidity. Applications built on the protocol will naturally aggregate liquidity and will be able to use omnichain liquidity in a natural way. Current DeFi applications are still mainly developed on their own chains, and even if there is cross-chain, the effect is not very big, and the liquidity is mainly aggregated on the original chain. And it is difficult for each team to develop on other chains, both in terms of development and resources, because there is no unified protocol to support them. If we compare DeFi applications to companies and chains to countries, then the whole-chain liquidity protocol is the basis for economic globalization, and applications can better develop on the whole chain through our whole-chain liquidity protocol instead of being stuck on one chain. The OmniChain Liquidity Protocol unifies the liquidity pool through an appropriate design, provides chain-wide operational convenience for various DeFi applications such as lending and borrowing, and solves the current dilemma of silos between chains. It has taken a solid step in the all-chain era and laid a good foundation for the development of the all-chain era.