Introduction
Since Ethereum has shifted to a Layer 2-centric expansion solution, coupled with the rise of tools like RaaS, a large number of public chains have developed rapidly. 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 out at the time of TGE.
With the help of the OP Stack, Coinbase has launched its own Base Layer 2, and Kraken has released Ink; with the help of ZK technology, OKX has launched XLayer; Sony has released Soneium, and LINE has launched Kaia. Nowadays, the financial and technical thresholds for building a chain have been greatly reduced, and the cost of operating a chain based on the OP Stack is about $10,000 per month.
The future will be an era of multi-chain coexistence. Although these Layer 2 chains may choose EVM compatibility to achieve interoperability, due to the large number of downstream applications behind their Web2 entities, they find it difficult to build applications on the same chain and reach consensus.
TVL Breakdown, source: Defillama
The current multi-chain ecosystem has brought a new challenge: fragmentation of liquidity and state. Since the existence of multiple chains is inevitable, interoperability is an area that must be explored and solved. There are currently many liquidity solutions, such as the ones we've heard of like Account Abstraction (Particle Network, Socket, XION, INFINIT, Borsa), Intent (Anoma, Khalani), Clearing Execution (Connext), Native CrossChain (Cross), and ZKSharding (=nil; Foundation), but their core essence is the same.
Chain Abstraction Stack, Source: FrontierResearch
We use the industry-recognized Cake architecture to introduce the core component composition of cross-chain abstraction from top to bottom:
Application Layer
This is the layer where users directly interact, and it is the most abstract layer in the liquidity solution, as it completely shields the details of liquidity conversion. At the application layer, users interact with the front-end interface without necessarily understanding the underlying liquidity conversion mechanism.
Permission Layer
Located below the application layer, users satisfy their transaction intentions by connecting their wallets to dApps and requesting quotes. The "intention" here refers to the user's expected final transaction result (i.e., the output), rather than the specific execution path of the transaction.
Key Management and Account Abstraction
Due to the existence of a multi-chain environment, a account management and abstraction system that adapts to different chains is needed 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 has built a trusted account system without the need to establish inter-chain consensus, only requiring trusted commitments between existing account systems. Near Account achieves abstraction 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 the existing public chains.
Solver Layer
This layer is responsible for receiving and implementing the user's transaction intentions, and the Solver role competes here to provide a better user experience, including faster transaction times and execution speeds. On this basis, intent-based projects like Anoma have built various intent-driven solutions. Derivatives of such intentions, such as the Predicate component, can realize user intentions under specific rules.
Settlement Layer
This is the middleware layer used by the Solver layer to implement the user's intentions. The core components of the solution to the fragmentation of liquidity and state include:
- Oracles: Used to obtain state information from other chains.
- Bridges: Responsible for the transmission of information and liquidity across chains.
- Pre-Confirmation: Shortens the cross-chain confirmation time.
- Data Availability (DA): Provides data accessibility.
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.
Solutions
Currently, there are various solutions to the problem of liquidity fragmentation on the market. After reviewing a large number of solutions, we found that they are mainly as follows:
1. Centered on RaaS: Similar to the OP Stack Rollup solution, by adding a specific shared orderer and cross-chain bridge to assist the Rollups built on the OP Stack to share liquidity and state. This hopes to solve the fragmentation of liquidity and state in a higher-level direction. A more subdivided one here is the separate design of the shared orderer, which is more targeted at Layer2 and lacks universality, such as Astria, Espresso, and Flashbots.
Chain Abstraction, source:NEAR
2. Centered on accounts: Similar to NEAR, build a cross-chain account wallet, supported by a technology called "chain signature" to sign and execute transactions across multiple blockchain protocols. The core component is the MPC network, which replaces the user to sign multi-chain transactions. This solution, while greatly solving the problem of UX fragmentation, involves complex backend implementation for developers and does not fundamentally solve the fragmentation of liquidity and state.
3. Centered on off-chain intent networks: That is, the Solver Network in the "Introduction" cake architecture diagram, the core of which is that users send intentions to the Solver network, and the Solver role competes to provide quotes, giving the optimal completion time and transaction price. These Solvers can be AI agents, CEXs, market makers, or even integrated protocols like Liquorice. Projects in this area include Anoma, Khalani, Enso, aori, and Valantis. Although intentions can theoretically achieve arbitrarily complex cross-chain operations, their implementation requires sufficient liquidity Solvers to assist, and when encountering some off-chain demands, Solvers may have the possibility of fraud. If fraud proofs and other measures are introduced, the implementation difficulty of the Solver Network will become higher, and the threshold for running Solvers will also be higher.
4. Centered on on-chain liquidity networks: This direction is specifically optimized for the problem of cross-chain liquidity, but does not solve the problem of state fragmentation on other chains. Its core is to build a liquidity layer, on which applications are built to share the liquidity across chains. Some projects include Raye Network, INFINIT, Everclear, and Elixir.
5. Centered on on-chain applications: This type of application builds high-liquidity applications by integrating large MMs or third-party applications, such as Liquorice, Socket, Radiant Capital, 1inch, and Hedgemony. These projects need to manage complex cross-chain processes, which places extremely high demands on developers, and are therefore also prone to hacking incidents.
Solving the liquidity problem is a very important proposition, as liquidity represents everything in the financial world. If a platform that integrates liquidity can be built, especially one that integrates the scattered liquidity across all chains, it will have great potential. We have also seen many different solutions.
In the two classifications above, we can see that according to the cake structure, the Settlement Layer is the most atomic-level solution, and on top of these cross-chain, oracle, Pre-Confirmation and other atomic solutions, a more abstract layer is built, which is the Solver Layer, Permission Layer, and Application Layer. The various solutions we listed above to build abstraction or liquidity solutions in different directions fit into different levels of this set, which can be understood as an upstream and downstream relationship. However, these solutions are still not atomic-level solutions, and the problem of liquidity fragmentation has brought about the emergence of many complex derivative problems. Therefore, in terms of interoperability, various solutions have been derived, but essentially they still depend on these components. Next, we will discuss several typical chain abstraction concept projects to see how they each solve the problem of liquidity fragmentation from their own starting point.
INFINIT
INFINIT Structure, source:InfinitINFINIT built a RaaS (Robotics-as-a-Service) service for the DeFi ecosystem, which can provide DeFi protocols with the necessary components for direct construction, such as Oracle, Pool Type, IRM, Asset, and also provide ready-to-use Leverage Trading and Yield Strategy components. It is similar to the application construction end, but the final liquidity is placed in the Infinit liquidity layer. However, the underlying working principles have not yet been disclosed. INFINIT has recently raised $6 million in seed funding from Robot Ventures, Electric Capital, and Maelstrom Capital.
Khalani Network
Khalani Network Structure, source: KhalaniNetworkKhalani has built three core components: the Intent Compatibility Layer, Validity, and the Universal Settlement Layer. The external application or intent layer can publish intents to Khalani, and Khalani's Intent Compatibility Layer can translate the external intents into a format recognizable by the protocol Solver, using the standardized Validity language. Khalani nodes are responsible for submitting the final results to the Universal Settlement Layer through cross-chain bridges and fast settlement technologies. This project is still in the construction phase and has not yet disclosed more details of its work. It received $2.2 million in seed funding in August from Ethereal Ventures, Nascent, Maelstrom Capital, and others.
Liquorice
Liquorice Structure, source: LiquoriceLiquorice is a decentralized application that enables price discovery based on auctions and unilateral liquidity pools. Liquorice's primary mission is to provide professional trading firms with efficient inventory management tools and easily connect to core DeFi protocols like 1inch and Uniswap X when settling trades using intents. Meanwhile, Liquorice has created a lending market for its lending and borrowing transactions. This application is more focused on the trading itself. It is still in the development stage and announced a $1.2 million pre-seed round led by GreenField in July.
Xion
Xion is an upgrade from the Burnt brand, which previously focused on consumer applications. The team later found that on-chain interactions were highly fragmented, so they built 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. Xion has completed four rounds of financing, with investors including Animoca, Multicoin, Alliance DAO, and Mechanism.=nil; Foundation
=nil; is the developer of the Ethereum ZK compute market, ZK co-processor, and Layer2. The team has a deep technical background in ZK. They proposed the zkSharding solution, which uses ZK technology to horizontally scale the Ethereum mainnet, execute sharding in parallel, and generate ZKPs, while the main shard verifies the data, communicates with Ethereum, and synchronizes the network state across all validators. The consensus protocol used by the validator 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 validator committees of each shard. The basic idea is to build a cross-shard communication architecture embedded like IBC through a sharded Layer2 architecture to solve the problem of liquidity and state fragmentation. However, this core idea is not reasonable, as the problem of liquidity fragmentation is a multi-chain problem, and the single Layer2 it builds means that to solve it, all chains need to become a shard of ZK-sharding, which is difficult to achieve.ERC-7683
ERC-7683, source:AcrossEthereum is also working to solve this cross-chain liquidity problem. Currently, Arbitrum, OP, and Uniswap are the first to publicly support the ERC7683 standard, which also uses an intent-based cross-chain approach. Its core goal is to establish a universal standard for cross-L2 and cross-sidechain cross-chain operations, standardizing order and settlement interfaces, and achieving seamless cross-chain execution. Its core is a Filler, or what can be called a Solver role in the chain abstraction. This proposal was jointly built by Uniswap and Across and is currently being reviewed by the Cake working group.