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

With Ethereum shifting towards Layer 2-centric scaling solutions, coupled with the rise of various tools, many public chains are rapidly developing. Numerous entities aspire 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 challenges early on.

With the help of various technologies, several well-known companies and institutions have launched their own Layer 2 or public chains. Nowadays, the funding and technological thresholds for building a chain have been significantly lowered, with the monthly cost of operating a chain based on certain technology stacks being around $10,000.

The future will undoubtedly be an era of coexistence of multiple chains. Although these emerging chains may choose interoperability for communication, 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 has brought about 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. Currently, there are many liquidity solutions, such as chain abstraction, intent, liquidation execution, native cross-chain, sharding, etc., but their core essence is similar.

We use a widely recognized architecture in the industry 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 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 expected final trading result (, which is the output ), rather than the specific execution path of the trade.

Account Management and Abstraction Layer

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. Some projects have built a credible account system that does not require inter-chain consensus, but only relies on the trusted commitments between existing account systems. Other projects achieve abstract management by generating multi-chain account wallets for users, greatly optimizing the user experience and reducing the fragmentation of the user experience.

Solution Layer

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

Settlement Layer

This is the middleware layer used to fulfill user intentions at the Layer 2. The 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, 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 play people for suckers. After reviewing a large number of options, we found that there are mainly a few methods:

1. Centered on RaaS: Assist in building Rollup shared liquidity and states on a specific tech stack by integrating specific shared sequencers and cross-chain bridges. This aims to address liquidity and state decentralization at a higher level.

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 fragmented user experience, involves complex backend implementation for developers and does not fundamentally solve liquidity and state decentralization.

3. Centered on the off-chain intent network: The core is that users send intents to the solver network, where the role of the solver competes for quotes, providing the optimal completion time and transaction price. These solvers can be AI agents, centralized exchanges, market makers, or even the integrated protocols themselves. Although intents can theoretically achieve arbitrarily complex cross-chain operations, in practice, it requires sufficient liquidity solvers to assist. Moreover, when encountering certain off-chain demands, there is a possibility of fraud among 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 state dispersion on 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 market makers or third-party applications. Such projects require managing complex cross-chain processes, which places high demands on developers and thus are also prone to security issues.

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 brings together fragmented on-chain liquidity, it will have great potential, and we have also seen many different solutions.

In the above two classifications, we can see that according to the layered structure, the settlement layer is the most atomic level solution. Above these atomic solutions, such as cross-chain, oracle, and pre-confirmation solutions, there is a more abstract layer constructed, which includes the solving layer, permission layer, and application layer. The various solutions listed above, which build abstract or liquidity solutions in different directions, correspond to different levels of this set, and can be understood as a relationship between upstream and downstream. However, these solutions are still not atomic level solutions. The issue of fragmented liquidity has led to the emergence of many complex derivative problems, and therefore, various solutions have emerged for interoperability. But essentially, it still relies on these components.

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

A certain project has built a RaaS service in the DeFi field, which can provide the components necessary for direct construction of DeFi protocols, such as oracles, liquidity pool types, interest rate models, assets, etc. It can also provide components like ready-to-use leveraged trading and yield strategies. This is equivalent to the construction end of other applications, but the final liquidity is placed in the liquidity layer of the project. However, it has not yet disclosed the underlying working principles.

Another project has built three core components, namely the Intent Compatibility Layer, Validity, and General Settlement Layer. External applications or the Intent Layer can publish intents to this project, and then its Intent Compatibility Layer can convert external intents into a format that protocol solvers can recognize, using a standardized format known as Validity Language. The project's nodes are responsible for submitting the final results to the General Settlement Layer via cross-chain bridges, fast settlement technologies, and so on.

There is another project which is a decentralized application that enables auction-based price discovery and unilateral liquidity pools. Its main mission is to provide professional trading firms with efficient inventory management tools and to easily connect to core DeFi protocols when settling trades based on usage intent. Meanwhile, the project has created a lending market for its lending transactions. This application focuses more on the trading itself.

A certain project has evolved from a brand upgrade, initially focused on consumer application apps. Later, the team discovered significant fragmentation issues in on-chain interactions, leading to the creation of a new project to address this problem. The cross-chain communication it employs is based on certain technologies, making it more native and secure than other cross-chain bridges.

There is also a project focused on Ethereum's ZK computing power market, ZK co-processors, and Layer 2 developers, with a team that possesses deep expertise 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 ZKPs, 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 a protocol commonly adopted by parallel execution projects. From the beginning, this project embedded cross-shard communication into the protocol. Cross-shard messages are verified as transactions by the validator committee of each shard.

The basic idea is to build an embedded cross-shard communication architecture through a sharded Layer 2 framework, which can solve the problems of liquidity and state dispersion. However, the core concept is not reasonable, as the issue of liquidity dispersion is a multi-chain problem, and what is being constructed 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, multiple projects are first publicly supporting a certain 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 that a filler can also be seen as a payer role in chain abstraction. This proposal has been jointly built by certain projects and is currently under review by a working group.

A certain tech stack, like the aforementioned standards and zkSharding, is an Ethereum internal solution for the fragmentation of liquidity between Layer 2 networks, addressing issues at the architecture layer, consensus layer, and application layer. This certain tech stack designs a complete multi Layer 2 solution to solve the problems of information transmission and the decentralization of the sorter all at once. When you use this tech 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 tech stack architecture.

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

Intent-based cross-chain bridge: This bridge supports fast and reliable liquidity transfer between blockchains, allowing users to set intentions, which helps the system automatically select the best path for liquidity movement. This approach abstracts 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 liquidity fragmentation risk caused by delayed settlements.

Fast Blocks and Verifiable Blocks Construction: By using Fast Blocks, the project significantly shortens block time, improves the efficiency of liquidity providers, and achieves a more synchronized cross-chain market. Fast Blocks help ensure that liquidity is available at all times and reduce the negative impacts caused by block confirmation delays, which may lead to...