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

With Ethereum's shift towards a Layer 2-centric scaling strategy and the rise of tools like RaaS, a large number of public chains are rapidly developing. Many entities hope 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 development of the ecosystem to keep pace with the public chains, resulting in many projects failing at the time of issuance.

With the help of OP Stack, a certain trading platform has launched its own Layer 2; with ZK technology, another trading platform has launched its own Layer; a certain company has released its own chain, and a certain communication software company has launched its own chain, etc. Nowadays, the financial and technical barriers to building a chain have been greatly reduced, and the cost of operating a chain based on OP Stack is about $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 has brought a new challenge: liquidity and state dispersion. Since the existence of multi-chain is inevitable, interoperability is a field that must be explored and solved. Currently, there are many liquidity solutions, such as chain abstraction, intent, Clearing Execution, Native CrossChain, and ZKSharding, but their core essence is fundamentally 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 that users interact with 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 mechanisms.

Permission Layer(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 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, 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. For example, the object-centered account system of SUI is completely different from EVM. Some projects have built trustworthy account systems that do not require inter-chain consensus, only needing trustworthy commitments between existing account systems. Additionally, some projects achieve abstract management by generating multi-chain account wallets for users, greatly optimizing user experience and reducing UX fragmentation. However, in terms of liquidity, it mainly integrates existing public chains.

Solve Layer (Solver Layer)

This 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 intent-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 achieve user intentions in the solution layer. The core components of liquidity and state-distributed solutions include:

• 预言机(Oracle): Used to obtain state information from other chains.
• Cross-Chain Bridge ( Bridges ): Responsible for the transmission 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 solutions, we found that there are mainly a few approaches:

1. Centered on RaaS: Similar to Rollup solutions like OP Stack, which assist in building Rollups on OP Stack by adding specific shared sequencers and cross-chain bridges to share liquidity and state. This hopes to address the decentralization of liquidity and state at a higher level. A more detailed aspect here is the separate design of shared sequencers, which is more targeted at Layer 2 and lacks universality.

2. Account-Centric: 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 multi-chain transactions. This solution, while greatly addressing the issue of UX fragmentation, involves complex backend implementation for developers and does not fundamentally solve the issues of Liquidity and state decentralization.

3. Centered around the off-chain intention network: This refers to the Solver Network in our "Introduction" cake architecture diagram, where the core is that users send intentions to the Solver network. 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 protocols themselves. Although intentions can theoretically achieve arbitrarily complex cross-chain operations, sufficient liquidity Solvers are required for assistance in practical implementation. Additionally, when encountering some off-chain demands, there is a possibility of fraud by Solvers. If fraud-proofing measures are introduced, the implementation difficulty of the Solver Network will increase, and the threshold for operating Solvers will also be higher.

4. Centered on the on-chain liquidity network: This direction specifically optimizes the liquidity issues of cross-chain, but does not address the problem of other on-chain state dispersion. Its core is to construct a liquidity layer, on which applications are built to share the full-chain liquidity.

5. Centered on on-chain applications: These applications build high liquidity applications by integrating large MM or third-party applications, etc. Such projects require managing complex cross-chain processes, which places high demands on developers, making them highly susceptible to hacking incidents.

Solving the liquidity problem is a very important proposition. In the financial world, liquidity often represents everything. If we can build a platform that integrates liquidity, especially by consolidating fragmented on-chain liquidity, it will have tremendous potential, and we have seen many different solutions.

In the above two classifications, we can see that based on the structure of the cake, the Settlement Layer is the most atomic level solution. Above these atomic solutions like cross-chain, oracles, and Pre-Confirmation schemes, there are more abstract layers constructed, namely the Solver Layer, Permission Layer, and Application Layer. The various solutions we listed above, which build abstractions or liquidity solutions in different directions, can be understood as a relationship between upstream and downstream. However, these solutions are still not atomic level solutions, and the entire liquidity fragmentation issue has led to numerous complex derivative problems. Therefore, a wide variety of solutions have emerged for interoperability. But essentially, it still relies on these components.

Solving the problem of cross-chain liquidity is a very complex area with many solutions. For example, Layer 2 solutions can be divided into those that use embedded cross-chain messaging, especially ERC-7683, and the OP Stack built on Layer 2 to share Sequencers. Outside the context of Layer 2, all Layer 1s also face issues of liquidity, state, and user experience fragmentation. There are solutions specifically centered around liquidity applications, as well as off-chain solutions like Solver Network, and even account-centric solutions, but they also need to be based on off-chain roles like Solver.

We recognize that the fragmentation of cross-chain liquidity, state, and user experience is an issue in the entire blockchain industry. If we think about it from a holistic perspective, it requires a more abstract approach, similar to chain abstraction, which is essentially the true entry point to Web3. It addresses the fragmentation in user experience, while integrating liquidity and state in ways that are imperceptible to users. How to specifically integrate this is further divided into the use of off-chain Solver networks and atomic integration of cross-chain bridges and other facilities, which are all worth exploring. Overall, the future will definitely be multi-chain, and addressing the issue of fragmented liquidity is a challenge that the industry must inevitably face. This integration of full-chain liquidity has vast growth potential and could construct a new type of internet entry point for the Web3 era.