Research on the Liquidity Fragmentation Issue in the Era of Layer 2

With Ethereum shifting to a Layer 2-centric scaling solution and the rise of related tools, a large number of public chains are rapidly developing. Many entities wish to build their own chains to represent different interests and seek higher valuations. However, the emergence of numerous public chains has made it difficult for the ecosystem's development to keep pace with the public chains, leading many projects to face difficulties in their early stages.

With the help of relevant technologies, many well-known enterprises and institutions have launched their own Layer 2 or proprietary chains. Nowadays, the funding and technical thresholds for building a chain have been significantly lowered, with the cost of operating a chain based on a specific tech stack being around $10,000 per month.

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

The current multi-chain ecosystem presents a new challenge: liquidity and state dispersion. As the existence of multi-chains is inevitable, interoperability is a field that must be explored and solved. There are currently many liquidity solutions, such as chain abstraction, intentions, Clearing Execution, Native CrossChain, ZKSharding, etc., but their core essence is the same.

We use the widely 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 the liquidity solutions, as it completely shields the details of liquidity conversion. In the application layer, users interact with the front-end interface, and may not understand the underlying liquidity conversion mechanisms.

Permission Layer

Located below the application layer, users connect their wallets to the dApp 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 transaction.

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 in order to maintain the unique account structures of each chain. Some projects achieve abstract management by building trustworthy account systems or generating multi-chain account wallets for users, greatly optimizing the user experience and reducing the fragmentation of UX.

Solver Layer

The layer is responsible for receiving and implementing the user's trading intentions, where the Solver role competes to provide a better user experience, including faster transaction times and execution speeds. On this basis, some projects have built various intention-driven solutions.

Settlement Layer

This is the middleware layer used to implement user intentions for the solution layer. 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 transmission of information and liquidity across chains.
• Pre-Confirmation: Shorten cross-chain confirmation time.
• Data Availability (DA): Provides accessibility to 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.

Solution

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

1. Technology-centric: Assist in sharing liquidity and state for Rollups built on a specific tech stack by incorporating 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 specific technologies.

3. Centered around the off-chain intent network: Users send intents to the Solver network, and the Solver role competes for quotes, providing the optimal completion time and transaction price.

4. Centered on the on-chain liquidity network: Specifically optimize cross-chain liquidity issues, build a liquidity layer, and develop applications on this layer to share liquidity across the entire chain.

5. Centered on on-chain applications: Build high liquidity applications by integrating major MM or third-party applications.

Solving the liquidity problem is a very important proposition. In the financial world, liquidity often represents everything. If a comprehensive liquidity platform can be built, especially one that integrates scattered on-chain liquidity, it will have great potential.

Next, we will discuss several typical projects of chain abstraction concepts to see how each of them addresses the issue of liquidity fragmentation from their own starting point.

INFINIT

INFINIT has built a service in the DeFi space that can provide the necessary components for directly building DeFi protocols, such as Oracle, Pool Type, IRM, Asset, etc. It can also offer immediately available components like Leverage Trading and Yield Strategy. This is equivalent to the building end of other applications, but the final liquidity is placed in INFINIT's Liquidity Layer.

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. The main mission of Liquorice is to provide efficient inventory management tools for professional trading firms 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 compared to other cross-chain bridges.

=nil; Foundation

nil is the ZK computing power market, ZK co-processor, and Layer 2 developer for Ethereum, proposing the zkSharding solution. This solution uses ZK technology to horizontally scale the Ethereum mainnet, execute sharding for parallel transaction processing, and generate ZKP.

ERC-7683

Ethereum is also working to address the issue of cross-chain liquidity. Currently, some well-known projects have publicly supported the ERC7683 standard, which is also based on an Intent-based cross-chain approach. Its core goal is to establish a universal standard for cross-chain operations across L2s and sidechains, standardizing order and settlement interfaces to achieve seamless cross-chain execution.

OP Stack

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

Summary

Solving the cross-chain liquidity problem is a very complex area with numerous solutions. Different approaches attempt to address the issues of liquidity, state, and user experience fragmentation from various perspectives. The future will definitely be multi-chain, and addressing the issue of fragmented liquidity is an inevitable challenge that the industry must face. This integration of full-chain liquidity has vast development potential and may construct important infrastructure for the Web3 era.