Research on the Liquidity Fragmentation Problem in the Layer 2 Era

Since Ethereum has shifted to Layer 2-centric scaling solutions, coupled with the rise of tools like RaaS, a large number of public chains have rapidly developed. Many entities hope to build their own chains to represent different interest demands 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, resulting in many projects experiencing a drop in value at the time of TGE.

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 platform has introduced XLayer; Sony has released Soneium, and LINE has launched Kaia, among others. Today, the funding and technical barriers to building a chain have been significantly lowered, with the operating cost of a chain based on OP Stack being approximately $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 from the Web2 entities behind them.

The current multi-chain ecosystem presents a new challenge: liquidity and state dispersion. As the existence of multi-chain is inevitable, interoperability becomes a field that must be explored and solved. There are currently 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 because 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 mechanism.

Permission Layer (

Located below the application layer, users connect their wallets to the dApp and request quotes to fulfill their trading intentions. Here, "intent" refers to the expected final trading result ), which is the output (, rather than the specific execution path of the trade.

Account Management and Abstraction Layer ) Key Management and Account Abstraction (

Due to the existence of a multi-chain environment, an account management and abstraction system that adapts to different chains is needed to maintain the unique account structures of each chain. For example, SUI's object-centered account system is completely different from EVM. One Balance is a representative project in this field, which builds a trustworthy account system without the need to establish inter-chain consensus, only requiring trustworthy commitments between existing account systems. Near Account achieves abstract management by generating multi-chain account wallets for users, greatly optimizing user experience and reducing UX fragmentation. However, in terms of liquidity, it primarily integrates existing public chains.

Solve Layer )Solver Layer (

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

Settlement Layer)Settlement Layer(

This is the middleware layer used to solve the layer to realize user intentions. The core components of the liquidity and state decentralization solutions include:

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

In addition, factors such as inter-chain liquidity, finality ), Layer 2 proof mechanisms, etc., 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. After reviewing a large number of options, we found that there are mainly these few methods:

1. Centered around RaaS: Similar to Rollup solutions like OP Stack, by incorporating specific shared sequencers and cross-chain bridges to assist in sharing liquidity and state for Rollups built on OP Stack. This aims to address the dispersion of liquidity and state at a higher level. A more detailed aspect here is the design of standalone shared sequencers, which is more targeted at Layer 2 and lacks universality.

2. Account-Centric: Similar to NEAR, build a full-chain account wallet that supports signing and executing transactions across multiple blockchain protocols through a technology called "chain signature." The core component is the MPC network, which replaces users in signing transactions for multiple chains. This solution, while greatly addressing the issue of UX fragmentation, involves complex backend implementations for developers and does not essentially resolve liquidity and state dispersion.

3. Centered on the off-chain intention network: that is, the Solver Network in the "Introduction" cake architecture diagram, the core is that users send intentions to the Solver network, and the Solver role competes for quotes, providing the optimal completion time and transaction price. These Solvers can be AI Agents, CEX, Market Makers, or even the integrated protocol itself. Although intentions can theoretically achieve arbitrarily complex cross-chain operations, in practice, it requires sufficient liquidity Solvers to assist, and when encountering some off-chain demands, there is a possibility of fraud by Solvers. If methods such as fraud proof are introduced, the implementation difficulty of the Solver Network will become higher, and the threshold for operating Solvers will also increase.

4. Centered around on-chain liquidity networks: This direction specifically optimizes the liquidity issues of cross-chain, but does not address the decentralized state issues of other chains. Its core is to build a liquidity layer, on which applications are built to share liquidity across the entire chain.

5. Centered on on-chain applications: These applications build high liquidity applications by integrating large MM or third-party applications. These projects require managing complex cross-chain processes, which places high demands on developers, and thus are also very prone to hacking incidents.

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 fragmented on-chain liquidity, it will have significant potential.

Among the above two classifications, we can see that based on the cake structure, Settlement Layer is the most atomic level solution. Above these atomic solutions such as cross-chain, oracle, and Pre-Confirmation schemes, a more abstract layer is built, which includes Solver Layer, Permission Layer, and Application Layer. The various solutions listed above that build abstract or liquidity solutions in different directions correspond to different levels of this system and can be understood as a relationship between upstream and downstream. However, these solutions are still not atomic-level solutions. The entire liquidity disconnection issue has led to the emergence of many complex derivative problems, and thus, a variety of solutions have emerged for interoperability. Nevertheless, it still fundamentally relies on these components. Next, we will discuss several typical projects of chain abstraction concepts to see how each addresses the liquidity disconnection problem from its own perspective.

(# INFINIT

INFINIT has built a RaaS service for the DeFi sector, which 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. It is equivalent to the construction end of other applications, but the final liquidity is placed in Infinit's Liquidity Layer. However, it has not yet disclosed the underlying working principles.

)# 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 recognizable by the protocol Solver, using the standardized format known as Validity language. The Khalani node is responsible for submitting the final results to the universal settlement layer through cross-chain bridges, rapid settlement technologies, etc. This project is still in the construction phase and has not disclosed more details about the work.

(# 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 to use. At the same time, Liquorice has created a lending market for conducting lending transactions. This application is more focused on the trading itself. It is still in the development stage.

)# Xion

Xion is an upgrade from the Burnt brand. In the past, Burnt focused on consumer application solutions, but the team discovered significant fragmentation issues in on-chain interactions, which led to the development of Xion to address this problem. 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.

![Research on the liquidity fragmentation issue in the Layer 2 era]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###

=nil; Foundation

nil is the ZK computing power market, ZK co-processor, and Layer 2 developer for Ethereum, with a team possessing a strong foundation in ZK technology. They proposed the zkSharding solution, which uses ZK technology to horizontally scale the Ethereum mainnet, execute sharding for parallel processing of transactions, and generate ZKP, while the main shard verifies data, communicates with Ethereum, and synchronizes network status among all validators. The main shard also manages the distribution of validators and accounts within the execution shards. The consensus protocol used by the validation committee is also Hotstuff, which is common in the latest parallel execution projects. =nil; L2 has embedded cross-shard communication into the protocol from the very beginning. Cross-shard messages are validated as transactions by the validator committee of each shard.

The basic idea is to build an embedded cross-shard communication architecture similar to IBC through a sharded Layer 2 architecture, which can solve the problems of liquidity and state dispersion. However, the core idea is unreasonable because the problem of liquidity dispersion is a multi-chain issue, while it constructs a single Layer 2, meaning that to solve it, all chains need to become a shard of ZK-sharding, which is difficult to achieve.

ERC-7683

Ethereum is also working to address the issue of cross-chain liquidity. Currently, multiple platforms are publicly supporting the ERC7683 standard, which is also based on an Intent-based cross-chain method. Its core goal is to establish a universal standard for cross-chain operations across L2 and sidechains, standardizing order and settlement interfaces to achieve seamless cross-chain execution. The main core is a Filler, which can also be described as a Solver role in chain abstraction for payment on behalf of others. This proposal has been co-constructed by two projects and is currently under review by the Cake working group.

OP Stack

OP Stack, ERC-7683, and zkSharding are all solutions within Ethereum aimed at addressing the liquidity fragmentation between Layer 2s, each tackling the issue from the architectural, consensus, and application levels. OP Stack designs a complete multi Layer 2 solution to simultaneously resolve the issues of information transmission and Sequencer decentralization. When you utilize the OP Stack architecture, cross-chain contracts will be automatically deployed, and there will be a Supervisor in place to challenge and prevent the transmission of false cross-chain information. Currently, several well-known projects are using the OP Stack architecture.

Among them, a typical example is Unichain. Unichain mainly operates through