Research on the Liquidity Fragmentation Issue in the Layer 2 Era

With Ethereum's shift towards Layer 2-centric scaling solutions and the rise of tools like RaaS, many public chains are rapidly developing. Numerous entities are looking to build their own chains to represent different interest claims and seek higher valuations. However, the emergence of numerous public chains has made it difficult for the ecosystem's development to keep up with the pace of these chains, resulting in many projects dropping in value at the time of TGE.

With the help of OP Stack, a trading platform launched its own Base Layer 2, another trading platform released Ink; leveraging ZK technology, a trading platform launched XLayer; Sony released Soneium, and LINE launched Kaia, among others. Today, the capital and technical barriers to building a chain have been greatly lowered, with the monthly cost of operating a chain based on OP Stack being around $10,000.

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 state fragmentation. Since the existence of multiple chains is inevitable, interoperability is a field that must be explored and solved. Currently, there are 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

This is the layer where users interact directly, and it is the most abstract layer in liquidity solutions because it completely obscures 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, "intent" 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 structure of each chain. For example, SUI's object-centered account system is completely different from EVM. One Balance is a representative project in this field, which builds a trustworthy account system without the need to establish inter-chain consensus, relying only on 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.

Solver Layer

The layer is responsible for receiving and executing users' trading intentions, where the Solver role competes to provide a better user experience, including faster transaction times and execution speeds. On this basis, various intention-driven solutions have been built based on intentions. 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 solve the layer for realizing user intentions. The core components of the solutions for liquidity and state decentralization 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): The accessibility of provided 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 a few methods:

1. Centered around RaaS: Similar to Rollup solutions like OP Stack, this approach assists in building Rollup shared liquidity and state on OP Stack by incorporating specific shared sequencers and cross-chain bridges. It aims to address the dispersion of liquidity and state at a higher-level direction. A more segmented aspect here is the design of independent shared sequencers, which is more targeted at Layer 2 and lacks 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 distribution.

3. Centered around the off-chain intent network: The core idea is that users send intents to the Solver network, where 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, sufficient liquidity Solvers are required for assistance in implementation. Additionally, when faced with certain off-chain demands, there is a possibility of fraud among Solvers. If measures such as fraud proofs are introduced, the implementation difficulty of the Solver Network will increase, and the threshold for running Solvers will also become higher.

4. Centered on the on-chain liquidity network: This direction is specifically aimed at optimizing the liquidity issues across chains, but it does not address the problem of on-chain state dispersion. Its core is to build a liquidity layer, on which applications can be built to share the liquidity of the entire chain.

5. Centered on on-chain applications: These applications build high liquidity solutions by integrating large MM or third-party applications, 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 we can build an integrated liquidity platform, especially one that consolidates scattered on-chain liquidity, it will have immense potential. We have also seen many different solutions.

In the above two categories, we can see that based on the cake 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 built, which includes the Solver Layer, Permission Layer, and Application Layer. The various solutions we listed above, which are built in different directions for abstraction or liquidity solutions, 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 entire liquidity disconnection issue has led to the emergence of many complex derivative problems. Therefore, a wide variety of solutions have emerged in response to interoperability. However, it still fundamentally 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 disconnection from its own starting point.

INFINIT

INFINIT has built a RaaS service for the DeFi sector, which can provide the components necessary for directly building DeFi protocols, such as Oracle, Pool Type, IRM, Asset, etc. It can also offer immediately available components like Leverage Trading and Yield Strategy. This is equivalent to the construction end of other applications, but the final liquidity is placed in Infinit's liquidity layer. However, it still has not disclosed the underlying working principles. Currently, INFINIT has secured $6 million in seed round funding from certain investment institutions.

Khalani Network

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

External applications or the intention layer can publish intentions to Khalani, and then Khalani's Intent compatibility layer can convert external intentions into a format recognized by the protocol Solver, using the standardized format known as the Validity language. The Khalani node is responsible for submitting the final results to the universal settlement layer via cross-chain bridges, fast settlement technologies, etc. This project is still in the construction phase and has not disclosed more work details yet. In August, it received $2.2 million in seed funding from certain 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 efficient inventory management tools for professional trading firms 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 stage and announced in July that it secured $1.2 million in a Pre-seed funding round led by a certain investment institution.

Xion

Xion is an upgrade from the Burnt brand. In the past, Burnt focused on consumer applications, but the team discovered a significant fragmentation issue in on-chain interactions. Therefore, Xion was built 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 gone through four rounds of financing and received support from multiple investment institutions.

=nil; Foundation

nil is a ZK computing power market, ZK co-processor, and Layer 2 developer for Ethereum, with a team possessing deep ZK technical expertise. It 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 the network state 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 embedded inter-shard communication into the protocol from the very beginning. Inter-shard messages are verified by the validator committee of each shard as transactions.

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 problem of liquidity dispersion is a multi-chain issue, while it constructs a single Layer 2. This means that to solve it, all chains would need to become a shard of ZK-sharding, which is difficult to achieve.

ERC-7683

Ethereum is also working to address the issue of cross-chain liquidity. Currently, some well-known projects are publicly supporting 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 is a Filler, which can also be said to take on the role of Solver in chain abstraction for payment. This proposal is being jointly developed by some well-known projects and is currently under review by the Cake working group.

OP Stack

OP Stack, ERC-7683, and zkSharding are all solutions for the fragmentation of liquidity between Layer 2s within Ethereum, addressing it from the architectural, consensus, and application layers, respectively. OP Stack solves the issues of information transmission and Sequencer decentralization by designing a complete multi Layer 2 solution. When you use the OP Stack architecture, cross-chain contracts are automatically deployed, and there is a Supervisor to challenge and prevent the transmission of false cross-chain information. Currently, several well-known trading platforms and projects are using the OP Stack architecture.

Among them, a typical example is Unichain. Unichain mainly operates through collaboration with