Research on the Liquidity Fragmentation Problem in the Layer 2 Era

As Ethereum shifts towards Layer 2-centric scaling solutions and the rise of tools like RaaS, a large number of public chains are rapidly developing. Many entities wish to build their own chains to represent different interests and seek higher valuations. However, the emergence of numerous public chains makes it difficult for the ecosystem's development to keep up with the pace of public chains, resulting in many projects breaking even 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; leveraging ZK technology, a certain trading platform has introduced XLayer; Sony has released Soneium, and LINE has launched Kaia, among others. Nowadays, the financial and technical barriers to building a chain have been greatly reduced, with the cost of operating a chain based on OP Stack being approximately $10,000 per month.

The future will undoubtedly be an era of multi-chain coexistence. Although these Layer 2 chains may choose EVM compatibility for interoperability, due to the large number of downstream applications from the Web2 entities behind them, 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. As the existence of multi-chains is inevitable, interoperability is a field that must be explored and solved. Currently, there are many liquidity solutions, such as chain abstraction, intents, Clearing Execution, Native CrossChain, ZKSharding, but their core essence is the same.

We use the widely recognized Cake architecture in the industry to introduce the core components of cross-chain abstraction from top to bottom:

Application Layer(Application Layer)

This is the layer where users interact directly, and it is also the most abstract layer in liquidity solutions, as it completely masks the details of liquidity conversion. In the application layer, users interact with the front-end interface and may not necessarily understand the underlying liquidity conversion mechanisms.

Permission Layer(Permission Layer)

Located below the application layer, users connect their wallets to the dApp and request quotes to fulfill their trading intent. Here, "intent" 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, an account management and abstraction system that adapts to different chains is needed to maintain the unique account structure of each chain. For example, SUI's object-centric 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 for inter-chain consensus, only requiring 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.

Solve Layer ( Solver Layer )

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

Settlement Layer(Settlement Layer)

This is the middleware layer used to achieve user intent in solving layers. The core components of liquidity and state decentralization solutions include:

• Oracle (: used to obtain state information from other chains.
• Cross-chain bridge ) Bridges (: Responsible for cross-chain information and liquidity transmission.
• Pre-Confirmation ): Shorten cross-chain confirmation time.
• Data Availability ( DA ): Provides accessibility to data.

In addition, factors such as inter-chain Liquidity, finality ( 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 play people for suckers. 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 the OP Stack, it assists in sharing liquidity and state for Rollups built on the OP Stack by incorporating specific shared sequencers and cross-chain bridges. This aims to address the dispersion of liquidity and state at a higher level. A more detailed aspect of this is the separate design of shared sequencers, which is more targeted at Layer 2 and lacks universality, such as Astria, Espresso, and Flashbots.

2. Account-Centric: Similar to NEAR, 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 for signing multi-chain transactions. Although this solution can greatly address the issue of UX fragmentation, it involves complex backend implementation for developers and does not fundamentally solve the problems of Liquidity and state dispersion.

3. Centered on the off-chain intent network: this is the Solver Network in our "Introduction" cake architecture diagram, where the core function is for users to send intents 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 integrated protocols like Liquorice. Projects in this area include Anoma, Khalani, Enso, aori, and Valantis. Although intents can theoretically achieve any level of complex cross-chain operations, it is necessary to have sufficient Liquidity Solvers to assist in implementation. Moreover, when encountering certain off-chain demands, there is the potential for fraud from 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 rise.

4. Focused on an on-chain Liquidity network: This direction specifically optimizes cross-chain liquidity issues, but does not address other issues of on-chain state dispersion. The core is to build a Liquidity layer, on which applications are developed to share liquidity across the entire chain. Some projects include: Raye Network, INFINIT, Everclear, Elixir, etc.

5. Centered around on-chain applications: These applications build high liquidity applications by integrating large MM or third-party applications, such as Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. These types of projects require managing complex cross-chain processes, which places high demands on developers, making them very 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 liquidity across the entire chain, it will have tremendous potential, and we have also seen many different solutions.

![Research on the Fragmentation of Liquidity in the Layer 2 Era])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp###

In the above two classifications, we can see that according to the cake structure, the Settlement Layer is the most atomic level solution. Above these atomic solutions such as cross-chain, oracles, and Pre-Confirmation schemes, a more abstract layer is built, which is the Solver Layer, Permission Layer, and Application Layer. The various abstract or liquidity solutions we listed above in different directions conform to the different levels of this system and can be understood as an upstream and downstream relationship. 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, thus giving rise to a variety of solutions aimed at 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 addresses the issue of liquidity fragmentation from their own starting points.

(# INFINIT

INFINIT has built a RaaS service in the DeFi space that can provide the components necessary for directly building DeFi protocols, such as Oracle, Pool Type, IRM, Asset, etc. It can also provide immediately usable components like Leverage Trading and Yield Strategy. This is equivalent to other application construction ends, but the final liquidity is placed in Infinit's liquidity layer. However, the underlying working principle is still undisclosed. Currently, INFINIT has secured $6 million in seed funding from Robot Ventures, Electric Capital, and Maelstrom Capital.

)# Khalani Network

Khalani has built three core components: the Intent compatibility layer, Validity, and the universal settlement layer.

External applications or intent layers can publish intents to Khalani, and Khalani's Intent Compatibility Layer can convert external intents into a format recognizable by the protocol Solver, 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, etc. This project is still in the building stage and has not disclosed more work details. In August, it secured $2.2 million in seed funding from Ethereal Ventures, Nascent, Maelstrom Capital, and others.

![Research on the liquidity fragmentation issue in the Layer 2 era]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###

(# Liquorice

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 trades with intent. At the same time, Liquorice has created a lending market for its lending transactions. This application focuses more on the trading itself. It is still in the development phase and announced in July that it had raised $1.2 million in a Pre-seed round led by GreenField.

)# Xion

Xion is an upgrade from the Burnt brand. In the past, Burnt focused on consumer application software, but the team discovered a significant fragmentation issue in on-chain interactions, which led to the development of Xion to address this problem. 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. It has undergone four rounds of financing, with investors including Animoca, Multicoin, Alliance DAO, and Mechanism.

=nil; Foundation

nil is a developer of Ethereum's ZK computing power market, ZK co-processors, and Layer 2, with a strong foundation in ZK technology. It proposed the zkSharding solution, which uses ZK technology to horizontally scale the Ethereum mainnet, executing sharding and processing transactions in parallel while generating ZKP, with the main shard validating data, communicating with Ethereum, and synchronizing network status among all validators. The main shard also manages the distribution of validators and accounts in the execution shard. The consensus protocol used by the validation committee is also Hotstuff, which is common in the latest parallel execution projects. =nil; L2 has embedded cross-shard communication into the protocol from the very beginning. Cross-shard messages are verified as transactions by the validation 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, its core idea is not reasonable, because the problem that liquidity dispersion solves is a multi-chain problem, and it constructs a single Layer 2, which means that to solve it, all chains need to become a shard of ZK-sharding, which is difficult to achieve.

![Research on the liquidity fragmentation issue in the Layer 2 era]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###

(# ERC-7683

Ethereum is also working to address the issue of cross-chain liquidity. Currently, Arbitrum, OP, and a certain DEX are the first to publicly support the ERC7683 standard, which is 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 that a Filler can also be seen as the Solver role in chain abstraction to act as a payment agent. This proposal is jointly built by a certain DEX and Across and is currently under review by the Cake working group.

)# OP Stack

OP Stack, ERC-7683, and zkSharding are all solutions within Ethereum aimed at addressing the liquidity fragmentation between Layer 2s, tackling the issues at the architectural, consensus, and application layers respectively. OP Stack aims to solve information transmission and sequencing by designing a comprehensive multi-Layer 2 solution.