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

With Ethereum shifting towards Layer 2-centric scaling solutions and the rise of tools like RaaS, numerous public chains are rapidly developing. Many entities wish to build their own chains to represent different interests and seek higher valuations. However, the surge of public chains has made it difficult for ecosystem development to keep pace with the public chains, leading to many projects breaking even 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 trading platform has introduced XLayer; Sony has launched Soneium, and LINE has rolled out Kaia, among others. Nowadays, the funding and technical barriers for building a chain have been significantly lowered, with the cost of operating a chain based on OP Stack being about $10,000 per month.

The future will inevitably be an era of multi-chain coexistence. 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 about a new challenge: liquidity and state dispersion. Since the existence of multiple chains is inevitable, interoperability is a field that must be explored and solved. There are currently many liquidity solutions, such as chain abstraction, intentions, 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, as it completely abstracts 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 user's 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, the object-centric account system of SUI is completely different from EVM. One Balance is a representative project in this field, which builds a trustworthy account system without establishing 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 the user experience and reducing UX fragmentation. However, the liquidity aspect mainly integrates existing public chains.

Solver Layer

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

Settlement Layer

This is the middleware layer used to realize user intentions at the Layer 2 level. The core components of liquidity and state decentralization solutions 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): Providing access 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.

Solution

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 assists in building shared liquidity and state on OP Stack by incorporating specific shared orderers and cross-chain bridges. This aims to address the decentralization of liquidity and state at a higher-level direction. A more specific aspect here is the separate design of shared orderers, which is more targeted towards Layer 2 and does not possess 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 dispersion.

3. Centered on the off-chain intent network: The core is that users send intents 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 intents can theoretically achieve arbitrarily complex cross-chain operations, in practice, sufficient liquidity Solvers are required to assist, and when encountering some off-chain demands, there is a possibility of fraud by Solvers. If fraud proofs and other means are introduced, the implementation difficulty of the Solver Network will increase, and the threshold for running Solvers will also be higher.

4. Centered on on-chain liquidity networks: This direction specifically optimizes the liquidity issues of cross-chain, but does not address the problem of dispersed on-chain states from 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. Such projects require management of complex cross-chain processes, which places high demands on developers, making them also very susceptible to hacking incidents.

Solving liquidity issues is a very important proposition. In the financial world, liquidity often represents everything. If a unified liquidity platform can be built, especially one that integrates fragmented on-chain liquidity, it will possess tremendous potential, and we have also seen many different solutions.

In the two classifications above, we can see that based on the cake structure, the Settlement Layer is the most atomic level solution. Above these atomic solutions like cross-chain, oracle, and Pre-Confirmation schemes, there is a more abstract layer constructed, which is the Solver Layer, Permission Layer, and Application Layer. The various solutions listed above, constructed in different directions for abstraction or liquidity, 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, and the overall liquidity play people for suckers issue has led to the emergence of many complex derivative problems. Therefore, in response to interoperability, a multitude of solutions has emerged. But fundamentally, these components still need to be relied upon. Next, we will discuss several typical projects of chain abstraction concepts to see how each addresses the liquidity play people for suckers issue from its own perspective.

A certain project has built a RaaS service in the DeFi space, which can provide the components needed for directly building DeFi protocols, such as Oracles, Pool Type, IRM, Asset, etc. It can also provide immediately usable components like Leverage Trading and Yield Strategy. It is equivalent to other application building ends, but the final Liquidity is placed in the liquidity layer of this project. However, it has not yet disclosed the underlying working mechanism.

Another project has built three core components: the Intent compatibility layer, Validity, and the 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 recognizable by the protocol Solver, using the standardized format known as Validity language. The project's nodes are responsible for submitting the final results to the general settlement layer through cross-chain bridges, rapid settlement technologies, and more. This project is still in the construction phase and has not disclosed more work details yet.

There is also 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 seamlessly connect to core DeFi protocols when settling trades based on usage intent. At the same time, the project has created a lending market for its lending transactions. This application is more focused on the trading itself. It is still in the development stage.

A certain project is built on the Comet BFT consensus protocol. The cross-chain communication it adopts is based on Cosmos IBC, making it more native and secure than other cross-chain bridges.

There is also a project focused on the ZK computing power market, ZK co-processors, and Layer 2 developers of Ethereum, with a team possessing a solid foundation in ZK technology. They proposed the zkSharding solution, which uses ZK technology to horizontally scale the Ethereum mainnet, executing sharded parallel processing of transactions and generating ZKPs, while the main shard verifies data, communicates with Ethereum, and synchronizes network state 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. This project’s Layer 2 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 not reasonable because the issue of liquidity dispersion is a multi-chain problem, while it constructs 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, certain projects are publicly supporting the ERC7683 standard, which is 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 said to play the role of a Solver in chain abstraction for payment delegation. This proposal is currently under review by the Cake working group.

OP Stack, ERC-7683, and zkSharding are all solutions within Ethereum aimed at addressing the fragmentation of liquidity between Layer 2s, each tackling the issue from the architectural, consensus, and application layers respectively. OP Stack designs a comprehensive multi-Layer 2 solution to address the issues of information transmission and Sequencer decentralization in one go. When you utilize the OP Stack architecture, cross-chain contracts are automatically deployed, and there will be a Supervisor in place to challenge and prevent the transmission of false cross-chain information. Currently, some mainstream trading platforms are using the OP Stack architecture.

One of the more typical examples is Unichain. Unichain mainly integrates with the Superchain network.