Research on the Liquidity Fragmentation Problem in the Layer 2 Era

With Ethereum shifting towards Layer 2-centric scaling solutions and 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 interests and seek higher valuations. However, the emergence of numerous public chains has made it difficult for the ecosystem 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, yet another trading platform has introduced XLayer; Sony has released Soneium, and LINE has launched Kaia, among others. Nowadays, the capital and technical thresholds for building a chain have significantly decreased, with the operating cost of 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 brings a new challenge: liquidity and state dispersion. Given that 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 we have all heard of chain abstraction, intent, 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 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(Permission Layer)

Located below the application layer, users connect their wallets to dApps and request quotes to fulfill their trading intentions. Here, the "intention" refers to the expected final trading result (, which is the output ), rather than the specific execution path of the trade.

Account Management and Abstract Layer ( 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 constructs a trustworthy account system without the need to establish inter-chain consensus, only requiring credible commitments between existing account systems. Near Account realizes 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 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 like Anoma have built various intention-driven solutions. Derivatives of such intentions, such as the Predicate component, can realize users' intentions under specific rules.

Settlement Layer(Settlement Layer)

This is the middleware layer used to achieve user intentions in the Layer 2 solution. The core components of liquidity and state decentralization solutions include:

• Oracle (: Used to obtain state information from other chains.
• Cross-chain bridges ): Responsible for cross-chain information and Liquidity transfer.
• Pre-Confirmation (: Shorten cross-chain confirmation time.
• Data availability ) DA (: Provides accessibility to data.

In addition, factors such as inter-chain liquidity, finality), Layer 2 proof mechanisms, and others 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, which assist in building Rollups on OP Stack by adding specific shared sequencers and cross-chain bridges to share liquidity and state. This aims to address the decentralization of liquidity and state at a higher level. A more detailed approach here is the design of a dedicated shared sequencer, which is more focused on 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 for multi-chain transactions. This solution, while significantly addressing the issue of UX fragmentation, poses a complex backend implementation challenge for developers and does not fundamentally solve the issues of Liquidity and state decentralization.

3. Centered around the off-chain intent network: that is, the Solver Network in our "Introduction" cake architecture diagram, the core is that users 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 themselves like Liquorice, etc. Projects in this area include Anoma, Khalani, Enso, aori, and Valantis. Although intents can theoretically achieve arbitrarily complex cross-chain operations, sufficient liquidity Solvers are indeed needed to assist in implementation. Moreover, when encountering some off-chain demands, there is a possibility of fraud by Solvers. If fraud-proofing measures are introduced, the implementation difficulty of the Solver Network will increase, and the threshold for running Solvers will also be higher.

4. Centered on the on-chain liquidity network: This direction is specifically aimed at optimizing cross-chain liquidity issues, but it does not address the problem of decentralized on-chain states. The core is to build a liquidity layer on which applications are built to share the liquidity of 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 major market makers or third-party applications, such as Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Such projects require managing complex cross-chain processes, which places high demands on developers and makes them susceptible to hacking incidents.

Solving the liquidity issue 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 on-chain liquidity, it will hold tremendous potential, and we have also seen 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 schemes, a more abstract layer is built, which is the Solver Layer, Permission Layer, and Application Layer. The various solutions listed above that construct abstractions or liquidity solutions in different directions correspond to different levels in this framework, which can be understood as an upstream and downstream relationship. However, these solutions are still not atomic level solutions, and the entire issue of liquidity fragmentation has led to the emergence of many complex derivative problems. Therefore, a variety of solutions have emerged for interoperability. But essentially, these still rely on these components. Next, we will discuss several typical projects related to chain abstraction concepts to see how each of them addresses the problem of liquidity fragmentation from their own starting points.

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

)# INFINIT

INFINIT has built a RaaS service for the DeFi space, which can provide the components needed for directly constructing DeFi protocols, such as Oracle, Pool Type, IRM, Asset, etc. It can also offer immediately usable components like Leverage Trading and Yield Strategy. This is equivalent to other application building ends, but the final liquidity is placed on Infinit's liquidity layer. However, it has not yet disclosed the underlying working principles. Currently, INFINIT has secured $6 million in seed funding from some well-known investment institutions.

Khalani Network

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

External applications or the intent layer can publish intents to Khalani, and then 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 construction phase and has not disclosed more work details. In August, it received $2.2 million in seed funding from some well-known investment institutions.

(# 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 some core DeFi protocols when settling trades with intent. Meanwhile, Liquorice has created a lending market for its lending transactions. This application focuses more on the trading itself. It is still in the development stage and announced in July that it had secured $1.2 million in Pre-seed funding from some well-known investment institutions.

)# Xion

Xion is an upgrade from the Burnt brand. In the past, Burnt focused on consumer application programs, but the team discovered a significant fragmentation issue in on-chain interactions, which led to the creation 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 some well-known investment institutions as investors.

=nil; Foundation

nil is the ZK computing power market, ZK co-processor, and Layer 2 developer on Ethereum, with a team possessing deep expertise 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 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 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 construct 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 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.

ERC-7683

Ethereum is also working to solve the issue of cross-chain liquidity. Currently, some well-known projects have publicly supported the ERC7683 standard, which also employs 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 component is a Filler, which can also be described as the Solver role in chain abstraction for payment on behalf. This proposal is jointly constructed by several well-known projects 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 liquidity fragmentation between Layer 2s, each tackling the issue from the architecture layer, consensus layer, and application layer respectively. OP Stack resolves the challenges of information transmission and decentralization of the Sequencer by designing a complete multi-Layer 2 solution that addresses these issues at once. When you use the OP Stack architecture, cross-chain contracts are automatically deployed, and there will be a Supervisor to challenge and prevent the transmission of false cross-chain information. Currently, there are some well-known projects using the OP Stack architecture.

Among them, a typical example is Unichain. Unichain mainly solves the problem of cross-chain liquidity fragmentation by integrating with the Superchain network. This setup facilitates seamless liquidity movement by providing the following features:

Intention-based cross-chain bridge: this