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

With Ethereum's shift towards Layer 2-centric scaling solutions and the rise of tools like RaaS, a large number of public chains are developing rapidly. 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 ecosystem's development to keep pace with the public chains, resulting in many projects experiencing a drop in value at their 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 certain platform has introduced XLayer; Sony has released Soneium, and LINE has launched Kaia, among others. Today, the capital and technical barriers to building a chain have been significantly reduced, with the monthly cost of operating a chain based on OP Stack being around 10,000 USD.

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

The current multi-chain ecosystem presents a new challenge: liquidity and state dispersion. Given that the existence of multi-chain is inevitable, interoperability is an area that must be explored and solved. Currently, there are many liquidity solutions, such as chain abstraction, intentions, Clearing Execution, Native CrossChain, ZKSharding, 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 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 dApps and request quotes to fulfill their trading intentions. Here, "intention" refers to the 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. 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 trusted account system without the need to establish inter-chain consensus, relying solely on trusted commitments between existing account systems. Near Account achieves abstract management by generating multi-chain account wallets for users, greatly optimizing the user experience and reducing UX fragmentation. However, in terms of liquidity, it mainly integrates existing public chains.

Solver Layer

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

Settlement Layer

This is the middleware layer used to solve the layer to realize user intentions. The core components of the solutions for Liquidity and state decentralization 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.

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 these few methods:

1. Centered around RaaS: Similar to Rollup solutions like OP Stack, this approach introduces specific shared sequencers and cross-chain bridges to assist in sharing liquidity and states for Rollups built on OP Stack. This aims to address the decentralization of liquidity and states at a higher-level direction. A more specific aspect here is the separate design of shared sequencers, which is more targeted towards 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 problems of Liquidity and state decentralization.

3. Centered around the off-chain intent network: This refers to the Solver Network in our "Introduction" cake architecture diagram, where the core is that users send intents to the Solver network. The role of the Solver is to compete for quotes, providing the optimal completion time and transaction price. These Solvers can be AI Agents, CEX, Market Makers, or even integrated protocols themselves. Although intents can theoretically achieve cross-chain operations of any complexity, sufficient liquidity Solvers are required for assistance in practical implementation. Additionally, when encountering certain off-chain demands, there is a possibility of fraud with Solvers. If fraud proofs and other measures are introduced, the implementation difficulty of the Solver Network will increase, and the threshold for operating Solvers will also rise.

4. Centered on the on-chain liquidity network: This direction is specifically optimized for cross-chain liquidity issues, but it does not address the problem of dispersed on-chain states in other chains. Its core is to build a liquidity layer, on which applications are built to share full-chain liquidity.

5. Centered around on-chain applications: These applications build high liquidity solutions by integrating large MM or third-party applications. Such projects require managing complex cross-chain processes, which places high demands on developers, making them 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 an integrated liquidity platform, especially one that consolidates fragmented on-chain liquidity, it will have tremendous potential, and we have also seen many different solutions.

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

INFINIT has built a RaaS service in the DeFi space, which can provide the components needed for the direct construction of DeFi protocols, such as Oracle, Pool Type, IRM, Asset, etc. It can also offer immediately usable components like Leverage Trading and Yield Strategy. This is equivalent to other application construction ends, but the final liquidity is placed on Infinit's liquidity layer. However, it has not yet disclosed the underlying working principles.

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 the external intents into a format that the protocol Solver can recognize, using the standardized format known as Validity language. Khalani nodes are responsible for submitting the final results to the universal settlement layer through cross-chain bridges, rapid settlement technologies, and so on.

Liquorice is a decentralized application that enables auction-based price discovery and unilateral liquidity pools. The main mission of Liquorice is to provide professional trading firms with efficient inventory management tools and to easily connect to core DeFi protocols when settling transactions based on usage intent. At the same time, Liquorice has created a lending market for its lending transactions. This application focuses more on the trading itself.

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; The Foundation proposed the zkSharding solution, which uses ZK technology to horizontally scale the Ethereum mainnet, executing sharded parallel processing of transactions and generating 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 projects of parallel execution. =nil; L2 embedded cross-shard communication into the protocol from the very beginning.

Ethereum is also working to address the issue of cross-chain liquidity. Currently, some major trading platforms are the first to publicly support the ERC7683 standard, which also uses an Intent-based cross-chain approach. Its core objective 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 that a Filler can also be considered as the Solver role in chain abstraction for payment.

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 to challenge and prevent the transmission of false cross-chain information.

Solving the problem of cross-chain liquidity is a very complex field with numerous solutions. Layer 2 solutions include embedded cross-chain messaging from Ethereum, especially ERC-7683, as well as Layer 2 solutions like OP that build on the OP Stack to share sequencers. Outside of the Layer 2 context, all Layer 1s also face issues of liquidity, state, and user experience fragmentation. There are dedicated liquidity-centric application solutions, as well as off-chain solutions like Solver Network, and even account-centric solutions like NEAR, which also need to be based on off-chain roles like Solver.

Cross-chain liquidity, state, and user experience fragmentation are problems in the entire blockchain industry. When thinking from a holistic perspective, it is necessary to approach it in a more abstract way, similar to chain abstraction, which is equivalent to being truly