Composability between Ethereum Layer 1 and 2 – Loopring Protocol

By depending on the operator we can close the gap between the onchain and offchain world for any kind of interaction in a trustless way. The only drawback of this solution is the necessity of the operator to store enough funds in his onchain wallet so he can front the necessary assets onchain. This is not capital efficient — unless the incremental trading volume it allows by these services outweighs the capital’s (opportunity) cost. Further, funds can be moved between the operator’s onchain and offchain wallet quite quickly (5 to 10 minutes), so the total amount of funds needed by the operator can be relatively low to support a high amount of economic activity traveling across. Note that solutions like this were already proposed by Gnosis and Starkware, just to name a few.

The design space for these solutions is constrained by quite strict limits in all layer 2 solutions. ZK rollup is actually the best layer 2 solution for schemes like this because of the fairly short finality times (once the proof is submitted onchain we’re sure the work was done correctly). In optimistic rollup, for example, the finality times are much greater, which greatly increases the capital needed by the operator to provide functionality like this.

ZKP improvements in the form of faster proving times would provide an incremental improvement, but the main problem of indirect state updates would still remain for practical reasons. A different solution to this problem would be if ‘everyone’ builds on a single layer 2 solutions. This should indeed be possible with progress in things like recursive SNARKs. The fluidity would still not necessarily be trivial, but solutions would almost certainly arise. If dapps, protocols, and other legos do go to layer 2, but in siloed solutions, the situation would not get easier, and likely more difficult.

As an example of who these other puzzle pieces can be in Loopring’s context — besides just an everyday user — think of DEX aggregators, and margin/lending protocols. Both these instances can cut both ways: wanting to pull/source liquidity from a Loopring exchange, and push/supply liquidity to a Loopring exchange.

DEX Aggregators have seen a strong surge in popularity over the past 6 months, with dapps such as 1inch, DEX.AG, Paraswap, and Totle offering swappers the best prices by aggregating liquidity and routing to the best rate. Right now they aggregate onchain sources (Uniswap, Kyber) but want to be able to source liquidity from layer 2 venues, such as a Loopring DEX. [Especially if layer 2 performance allows for spreads to compress, thus hosting the most competitive prices]. Conversely, a Loopring DEX may want to aggregate/include liquidity from these onchain sources as well, to bootstrap/supplement their order book’s liquidity.

Margin/lending protocols are an important building block in open finance, allowing lenders to earn interest, and borrowers to access credit (and notably, margin trade). Similarly to the case with DEX aggregators, the protocols, such as bZx for example, would like to be able to pull from Loopring liquidity to fill their order objects’ needs when a user initiates a position. And again, Loopring would like their exchange users to access some of these protocols seamlessly & trustlessly from with their Loopring exchange accounts. A nice solution/workaround to this latter case is when the protocol’s output is a token itself, such as a ‘position token’, which can trivially be listed on a Loopring exchange as it is just an ERC20.

As a slight aside, composability can also be implemented “in bulk” for users of a specific Loopring exchange, or across the entire protocol. For example, users’ funds locked into the exchange protocol can be used collectively for certain DeFi opportunities. A DAO may be setup to manage the deposited funds, and vote to deploy these assets in a lending protocol, or for staking in some other network, etc. Indeed, such a Loopring DAO will exist, and besides these DeFi decisions, will govern certain protocol parameters at large.