Liquidity Challenges and Solutions in the Layer 2 Era

After Ethereum shifted to a Layer 2-focused scaling solution, coupled with the rise of tools like RaaS, many public chains have developed rapidly. Numerous entities wish to build their own chains to represent different interest demands and seek higher valuations. However, the surge of public chains has made it difficult for the ecosystem's development to keep pace with the public chains, leading to many projects experiencing a drop in value at the initial token issuance.

With the help of OP Stack, a trading platform has launched its own Base Layer 2, while another trading platform has released Ink; leveraging ZK technology, a trading platform has introduced XLayer; a tech company has launched Soneium, and a communications company has rolled out Kaia, among others. Nowadays, the funding and technical barriers to building a blockchain have been greatly reduced, with the cost of operating a chain based on OP Stack being around $10,000 per month.

The future will undoubtedly be an era of multi-chain coexistence. Although these Layer 2 chains may choose EVM compatibility for interoperability, it is challenging for them to build applications and reach consensus on the same chain due to the large number of downstream applications from the Web2 entities behind them.

The current multi-chain ecosystem has brought a new challenge: liquidity and state dispersion. The existence of multiple chains is inevitable, so interoperability is a field that must be explored and addressed. Currently, there are many liquidity solutions, such as chain abstraction, intent, Clearing Execution, Native CrossChain, ZKSharding, etc., but their core essence is the same.

We use the industry-recognized Cake architecture to introduce the core components of cross-chain abstraction from top to bottom:

Application Layer

This is the layer where users interact directly, and it is also the most abstract layer in liquidity solutions, as it completely abstracts the details of liquidity conversion. In the application layer, users interact with the front-end interface and may not fully understand the underlying liquidity conversion mechanisms.

Permission Layer

Located below the application layer, users connect their wallets to dApps and request quotes to fulfill their trading intentions. Here, "intention" refers to the user's expected final trading result (i.e., output), rather than the specific execution path of the trade.

Key Management and Account Abstraction

Due to the existence of a multi-chain environment, there is a need for an account management and abstraction system that adapts to different chains to maintain the unique account structures of each chain. One project built a trustworthy account system that does not require inter-chain consensus, only the trustworthy commitments between the existing account systems. Another project achieves abstract management by generating multi-chain account wallets for users, greatly optimizing the user experience and reducing the fragmentation of UX. However, in terms of liquidity, it mainly integrates existing public chains.

Solver Layer

This layer is responsible for receiving and fulfilling users' trading intentions, where the Solver role competes to provide a better user experience, including faster transaction times and execution speeds. Based on this, various intention-driven solutions have been built for intention-based projects. Derivatives of such intentions, such as the Predicate component, can realize user intentions under specific rules.

Settlement Layer

This is the middleware layer used to achieve user intent at the Layer 2 level. The core components of liquidity and state decentralization solutions include:

• Oracle: Used to obtain state information from other chains.
• Cross-chain Bridges: Responsible for the transfer of information and liquidity across chains.
• Pre-Confirmation: Shorten cross-chain confirmation time.
• Data Availability (DA): The accessibility of provided data.

In addition, factors such as inter-chain liquidity, finality, and Layer 2 proof mechanisms need to be considered to ensure the efficient operation of the entire multi-chain system.

Currently, there are various solutions on the market to address liquidity fragmentation, mainly including:

1. Centered on RaaS: Assist in sharing liquidity and state of Rollups built on the OP Stack by joining specific shared sequencers and cross-chain bridges.

2. Account-Centric: Build a full-chain account wallet that supports signing and executing transactions across multiple blockchain protocols through "chain signature" technology.

3. Centered on the off-chain intent network: Users send intents to the Solver network, which competes for bids and provides the optimal completion time and transaction price.

4. Centered on the on-chain liquidity network: Build a liquidity layer on which applications are built to share the full-chain liquidity.

5. Application-centric: Build high Liquidity applications by integrating large market makers or third-party applications.

Solving liquidity issues is a very important proposition. In the financial world, liquidity often represents everything. If a platform that integrates liquidity can be built, especially one that consolidates scattered liquidity across the entire chain, it would have tremendous potential.

Some typical chain abstraction concept projects include:

INFINIT

INFINIT has built a RaaS service for the DeFi space, providing the necessary components for directly building DeFi protocols, such as Oracle, Pool Type, IRM, Asset, etc., and also offering immediately deployable components like Leverage Trading and Yield Strategy.

Khalani Network

Khalani has built three core components: the Intent Compatibility Layer, Validity, and the Universal Settlement Layer. External applications or the intent layer can publish intents to Khalani, and then Khalani's Intent Compatibility Layer can convert external intents into a format that the protocol Solver can recognize.

Liquorice

Liquorice is a decentralized application that enables auction-based price discovery and unilateral liquidity pools. Its main mission is to provide professional trading firms with efficient inventory management tools and to easily connect to core DeFi protocols when settling trades with intent.

Xion

Xion is built on the Comet BFT consensus protocol. Its cross-chain communication is based on Cosmos IBC, making it more native and secure than other cross-chain bridges.

=nil; Foundation

nil is the Ethereum ZK computing power market, ZK co-processor, and Layer 2 developer. It proposed the zkSharding solution, which uses ZK technology to horizontally scale the Ethereum mainnet, execute sharding to parallel process transactions, and generate ZKP.

ERC-7683

This is a proposal to establish a universal standard for cross-chain operations across Layer 2 and sidechains, aiming to standardize order and settlement interfaces for seamless cross-chain execution.

OP Stack

The OP Stack addresses the issues of information transmission and Sequencer decentralization by designing a complete multi Layer 2 solution. When using the OP Stack architecture, cross-chain contracts are automatically deployed, and there is a Supervisor in place to challenge and prevent the transmission of false cross-chain information.

Solving the problem of cross-chain liquidity is a very complex area with many solutions. The future will certainly be multi-chain, and addressing the challenge of liquidity fragmentation is an inevitable task for the industry. There is significant growth potential in the integration of this all-chain liquidity, which could potentially build important infrastructure for the Web3 era.