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

With Ethereum shifting to Layer 2-centric scaling solutions, along with 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 interest claims 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, leading to many projects experiencing a price drop at TGE.

With the help of OP Stack, a certain trading platform has launched its own Base Layer 2, while another trading platform has released Ink; utilizing ZK technology, a certain trading platform has introduced XLayer; a certain tech company has launched Soneium, and a communication application has released Kaia, among others. Nowadays, the capital and technical barriers for building a chain have been greatly reduced, and the monthly cost of operating a chain based on OP Stack is approximately $10,000.

The future will undoubtedly be an era of coexistence of multiple chains. Although these Layer 2 chains may choose EVM compatibility to achieve 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 multiple chains is inevitable, interoperability is an area that must be explored and addressed. There are currently many liquidity solutions, such as chain abstraction, intent, Clearing Execution, Native CrossChain, and 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:

The application layer is the layer that users interact with directly, and it is also the most abstract layer in 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.

The permission layer is located below the application layer, where users connect their wallets to the dApp and request quotes to fulfill their trading intentions. Here, "intent" refers to the user's expected final trading outcome, rather than the specific execution path of the trade.

Account management and abstraction layers require an account management and abstraction system that adapts to different chains due to the existence of a multi-chain environment, in order to maintain the unique account structures of various chains. A certain platform is a representative project in this field, which has built a trusted account system that does not require inter-chain consensus, only the trusted commitments between existing account systems. This platform 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 mainly integrates existing public chains.

The Solver layer is responsible for receiving and implementing user trading intentions, with the Solver role competing here 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 intentions. Derivatives of such intentions, such as the Predicate component, can realize user intentions under specific rules.

The settlement layer is the middleware layer used by the solving layer to implement user intentions. Core components of liquidity and state decentralization solutions include:

• Oracle: Used to obtain state information from other chains.
• Cross-Chain Bridge: Responsible for the transmission of information and liquidity across chains.
• Confirm the plan in advance: Shorten cross-chain confirmation time.
• Data availability: Providing accessibility to data.

In addition, it is necessary to consider factors such as inter-chain liquidity, finality, and Layer 2 proof mechanisms 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 on RaaS: Similar to Rollup solutions like OP Stack, it assists in building Rollups on OP Stack by adding specific shared sequencers and cross-chain bridges to share liquidity and state. This aims to solve the decentralization of liquidity and state at a higher level. A more detailed aspect of this is the design of standalone 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 resolve liquidity and state decentralization.

3. Centered around the off-chain intent network: that is, the Solver Network, where the core is that users send intents to the Solver network, and the role of the Solver is to compete for quotes, providing the best completion time and trade price. These Solvers can be AI Agents, exchanges, market makers, or even the integration protocols themselves. Although intents can theoretically achieve any level of complex cross-chain operations, sufficient Liquidity Solvers are required for assistance in practice. Furthermore, when encountering some off-chain demands, there is a possibility of fraud by Solvers. If fraud proofs and other measures are introduced, the implementation difficulty of the Solver Network will increase, and the threshold for running Solvers will also rise.

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

5. Centered on on-chain applications: These applications build high liquidity applications by integrating major market makers or third-party applications. Such 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 full-chain liquidity, it will have very great potential. We have also seen many different solutions.

The various abstract or liquidity solutions we listed above, built in different directions, correspond to different levels of this system, which can be understood as an upstream and downstream relationship. However, these solutions are still not atomic-level solutions; the overall liquidity segmentation issue has led to the emergence of many complex derivative problems. Therefore, in terms of interoperability, a wide array of solutions has emerged. However, fundamentally, these still rely 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 segmentation from its own perspective.

A certain project has constructed 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. It is equivalent to the construction end of other applications, but the final liquidity is placed on the liquidity layer of this project. However, the underlying working principles have not yet been disclosed. Currently, this project has secured $6 million in seed round financing.

A certain network has built three core components, namely the Intent compatibility layer, Validity, and the universal settlement layer.

External applications or the intent layer can publish intents to the network, and then the network's Intent compatibility layer can convert external intents into a format recognizable by the protocol Solver, where the standardized format used is the Validity language. The network nodes are responsible for submitting the final results to the universal settlement layer through cross-chain bridges, fast settlement technologies, etc. This project is still in the construction phase and has not disclosed more details about its work. It secured $2.2 million in seed funding in August.

A certain decentralized application enables auction-based price discovery and unidirectional liquidity pools. Its main mission is to provide professional trading firms with efficient inventory management tools and easily connect to core DeFi protocols when settling trades with intent to use. Meanwhile, the application has created a lending market for its lending transactions. This application focuses more on the trades themselves. It is still in the development stage and announced in July that it had secured $1.2 million in Pre-seed funding.

A certain project is built on the Comet BFT consensus protocol. The cross-chain communication it uses is based on Cosmos IBC, making it more native and secure than other cross-chain bridges. It has gone through four rounds of financing.

A certain foundation is a developer of ZK computing power market, ZK co-processors, and Layer 2 on Ethereum, with a team possessing a deep foundation in ZK technology. They proposed the zkSharding solution, which uses ZK technology to horizontally scale the Ethereum mainnet, executing sharding to process transactions in parallel 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 in the execution shards. The consensus protocol used by the validation committee is also Hotstuff, which is common in the latest parallel execution projects. The foundation's L2 has embedded cross-shard communication into the protocol from the very beginning.

The basic idea is to construct an embedded cross-shard communication architecture similar to IBC through a sharded Layer 2 framework, which can solve the problems of liquidity and state dispersion. However, its core idea is not reasonable, because the issue of liquidity dispersion is a multi-chain problem, and what it builds is a single Layer 2. This means that to solve it, all chains need to become a shard of ZK-sharding, which is difficult to achieve.

Ethereum is also working to address the issue of cross-chain liquidity. Currently, a certain Layer 2 and a certain DEX are the first to publicly support a certain standard, which is also based on Intent for cross-chain operations. The core goal is to establish a universal standard for cross-chain operations between L2 and sidechains, standardizing order and settlement interfaces to achieve seamless cross-chain execution. The main core is a Filler, which can also be referred to as the Solver role in chain abstraction for payment on behalf of others. This proposal is jointly constructed by a certain DEX and a certain project and is currently under review by the working group.

Certain Stack, like the aforementioned standards and zkSharding, is a solution for liquidity fragmentation between Layer 2s within Ethereum, addressing it from the architectural, consensus, and application levels. Certain Stack designs a complete multi-Layer 2 solution to solve the issues of information transmission and Sequencer decentralization all at once. When you use this Stack architecture, cross-chain contracts will be automatically deployed, and there will be a Supervisor to challenge and prevent the transmission of false cross-chain information. Currently, several well-known projects are using this Stack architecture.

Among them, a typical example is a certain chain. This chain mainly addresses the issue of fragmented cross-chain liquidity through integration with the Superchain network. This setup facilitates seamless liquidity movement by providing the following features:

Intention-based cross-chain bridge: This bridge supports fast and reliable liquidity transfer between blockchains, allowing users to set intentions, thereby helping the system automatically select the best path for liquidity movement. This approach abstracts away the complexity for users, making cross-chain transactions smoother and faster.

Verification Network: This decentralized node operator network validates cross-chain transactions, providing faster economic finality. Faster finality is crucial for ensuring efficient settlement of cross-chain transactions, thereby minimizing the risk of liquidity fragmentation caused by delayed settlements.

Flashblocks and Verifiable Block Construction: By using Flashblocks, the chain significantly shortens block time, improves the efficiency of liquidity providers, and achieves a more synchronized cross-chain market. Flashblocks help ensure that liquidity is always accessible and reduce the negative impacts caused by block confirmation delays, which can lead to fragmentation of liquidity.

![Research on the Liquidity Fragmentation Issue in the Layer 2 Era](