Research on the Liquidity Fragmentation Problem in the Layer 2 Era

With Ethereum transitioning to Layer 2-centric scaling solutions and the rise of tools like RaaS, many public chains are rapidly developing. Numerous entities wish to build their own chains to represent different interests and seek higher valuations. However, the emergence of a multitude of public chains has made it difficult for ecosystem development to keep pace with public chains, resulting in many projects breaking their initial value at TGE.

With the help of OP Stack, a trading platform has launched its own Base Layer 2, while another trading platform has released Ink; utilizing ZK technology, a trading platform has introduced XLayer; Sony has released Soneium, and LINE has launched Kaia, among others. Nowadays, the funding 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 coexistence of multiple chains. 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 presents a new challenge: liquidity and status dispersion. As the existence of multi-chain is inevitable, interoperability is a field that must be explored and solved. There are currently many liquidity solutions, such as chain abstraction, intent, 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(Application Layer)

This is the layer of direct interaction for users, 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 fully understand the underlying liquidity conversion mechanisms.

权限层(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 (, which is the output ), rather than the specific execution path of the transaction.

Account Management and Abstraction ( Key Management and Account Abstraction )

Due to the existence of a multi-chain environment, a management and abstraction system for accounts that adapts to different chains is needed to maintain the unique account structures of each chain. For example, the object-centered account system of SUI 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, only requiring trusted commitments between existing account systems. Near Account 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.

Solver Layer(

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

Settlement Layer )Settlement Layer (

This is the middleware layer used to realize user intentions. 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 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 ( 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 a few approaches:

1. Centered around RaaS: Similar to Rollup solutions like OP Stack, by incorporating specific shared sequencers and cross-chain bridges to assist in building Rollups on OP Stack, which share liquidity and state. This aims to address the decentralization of liquidity and state at a higher-level direction. A more refined aspect here is the design of separate shared sequencers, which is more targeted towards 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 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 liquidity and state dispersion.

3. Centered on the off-chain intention network: this refers to the Solver Network in our "Introduction" cake architecture diagram, where the core is that users send intentions 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 themselves like Liquorice, etc. Projects in this area include Anoma, Khalani, Enso, aori, and Valantis. Although intentions can theoretically achieve complex cross-chain operations of any difficulty, it is essential to have enough Liquidity Solvers to assist in implementation. Additionally, when facing some off-chain demands, there is a possibility of fraud by Solvers. If fraud-proof mechanisms are introduced, the implementation difficulty of the Solver Network will increase, as will the threshold for running Solvers.

4. Centered on the on-chain Liquidity network: This direction specifically optimizes the liquidity issues of cross-chain, but does not solve the problem of other on-chain state dispersion. Its core is to build a Liquidity layer, on which applications are built to share the full-chain liquidity. Some projects include: Raye Network, INFINIT, Everclear, Elixir, etc.

5. Centered on 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 and have high demands on developers, which makes them very susceptible to hacking incidents.

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

Solving the liquidity problem is a very important proposition. In the financial world, liquidity often represents everything. If we can build a platform that integrates liquidity, especially by consolidating fragmented on-chain liquidity, it will have tremendous potential, and we have also explored many different solutions.

In the above two classifications, we can see that based on the structure of the cake, 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 Solver Layer, Permission Layer, and Application Layer. The various solutions listed above, which are built in different directions for abstraction or liquidity, conform to this different hierarchy and can be understood as upstream and downstream relationships. However, these solutions are still not atomic level solutions. The entire liquidity split issue has led to the emergence of many complex derivative problems, thus giving rise to a plethora of solutions targeting interoperability. But essentially, we still need to 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 split from its own starting point.

(# INFINIT

INFINIT has built a RaaS service in the DeFi space, which can provide the necessary components 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. It is equivalent to other application building ends, but the final liquidity is placed in Infinit's liquidity layer. However, it has not yet disclosed the underlying working principles. Currently, INFINIT has secured $6 million in seed funding from Robot Ventures, Electric Capital, and Maelstrom Capital.

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

(# Khalani Network

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

External applications or intent layers can publish intents to Khalani, and then Khalani's Intent compatibility layer can convert 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, etc. This project is still in the construction phase and has not disclosed more work details. In August, it secured $2.2 million in seed round financing 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-e4d53accc40f8c915eaabbd2909f51d4.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, while easily connecting 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 a $1.2 million Pre-seed round funding led by GreenField in July.

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

(# Xion

Xion is an upgrade from the Burnt brand. Previously, Burnt focused on consumer applications, but the team discovered significant fragmentation in on-chain interactions, which led to the development of Xion to address this issue. 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 gone through four rounds of financing, with investors including Animoca, Multicoin, Alliance DAO, Mechanism, and others.

)# =nil; Foundation

nil is the ZK computing power market, ZK co-processor, and Layer 2 developer of Ethereum, with a team that possesses deep ZK technical expertise. 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 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. =nil; L2 has embedded cross-shard communication into the protocol from the beginning. Cross-shard messages are verified as transactions by the validating committee of each shard.

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, the core idea is not reasonable, because the problem that Liquidity dispersion addresses is a multi-chain issue, and what is being built is a single Layer 2. This means that in order 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-69852e6a1bbab8f4fc50f48006eb6fef.webp###

(# ERC-7683

Ethereum is also working to address the issue of cross-chain liquidity. Currently, some DEXs and OP are the first to publicly support the ERC7683 standard, which also uses 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 of this is a Filler, which can also be referred to as the Solver role in chain abstraction for payment on behalf. This proposal was jointly developed by a certain DEX and Across.