Last year we proposed the concept of EthPort, the purpose of which was to allow users to experience various Layer 1 DeFi products on Loopring Layer 2 in a decentralized manner.
As part of the process to implement this function, we carefully considered its limitations. For one, it would bring additional overhead to the system. Additionally, the reduction in gas costs would only be realized with large and frequent use in specific DeFi transactions, presenting initial liquidity challenges.
Due to these limitations, we redesigned a new solution which I will be covering next. L2 DeFi Port is now live on L2 and we chose ETH 2.0 staking via Lido as the first integrated DeFi product using it.
Before we cover the details of this new DeFi solution, let’s first review the orderbook mechanism of Loopring’s DEX. The matching engine in this architecture diagram is responsible for settling sell orders and buy orders between users. As long as the price matches, the matching engine will execute the settlement in the order of the orders coming in first. A zero-knowledge proof is generated for these settlements and then submitted to Ethereum.
The matching and settlement of two orders is a piece of logic code solidified and realized by the zero-knowledge proof circuit. It can ensure that the entire matching and settlement process is truthfully executed according to the price specified in the user’s order, and that no third party can tamper with that process. With this settlement process in mind, if we regard the user’s desire to participate in a DeFi product on Layer 2 as a buy and sell order, then as long as there is a counterparty order provided by another party, the user can instantly complete the L2 DeFi Port interaction.
Taking ETH 2.0 staking via Lido as an example, Loopring uses its own liquidity to participate in staking with Lido on Ethereum Layer 1, taking the corresponding wstETH and depositing it to Loopring L2. When a user places an order using a Loopring DeFi product in which they want to stake ETH on L2, the matching engine quickly matches a corresponding wstETH sell order, and then completes the mutual exchange of ETH and wstETH after passing the verification of the matching settlement circuit, and vice versa. When a user wants to withdraw from staking, we will provide a counterparty buy order based on the price of wstETH on Ethereum L1, where users can exchange wstETH back to ETH. The whole process is implemented in a decentralized and non-custodial manner.
Loopring’s self-operated liquidity can be regarded as an intermediate bank that deposits and withdraws at any time. When users’ deposits and withdrawals are balanced or have a small deviation, they do not need to have any interaction with L1 at all. When there is a large deviation between funds deposited and withdrawn or if wstETH greatly appreciates in value against ETH, it is necessary to rebalance funds to L2. At this time, it will involve withdrawing some assets to L1, and then depositing back to L2 after the interaction with the DeFi protocol is completed. The entire process of rebalancing funds is currently controlled automatically by smart contracts on Ethereum L1. Loopring’s backend relayer will monitor the balance of the entire fund, triggering the rebalance operation of the smart contract according to preset conditions.
From this process arises another consideration, what happens when there are not enough funds to match for a given order? We can take a real world example of a real bank to understand the process in such cases. When a user wants to withdraw a large amount of funds, such as in a large cash withdrawal, a real bank will require that the transaction be reserved in advance to allow the bank a sufficient amount of time to prepare the funds needed to process the large withdrawal. This mechanism can be entirely adapted to Loopring L2 in a decentralized way. We have introduced a new sufficiently powerful API, called asset locking. In practice, it is not so new.
This locking function is already used by Loopring’s orderbook to accomplish the pending order functionality. The realization of the pending order essentially locks the user assets first (please note that this locking method is also decentralized, and the assets are always on the user’s wallet address). The asset will not be unlocked and the matching settlement will be performed until a matching counterparty order appears.
We took this asset lock function separately and expanded it into a sufficiently general API. Using this API, we can specify how long the asset should be locked, allowing it to be automatically released after expiration. When we detect that L2 assets cannot fully match the user’s DeFi order, we will lock the balance that cannot be redeemed temporarily, and then we will go to L1 as soon as possible to interact with the DeFi protocol to get the remaining part that needs to be redeemed, and then deposit it back to L2 to redeem the full amount. Of course, because this means each user has to be dealt with specially, the associated cost will be higher. The main contributor to the higher cost is that the gas cost cannot be saved by gathering user operations on L2.
Because of the introduction of the asset locking API, two abnormal situations will need to be accounted for: one occurs when the user updates the L2 public and private key pair during the locking period, and the other occurs when the user initiates a forced withdrawal during the locking period. Both will cause the user’s orders previously placed to be unable to be matched and settled. For the first case, the change of the public-private key pair will invalidate all the previously signed orders, so the relayer system will not process the request first when there is a special asset locked; for the second case, due to the protocol requiring forced withdrawals be processed within 2 weeks, if the asset lock expires within 1 week, we will wait until the locked asset expires before processing the forced withdrawal. If the asset lock period exceeds 1 week, it will be forced to unlock.
The above discussion is about the way to access a DeFi protocol on Loopring L2. Turning now to assumptions, one of the assumptions is that the number of tokens corresponding to the DeFi protocol is fixed. For example, the reason why we only support wstETH and not stETH is because wstETH has a constant supply, but the value of wstETH is always rising, whereas the supply of stETH will increase dynamically. If the tokens of a specific DeFi protocol do not have this constant property, we need to provide a wrapped layer of smart contract on Ethereum L1 and interact with the DeFi protocol through this wrapped layer (in a way very similar to the implementation of wstETH). For the access of this kind of DeFi protocol, the overall framework diagram will become slightly different.
In the design of the entire Loopring L2 DeFi access mechanism, a core design concept is that users always control their own assets. For example, the various DeFi protocol tokens obtained by users on L2 can be redeemed at any time on L2. You can also withdraw back to the Ethereum L1 at any time, and then interact with the DeFi protocol by yourself.
With the asset locking API, many scenarios can be implemented on Loopring L2 in a decentralized way. For example, Uptick developed the buy-in, highest-price and Dutch auction mechanism for NFT sales based on the locking API. This locking mechanism may open the door to applications like lending protocols, margin trading, and more, all on Loopring L2. From a technical standpoint, all of these can be implemented. If you have some innovative ideas based on Loopring L2, please contact us and we are very willing to work with you. Let’s work together to build the best application specific zkRollup Layer 2 protocol.
Remember our slogan: Be your own bank!
Loopring is an Ethereum Layer 2 zkRollup protocol for scalable, secure DeFi and NFT applications. Loopring builds non-custodial, high-performance products atop our L2, including the Loopring Wallet — a mobile Ethereum smart wallet, and the Loopring L2 web app — an L2 orderbook and AMM DEX. To learn more, follow us on Medium or see Loopring.org.