The current state of chain abstraction: an overview of solutions and related projects

Source: Digital Asset Research Company ASXN; Translation: Golden Finance xiaozou

1. Introduction

The crypto industry is full of changes, and one of the few constants is the growing number of blockchains. Whether it is Ethereum L2, application chain, or alt L1, there seems to be a large number of new blockchains emerging all the time.

While different blockchains provide users with many different options, it also brings challenges to developers and multi-chain users. More and more chains will cause fragmentation problems in liquidity and usage, which will damage the user experience-this is a very bad thing for multi-chain users and application developers.

It can be said that the current multi-chain situation of cryptocurrency is one of several stories of infrastructure iteration and incentive misalignment. Since the introduction of the PoS consensus mechanism, the number of blockchains in the crypto world has exploded. Compared with the Bitcoin PoW consensus mechanism, PoS greatly reduces the barriers to launching and protecting new networks, giving rise to a Cambrian explosion of innovative projects in the L1 field. To solve the scalability trilemma, we have Solana, Cosmos and its appchain, Berachain and its PoL consensus mechanism, Ethereum L2 and fraud proofs, etc., each with their own unique way of innovation.

While innovation may be the main driver behind the explosive growth of blockchain, incentive misalignment is also responsible. Infrastructure trades at a higher premium than applications, so developers take valuation fluctuations into account when deciding what to build and where to build it. This incentive misalignment has led to countless various blockchains or protocols that "own their own stack", which is largely responsible for the crypto world we are in today.

2. The rise of modularity and rollups

The concept of modularity is a relatively new concept that was first proposed by Mustafa Al-Bassam in an academic paper titled "LazyLedger: A Distributed Data Availability Ledger with Client-Side Smart Contracts" in 2019. In this paper, he outlined a blockchain design philosophy that decouples network consensus and data availability functions from transaction settlement and execution.

The benefit of modularity is specialization, whether it is affordable DA (data availability) or off-chain execution. Similar to Adam Smith's assumption that the division of labor is the source of economic growth, specialization (division of labor) drives scalability (growth) by improving efficiency.

On October 2, 2020, Vitalik turned to rollup as Ethereum's main scaling solution - rollup is a natural extension of the "rise of modularity". Ethereum's ultimate goal is to become a globally coordinated financial layer, and achieving this goal requires scale expansion. However, given the scalability trilemma, Ethereum has optimized decentralization and security at the expense of scalability. By bundling multiple transactions into a single transaction package and then submitting that package to the Ethereum mainnet, rollup increases transaction throughput while reducing transaction costs. This approach minimizes the amount of data processed on-chain, enabling faster and cheaper transactions. However, as the number of rollups increases, the complexity of interacting with the Ethereum ecosystem also increases, as additional infrastructure needs to be built to connect rollups to the rest of the ecosystem.

Celestia's scalability is enhanced by its unique Data Availability Sampling (DAS) approach. This allows the network to scale as more light nodes are added, allowing for larger blocks without compromising security or decentralization.

3. Chain Abstraction

To surpass Web2, Web3 UX needs to provide an absolutely better experience (taking into account switching costs). This is where chain abstraction comes in.

As a concept, chain abstraction is closer to the end goal than a means to an end goal. Therefore, "chain abstraction" is a user experience, and any component/improvement can be considered to be committed to "realizing the future of chain abstraction."

To be a multi-chain user in the crypto world today, you need to build financial bridges between many chains, shuttle through complex UIs, and pay for transactions with many different tokens, each with its own risk characteristics. Users need to interact with the various "pipes" of the crypto economy, which is a cumbersome and complex experience - the equivalent "pipe" in traditional finance would be to trade on FedWire. Considering chain abstraction from the end goal of Web2 UX type, there are two key pain points that need to be solved: the complexity of Web3 UX, and the fragmentation of users and liquidity.

4. Abstraction in Web2

In the context of computer science, abstraction is defined as follows:

Simplifying or removing technical complexity from the user experience, producing technologies that hide these details and processes. These complexities still exist and play a role, but they are invisible to users.

In the Web2 world, abstraction plays a vital role in creating a user-friendly and seamless experience by hiding the technical complexity of various operations and presenting simplified interfaces to users. For example, users interact with websites through browsers without understanding what the underlying protocols such as HTTP, TCP/IP, or DNS are. Users simply open Outlook, write an email, and send it - they are completely unaware that their email interacts with sending protocols such as SMTP and receiving protocols such as IMAP/POP. Web hosting and cloud services abstract server management, data replication, and load balancing, providing user-friendly interfaces for easy deployment and management of applications. Authentication and authorization processes (including password hashing and session management) are hidden behind simple login interfaces. Online payment services like PayPal and Stripe abstract secure encryption, fraud detection, and banking network communications, supporting users to make effortless transactions. The most important point is that Web2 provides an experience that non-internet native users can also browse, and Web2's focus on abstraction makes this technology accessible.

Google, as the preferred search engine, can be considered the ultimate abstraction. By serving as a broad guide to the Internet, it simplifies the information retrieval process, allowing users to enter search requests without having to understand the complex search algorithms or web crawling process. Google's algorithm indexes billions of web pages and ranks them according to relevance, presenting the most important results to users. This abstraction means that users do not need to have technical knowledge about SEO, HTML structure, or web hosting, because Google hides these complexities and provides direct, systematic search results. In addition, Google also provides most of the services mentioned above - mail (Gmail), writing (Google Docs), storage (Google Drive), etc. Through an accessible unified interface, Google further enhances the user experience by bringing together various functions into a highly cohesive ecosystem.

Let's take this a step further and understand it more clearly: Web2 is composed of many protocols that interoperate with each other, and in terms of abstraction requirements, Web2 and Web3 are not much different at the "bottom". For the average Web2 user, there is no need to understand these protocols, and this simplified user experience can serve as a guiding light for chain abstraction.

5. Formal Definition

Chain Abstraction - "A user experience that eliminates the manual process required for multi-chain interaction"

Let's look at the problems that chain abstraction attempts to solve:

• Bridging - Users need to connect value to different chains, which brings both significant user experience friction and security risks.

• Gas Tokens - Users need to obtain and manage different tokens on different chains to pay for gas fees.

• Account and Wallet Fragmentation - Users need to interact with multiple accounts to access their full balance. This problem is more serious in non-EVM ecosystems because separate addresses and wallets are required.

• Liquidity Fragmentation - As the number of blockchains increases, liquidity is dispersed and further isolated on these chains.

6. Fragmentation

As mentioned earlier, incentive misalignment, Ethereum's rollup-centric roadmap, and the popularity of application chains, application-specific rollups, and "own your own stack" modularization have led to increased liquidity and user fragmentation, as well as the disintegration of a unified and smooth user experience.

Often, proponents of "monolithic architecture" use Solana and other non-EVM chains (such as Sui and Aptos) as examples to show the simplicity they provide to users.

If users bridge funds to Solana, they usually only need to interact with one form of USDC and one form of SOL. Solana has its own problems with the interchangeability of USDC due to the long-standing existence of Wormhole and Axelar USDC, but these problems have been largely resolved or improved. Solana "ecosystem" refers to Solana and the applications built on it. There is no L2 (yet), and there is no need to bridge to obtain more liquidity or a different subset of applications.

In contrast, once users log onto the Ethereum ecosystem (including rollups), they encounter various forms of USDC and various forms of ETH. For example, while ETH on Optimism and ETH on Arbitrum are for all intents and purposes the same asset — both are bridged from the Ethereum mainnet using their own canonical bridges — they cannot be used interchangeably. Certain applications only run on Optimism, while others only exist on Arbitrum. For all practical purposes, ETH on Optimism and ETH on Arbitrum are on completely different chains, with different ecosystems and different use cases.

Even at the wallet level, the two are treated as different assets. Emerging wallets like Rabby and Rainbow have worked hard to obfuscate and abstract assets at the wallet level. Still, users will find themselves managing assets that are “fungible” (actually almost in an irrefungible way) across multiple chains and rollups.

This difference is more obvious at the non-rollup level. For non-EVM chains (such as Solana, Sui, Aptos) and non-Ethereum EVM L1 (such as BNB and Avalanche C-Chain), users must also deal with non-native assets (axlUSDC, axlETH, etc.).

In theory, if rollups fulfilled their promises, completely divested Ethereum users, and became their own "monopoly" chain on top of Ethereum, then there would be no need for bridging and seeking liquidity. However, this is not the case. The three largest rollups: Arbitrum, Optimism, and Base, each have different ecosystems, use cases, and users. Optimism has moved to adding additional levels of modularity: with superchains (more on that later). Arbitrum has focused primarily on DeFi (particularly perpetual contracts and options DEXs), and more recently on L3 (Arbitrum's own additional modularity layer) with the launch of Xai and Sanko. Base, on the other hand, is primarily focused on SocialFi applications.

As you can see, "general purpose" L2s have begun to develop their own specific focus and use cases. A user who wants to play games must first bridge to Arbitrum and then to Xai or Sanko. If the same user wants to make Degen rewards on Farcaster or buy keys on friendtech, they must bridge to Base. If the user wants to use Synthetix, they will have to bridge to Optimism. The end result is a high degree of fragmentation, which is not intentional. In general, each general purpose L2 should aim to provide a wide variety of applications to meet every need of the user: providing a single experience in a modular setting. But this is not the case, for two reasons:

• Due to the low TPS of base rollup, especially in gaming, rollup must adopt some form of modular architecture to move execution to other environments (such as L3).

• Each general-purpose rollup has inadvertently formed a different culture and ecology due to different incentive mechanisms and other methods of bringing users and developers onto their chain.

The same is true for L1. Some applications and users only exist on Avalanche C-Chain or BNB or Sui and Aptos.

The fragmentation problem affects not only users, but also the execution layer and the protocol itself. Due to fragmentation, the revenue and MEV of the execution layer will be swallowed up by rollups (in the case of MEV) or other chains. This becomes more important as competition between execution layers intensifies.

The situation is very challenging for protocols because they must launch on numerous chains and try to guide liquidity and users on all chains. This is especially difficult for new products, as their goal is to get as many users as possible. Additionally, every underlying chain that a protocol runs on and every bridge integration adds complexity and security risks.

Fragmentation in crypto in general, and in Ethereum in particular, is at an all-time high, which leads to less than optimal user experience and traffic.

Solving Fragmentation: Chain Abstraction

This fragmentation problem gave rise to the idea of ​​chain abstraction. As mentioned earlier, we have chain abstraction as the ultimate goal: crypto users can get a better experience that is truly optimized without having to deal with the myriad of issues associated with bridging, gas payments, complex UIs, and multi-chain wallet management.

There have been a number of attempts to achieve the ultimate goal of chain abstraction, ranging from comprehensive solutions like AggLayer, Particle Network, and OP Superchain to component solutions like intent networks and bridge aggregators.

Often, and ironically, one of the key issues with chain abstraction has been the fragmentation of chain abstraction solutions. Often, we see chain abstraction solutions trying to “own” the chain being abstracted. For example, both Polygon’s AggLayer and Optimism’s Superchain attempt to abstract the rollup fragmentation problem by unifying liquidity, messaging, bridging, or other components. However, both require chains to choose their solutions, which comes with the problem of incentive misalignment. In the end, often all chains want to have their own stack.

In addition, they don’t work well together. While rollups on Polygon’s AggLayer benefit from unified liquidity, and Superchain’s rollups benefit from unified messaging and interchangeable applications and resources, users still face a poor user experience if they want to interact with both at the same time.

In addition to the fragmentation problem of some abstract solutions, especially at the component level, another problem faced by chain abstraction is related to the way it is handled.

The reality is that chain abstraction is a multifaceted problem that can be approached from many different angles: both what problems should be solved and how they should be solved.

There have been some strong efforts to outline how chain abstraction should be approached, the most prominent of which is the CAKE framework proposed by Frontier Research. We strongly encourage readers to read through the CAKE framework for themselves, but in general, Frontier outlines that the Chain Abstraction Key Elements (CAKE) framework consists of three infrastructure layers: the permission layer, the solver layer, and the settlement layer.

The permission layer is where users connect their wallets to protocols and applications and submit intents, and users sign messages here. The permission layer is responsible for identifying users' assets and executing transactions.

The solver layer includes solvers and fulfillers, who provide quotes and execution intents based on fees and execution speeds estimated based on the user's assets and intent.

The settlement layer ensures the user's transactions. If the transaction is set to occur on a different chain than the original chain, it bridges the assets to that chain and executes them.

Instead of the CAKE framework, we think a more practical approach can help visualize the evolution of chain abstraction. In simple terms, we divide chain abstraction solutions into two categories: comprehensive solutions and component solutions, each of which has further subcategories.

7. Comprehensive Design Space vs. Component Design Space

Given that the term chain abstraction (CA) is quite vague, let’s split the design space into two – comprehensive CA solutions and component CA solutions. Comprehensive CA solutions are defined as solutions that seek to abstract multiple frictions, providing a “full stack” solution for CA. Comprehensive solutions are similar to monolithic blockchains in terms of user experience. Component solutions are solutions that attempt to solve a single problem, making their own contribution to a larger solution. It is important to note that this report does not delve into every solution related to chain abstraction. Chain abstraction is a broad concept that is more of a motivation and end goal than a category. The protocols, networks, infrastructure layers, and EIPs discussed below help clarify and represent how certain types of solutions help chain abstraction. Chain abstraction has been extensively researched over the past few months, and there has been a lot of discussion about it at the recent crypto summits, during which many protocols, infrastructure projects, and researchers have focused on chain abstraction in one way or another.

8. Comprehensive Solutions

There are several big companies in the field of comprehensive solution design - NEAR, Particle, Okto, Polygon AggLayer, and OP Superchain. These 5 solutions can be further subdivided into ecosystem-independent solutions (NEAR, Particle, Okto) and ecosystem-specific solutions (AggLayer and Superchain). In short, the difference between the two lies in the scope of the CA solution.

All chains on the Polygon AggLayer are connected by a bridge contract, which makes the value transfer between chains in this ecosystem frictionless, but such user experience is limited to users of Polygon CDK L2. The design of OP Superchain is similar, with a unified bridge contract connecting all chains in the ecosystem, making the value transfer between them quite simple. Ecosystem-agnostic solutions provide a solution that is not limited to their own ecosystems, and users are able to transfer value between different chains and trade on different chains. All three ecosystem-agnostic solutions abstractly perform the role of transferring assets on other chains on behalf of users - essentially, this is their main product. Chain abstraction solutions like NEAR have been in the works since 2018, while other protocols are relatively new to the abstraction space. Given that most CA solutions are still in the early stages of their development process, and the diversity of approaches, it is difficult to single out a leader. To identify leaders in this space, one can consider the usage of each protocol’s main product, but once again, given that these protocols are still in their early stages of development, it is indeed too early to make a comparison.

(1) Particle

As the settlement and coordination layer for all on-chain users, Particle’s modular L1 (which can be thought of as a bottom-level infrastructure layer rather than a general-purpose L1) is designed to provide a chain abstraction experience for crypto users.

Particle's main product is Universal Accounts - allowing users to operate on all chains (EVM and non-EVM chains) with a single address, account balance and interaction point, while abstracting gas and unifying liquidity. Built on the Cosmos SDK, Particle is modular in nature, thus retaining sovereignty while outsourcing key functions such as validation and data availability to professional players. Modularity in nature refers to its ability to handle different aspects of blockchain operations through interchangeable independent modules. This allows Particle to maintain control over its core functions and governance, while also being able to adapt and evolve its modules.

Particle relies on 3 core modules:

• Universal Accounts: These accounts provide a single point of interaction, user addresses and balances across all chains (EVM and non-EVM networks).

• Universal Liquidity: Unifies liquidity across all chains through optimistic execution of cross-chain atomic trades and swaps. This allows users to interact with new chains seamlessly, even if they do not hold tokens.

• Universal gas: allows users to use any token for cross-chain transaction payments.

Universal liquidity

The universal liquidity of the Particle network acts as the underlying layer to support seamless atomic cross-chain interactions, unifying the balances in universal accounts. Through the implementation of universal liquidity, users using cross-chain applications have an experience similar to interacting with a single chain.

Universal liquidity - a typical example:

• User A wants to use his USDT to buy an NFT with a price of 1 ETH on chain 4, and the USDT is randomly distributed on chain 1, chain 2, and chain 3.

• By clicking the "Buy" button, the user packages the UserOperations involving 5 chains (chain 1, chain 2, chain 3, chain 4, and the Particle network) into one signature and sends it to Particle L1.

• After executing the above signatures, USDT on Chain 1, Chain 2, and Chain 3 are exchanged for intermediate tokens, such as USDC, through the DEX (decentralized exchange) of the corresponding chain.

• USDC on Chain 1, Chain 2, and Chain 3 are sent to liquidity providers (LPs).

• LPs release USDC on Chain 4.

• USDC on Chain 4 is exchanged for ETH through the DEX on Chain 4.

• ETH on Chain 4 is used to purchase NFTs.

Universal Accounts

Particle's Universal Accounts play a core role in Particle's chain abstraction products, they provide users with a single address, balance, and interaction point across multiple chain ecosystems. Particle Universal Accounts automatically perform cross-chain atomic transactions using Universal Liquidity and pool funds from users' cross-chain balances to meet the conditions of a given operation. Universal Accounts provide users with a unified interface within the EVM and non-EVM ecosystems and provide them with the ability to store and use funds on any blockchain. At the core of Universal Accounts is Particle Universal Liquidity technology, which automatically coordinates cross-chain transactions on a per-transaction basis. The Particle network acts as a settlement layer for these transactions.

A generic account is essentially an ERC-4337 smart account implementation attached to a pre-existing EOA (external address). The protocol implementing Particle's generic SDK will allocate or resolve a generic account attached to a given EOA address, queried via social login using the Particle network's modular smart wallet-as-a-service. The account is then used as the core interface for interacting with the application, as well as any other application leveraging the Particle network SDK.

Hypothetical example about an end user:

• Alice discovers a Play to Earn dApp. The dApp is hosted on Arbitrum and leverages the Particle network’s Universal SDK to implement Universal Accounts.

• Alice starts using the dApp. The assets in her wallet (Polygon native) are used for basic dApp interactions. Bridging is automatic and is performed automatically upon interaction.

• After playing around for a while, Alice earns some tokens. She uses the money to buy an NFT as a birthday gift for her friend Bob. Unbeknownst to her, the NFT is hosted on Optimism. She can seamlessly send the money to Bob’s Universal Account. Importantly, Alice only used one gas token throughout her entire experience.

• Bob decides to collateralize the NFT on Solana for a loan and use the proceeds to buy a meme, Bitcoin Ordinal. He does this all in a few minutes and with a few clicks from the same account.

Bitcoin, Particle, and Account Abstraction (AA):

The introduction of inscriptions and ordinals kicked off a resurgence of activity on Bitcoin’s L1.

Various Bitcoin L2s have emerged that extend computational limits beyond the Bitcoin base chain, examples of which include EVM-compatible BTC L2s such as Merlin, BEVM, and bSquared. This represents a leap forward for Bitcoin and the industry as a whole, but their design and supporting infrastructure still result in considerable friction at the wallet and UI/UX level when interacting across networks.

This is where Particle and BTC Connect come in, aiming to resolve the friction while bringing the benefits of account abstraction to Bitcoin. BTC Connect achieves account abstraction on the Bitcoin network by unifying users' Bitcoin accounts and EVM-based smart accounts. This is done by using a Bitcoin wallet as a Signer for smart accounts on Bitcoin L2 or EVM networks, making the user's existing Bitcoin wallet the only point of interaction. The architecture leverages the EIP-4337 design (supporting multi-signature wallets, social recovery, and more complex transaction logic at the wallet level) and EVM-compatible chains, introducing smart accounts, paymasters, bundlers, and unique Bitcoin-specific wallet connection modes.

Thus, all interactions on smart accounts and original Bitcoin wallets can be controlled through the Bitcoin wallet interface. BTC Connect extends the functionality of Bitcoin wallets. Using a single Bitcoin wallet, users can send native BTC transactions, interact with ordinals, and execute logic on compatible EVM dApps and Bitcoin L2.

This allows builders in the Bitcoin ecosystem to provide users with gas-free transactions, account programmability, and many other abstract features.

The public key of the Bitcoin wallet is used to execute native BTC transactions and generate an EVM EOA. This EOA is used to create a smart account with the Bitcoin wallet as the signer, so the Bitcoin wallet signature is compatible with the EVM.

(2) NEAR

NEAR is developing a comprehensive chain abstraction stack with a focus on account aggregation. The ability to conduct transactions on any blockchain through a single account and interface is a key component of chain abstraction. This will clean up Web3 fragmentation for app users and improve their ability to flow across networks or applications.

NEAR account aggregation includes 3 core technologies:

• NEAR Accounts — NEAR is built using native account abstraction, so NEAR accounts map to human-readable account names instead of public key hashes. In addition, NEAR accounts can hold multiple keys with different permissions for different functions. FastAuth provides users with a Web2-like onboarding process where users sign up with emails without having to manage private keys. FastAuth accounts and keys are protected by a biometric “Passkey” security feature (think FaceID). Users can also recover their accounts at any time using emails through a multi-party computation (MPC) recovery service.

• Chain signatures - This allows any NEAR account to control addresses on other chains. Using chain signatures, the NEAR MPC network is a signer of transactions on other chains without having to manage different wallets and private keys. MPC signatures allow multiple independent nodes to sign messages using key shares generated individually by untrusted parties without having to aggregate them anywhere.

• Intent Relayer - In pursuit of a smooth user experience, users should be able to make payments on the NEAR network and then be able to trade value on other chains. With an intent relayer, users can specify what they want to do without knowing exactly how it is done. The intent relay network is tasked with monitoring responses from MPC services, processing signed transactions, submitting them to their respective chains, and then completing the final transaction.

(3) Okto

Okto is a middleware solution that aims to simplify the complexity of Web3 for developers and end users. It abstracts the complexity of blockchain interactions, making it easier to build and use decentralized applications. Okto believes that an end-to-end solution is needed to address both development experience and user experience challenges. For this purpose, they launched an orchestration layer that abstracts the complexity of Web3 and addresses development/user experience by addressing the three challenges of the fragmentation problem: liquidity, technical standards, and user experience.

Components of the Okto Orchestration Layer:

• Okto Appchain - A middleware chain that coordinates transactions without holding user assets or total locked value (TVL). It acts as a rollup-based application chain that inherits trust from the underlying secure/scalable blockchain. Key subcomponents include the Bloc Hub and a unified set of application development APIs.

• Decentralized Wallet Network (DWN) - Supports unified wallet accounts secured by MPC and allows user-permissioned delegated signatures, supporting EVM and non-EVM chains.

• Decentralized Trading Network (DTN) - Coordinates asynchronous transaction management across multiple blockchains and handles sub-transactions of user operations, including nonce management, gas fee estimation, and data indexing.

Okto aims to provide a chain abstraction solution through its orchestration layer, which consists of application chains, DWNs, and DTNs. This layer abstracts the complexity of standards, chains, and protocols, providing a consistent development experience. It allows developers to build dApps using simpler primitives and better user experience, focusing on their core products, while chain-related complexities are managed by Okto.

9. Specific Ecosystem Solutions/Aggregate Blockchain

Aggregate blockchain can be thought of as a blockchain expansion solution that provides the secondary advantage of chain abstraction. It stands to reason that we will find ourselves in a multi-chain world, and no single chain currently supports the throughput required to achieve mass adoption. To scale blockchains, we need to increase access to liquidity and shared state — if increasing block space destroys liquidity, then it is not a viable solution. This is the idea behind aggregated blockchains.

（1）Polygon AggLayer

Before we delve into the Polygon AggLayer, it is necessary to take a quick look at the Polygon ecosystem:

• Polygon = An aggregated blockchain global network

• AggLayer (unified liquidity) = A protocol that unifies the liquidity of multi-chain networks by aggregating proofs from all associated chains, ensuring the security of near-instant cross-chain atomic transactions.

• Polygon CDK (Extension) = A modular collection of open source tools that allows developers to deploy their own sovereign ZK (zero-knowledge proof)-driven L2, or allow existing L1 and L2 chains to migrate to AggLayer.

Polygon expounds on the concept of chain abstraction from a different perspective, and their unified bridge contract provides the benefits of integrated (monopoly) and modular architecture by using ZK technology. AggLayer is the interoperability layer for CDK chain connections, enabling features such as seamless and efficient cross-chain communication and unified liquidity. This achieves unified cryptographic security and atomic composability between aggregated chains without sacrificing sovereignty. Polygon claims that, similar to TCP/IP, AggLayer will unify the blockchain landscape into a network consisting of L1 and L2 chains with zero-knowledge security guarantees.

AggLayer functions in three phases - assuming chain A is a ZK-driven chain running in the Polygon ecosystem:

• Pre-confirmation: Chain A submits the header of a new block/transaction package A1 to AggLayer, along with a light client proof. The header file contains commitments to all other blocks and transaction packages that A1 depends on (Bi, Ci, etc.). When a new transaction package is received without a validity proof, it is considered "pre-confirmed" by AggLayer.

• Confirmation: Chain A or any full node of A generates a proof of A1 and submits it to AggLayer. Once the proof is verified by AggLayer, A1 is confirmed if all the transaction packages it depends on are also confirmed.

• Finality: After A1 is confirmed, its proof is aggregated with transaction packages from other rollups into a single proof and published on Ethereum. The aggregate proof enforces consistency between dependent chain states and transaction packages.

Seamless, efficient cross-chain communication and unified liquidity - in practice:

Imagine an example where Alice on chain A wants to lock or burn some tokens in block A1 in order to mint assets and transfer these tokens to Bob on chain B. Chain B needs to wait until these A1s are finalized on Ethereum and provide valid proofs before minting assets, which is a slow process. AggLayer solves this problem by allowing chain B to temporarily assume that A1 is valid and will be finalized on Ethereum. Chain B's sorter submits the declared chain A state root A1 as a dependency of B's ​​block header (B1A1) to AggLayer before submitting it, reducing the latency required for chain B to build B1 from 20 minutes to a few seconds.

AggLayer's unified bridge provides a bridge contract on Ethereum for all associated chains. Each chain has a local copy of the unified bridge root, enabling cross-chain transactions without exiting to Ethereum and without the security risks of third-party bridges. AggLayer also includes a bridgeAndCall() Solidity library - this allows developers to deploy program logic that executes calls on different chains. Users can transfer assets to different chains and also trigger contracts on the target chain. In theory, this provides a user experience similar to that of a single chain.

So, how does AggLayer support chain abstraction? At a high level, AggLayer will enable near-instant atomic transactions and unified liquidity across the entire ecosystem, creating better capital efficiency and providing an improved user experience. L1 and L2 connected to AggLayer can leverage unified liquidity, developers can reach a wider range of users, and users can interact through a user experience similar to Web2.

(2) Optimism Superchain

OP Superchain is a chain network that shares bridging, decentralized governance, upgrades, communication layers, etc., all built on the OP Stack. The launch of the superchain merges the OP mainnet and other chains into a unified OP chain network (many chains form a superchain). Unlike multi-chain designs, the chains that make up a part of the hyperchain are standardized and intended to be used as interchangeable resources. Therefore, applications can be built that target the entire hyperchain - the underlying chain on which the abstract application runs.

OP Stack:

• The Data Availability (DA) layer stipulates that the original input of the chain based on the OP Stack mainly comes from Ethereum data availability.

• The sorting layer controls how user transactions are collected and forwarded, and is usually managed by a single sorter.

• The derivation layer processes raw data as input to the execution layer, mainly using rollup.

• The execution layer defines the system state structure and transaction functions. EVM is the central module.

• The settlement layer allows external blockchains to view the valid state of the OP Stack chain through proof-based error proofs.

10. Component solutions

(1) Intent

An intent is an order in which the user specifies the desired result rather than a specific execution path. Users do not need to specify every step of the transaction, but simply state what they want to achieve. External agents called "solvers" or "fillers" then compete to find the most efficient way to fulfill this intent, usually for a fee. They can be viewed as similar to limit orders, but can be applied to a variety of situations (not just trading), such as bridging.

In general, intent protocols follow a similar structure:

• Intents are submitted by users. Each intent comes with specifications related to the user's goal: desired size, target chain, target asset, requested price, desired solver (for certain intent networks), etc.

• Solvers and fillers monitor intents across different intent networks using subgraphs, event listeners, etc.

• Solvers/fillers can choose to complete the user's intent.

The above structure varies across different protocols and use cases, especially in terms of what assets the solver/filler uses, whether they are locked, and where they come from.

Generally, intent protocols fall into two categories:

• Intent-based transaction protocols

• Intent-based bridge protocols

For all intents and purposes, they actually have the same functionality, allowing users to submit intents and potentially be executed on or through different chains.

Intent-based bridge protocols

Historically, bridging requires moving assets directly between chains, which is expensive, complex, and insecure. Generally speaking, traditional bridges can be based on mint and lock, mint and lock, or LP mechanisms, which can lead to problems such as unlimited minting or utilizing liquidity pools or locking mechanisms.

Intent-based bridges, in contrast, rely on users expressing their intent and owning tokens on a separate chain. Solvers can fulfill this request for users on the target chain, using their own funds. The solver is then rewarded on the original chain.

Intent-based bridging avoids the need to mint or lock tokens, thereby mitigating some of the issues that can arise from this. However, it also has its own disadvantages, more specifically, fillers/solvers may face problems due to failed transactions and chain reorganizations or rollbacks.

Similar to traditional bridging, intent-based bridging must also consider liquidity constraints. Intent solvers/fillers need to maintain liquidity on multiple chains to execute and complete transactions, while also rebalancing these funds regularly. In addition, fillers/solvers face funding costs and gas costs (especially on the target chain).

The benefits of intent-based bridging are obvious:

• They abstract the backend from the end user. From the user's perspective, intent-based bridging happens behind the scenes, and the user only needs to consider paying fees to the protocol and solver.

• They are often faster and easier than traditional bridges because they use fewer computing resources and require less waiting time.

By far, the largest intent-based bridge protocol is Across. Since November 2021, the protocol has bridged over $10 billion in transaction volume across the chains it supports.

Across

Across enables cross-chain asset transfers through an intent-based system. Users store assets on a chain and specify their target chain. Independent relayers then fulfill these requests by sending funds to users on the target chain. The protocol verifies these fund transfers and compensates relayers.

The Across protocol relies on several key mechanisms to enable cross-chain asset transfers. The first is the relayer mechanism. Relayers observe when users deposit funds into the original chain and then send the requested funds to users on the specified target chain. They can use their own funds to execute requests, so they may face liquidity constraints. However, Across also has a liquidity pool system as a backup solution for intent. After an intent is completed, the data workers and optimistic oracle system must verify that the intent was completed so that the relayer can be compensated.

Data workers are whitelisted participants who reimburse or provide financial compensation to relayers, rebalance liquidity pools between chains, and occasionally perform slow executions (relayers complete fast executions and compete with each other on speed to earn fees). They also monitor the intents that Across has executed and propose transaction packages to the Optimistic Oracle. The optimistic oracle can then verify the transaction packages proposed by the data workers (after a one-hour dispute window).

Across V3 focuses on building applications beyond bridge applications and focuses on more complex cross-chain interactions. Across+ allows protocols to combine the Across bridge infrastructure with other transactions and include them in a single transaction. For example, an NFT marketplace can allow users to combine bridge and mint or bridge and buy interactions into a single transaction. This greatly reduces the number of clicks for users and potentially saves gas costs, alleviating other user experience issues such as not having assets on the target chain. In addition to Across+, the protocol has also launched Across Settlement, which performs settlement of cross-chain transactions by allowing cross-chain settlement logic to be implemented at the protocol level. With Across+ and Across Settlement, Across aims to move from intent-based bridging to more complex cross-chain interactions, attempting to become a more modular component of cross-chain transactions rather than just bridging.

Across is particularly important in intent-based architectures and protocols as they have been working on standardization of cross-chain intents. UMA, the team behind Across's optimistic oracle, along with Uniswap, launched ERC-7683 earlier this year to establish a standard API interface for cross-chain intents. ERC-7683 focuses on creating a standardized API interface for cross-chain intents, aiming to enhance interoperability between different cross-chain intent systems in the following ways:

• Define a standard CrossChainOrder structure to represent a cross-chain order.

• Specify the ISettlementContract interface for the settlement contract.

deBridge

Similar to Across, deBridge uses solvers and intent-based architectures to enable cross-chain asset transfers and smart contract interoperability. It consists of two layers: the protocol layer and the infrastructure layer.

The protocol layer is located on the chain and consists of a set of smart contracts that exist on the supporting chains. It handles the locking and unlocking of tokens involved in cross-chain transactions, sends transactions from the source chain to the target chain, and verifies validators to ensure the legitimacy and authenticity of transactions. Validators, as part of the infrastructure layer, exist off-chain. The infrastructure layer consists of validators operating deBridge nodes and full nodes of supporting chains, the former processing and signing cross-chain transactions, and the latter allowing validators to monitor and fully verify transactions.

The deBridge liquidity network is built on top of these two layers of architecture. It enables users to create limit orders (similar to intents) for cross-chain transactions. Similar to how Across works, DLN allows users to submit intents, including the target chain, token, size, and recipient address. Off-chain solvers can fetch intents on the target chain to fulfill them. In order to fulfill an order, the solver needs to provide details about the intent to the smart contract, which needs to verify that the order to be executed matches the submitted order. If the order is verified, the contract will extract the necessary number of tokens from the solver address to fulfill the intent and send it to the recipient address.

Intent-Based Trading Protocol

Intent-based trading, similar to bridging, relies on professional solvers and market makers to find the best execution path. A key benefit this provides to users is that it allows user needs to be fulfilled not only on a separate target chain (similar to how bridging works), but also from a separate chain to the origin chain. This greatly increases liquidity as it enables users to access shared liquidity and execution across multiple blockchains and allows them to potentially access off-chain liquidity.

In addition to benefiting from shared liquidity, intent-based trading also allows users to potentially merge complex and previously multi-trade programmatic orders and conditional executions into a single trade. For example, for assets that may not even exist on the original chain, users can implement conditional orders based on time, quantity, or price with a single trade. In addition to these relatively simple order types, intent-based trading can even allow users to execute trades based on the price action of other trades, allow users to execute a series of trades in a specific order, and even allow trades to be triggered based on off-chain data.

Finally, intent-based trading makes gasless trading possible (to a certain extent). Users may still need to approve tokens to be traded, but protocols like Matcha (0x) allow users to sign gasless transactions that only submit intents. This allows users to not have to worry about gas fees. In addition, users usually have to pay gas fees for failed trades, which can be alleviated by intent-based design.

In addition to simplifying the user experience and alleviating some of the UX issues associated with trading, intent-based trading can also improve capital efficiency. Solvers, who are responsible for completing trade orders, only need to invest funds when they actually complete the order. This on-demand capital commitment enables solvers to manage their resources more efficiently and participate in a wider range of markets without increasing capital requirements. As a result, competition between solvers may increase, which may result in better prices and liquidity for traders in various markets.

Everclear

Everclear is an intent-based solution that solves the limitations of rebalancing and settling liquidity between chains. They propose a new primitive, the clearing layer, that allows market participants to access net fund flows between chains before final settlement with the underlying chain and bridges. Everclear's clearing layer is built as an Arbitrum Orbit rollup (via Gelato RaaS) and connects to other chains using Hyperlane with feature layer ISM.

In summary, the "rebalancing problem" can be understood as: in the process of executing intents, solver funds are moved from chains that need them to chains that need them less. In order to rebalance effectively, solvers must integrate with bridges, aggregators, CEXs, OTC desks, and any other available liquidity sources for each supported chain and asset. The rebalancing process is expensive, and these costs are ultimately passed on to users.

This is where Everclear comes in, providing a shared system for all market participants to coordinate capital flows and support cross-chain settlement. Of all cross-chain flows, an astonishing 80% can be deducted - this provides a huge opportunity to reduce costs for end users. Perhaps the solution to liquidity fragmentation is not to build another bridge or liquidity layer, but to help existing participants coordinate better.

Deposits in this system generate invoices on the Everlear rollup, which represent the system's obligations to settle with users (backed by funds locked in the gateway). A typical example is as follows:

Suppose Alice and Bob are solvers for UniswapX and Across respectively. Alice prefers Arbitrum, while Bob prefers Optimism.

• Alice executes an Optimism-Arbitrum trade for 10 ETH. Bob executes an Arbitrum-Optimism trade for 20 ETH.

• Suppose the funds from the two original trades (10 ETH and 20 ETH) are deposited into Everclear on Optimism and Arbitrum respectively.

• Everclear uses 50% of Bob’s 20 ETH deposit to immediately settle Alice’s 10 ETH to Arbitrum at nearly zero cost.

• Everclear wants to settle Bob’s trade, but only 10 ETH is available for settlement on Optimism. The system auctions off his invoice, discounting its price from $1 to $0.99.

• Charlie notices this and deposits 9.99 ETH on Optimism. Everclear settles Bob’s trade on Optimism for 19.99 ETH. Charlie now holds an invoice for 10 ETH, making a profit of 0.01 ETH.

Both Alice and Bob eventually return to their respective chains, ready to complete more trades. Importantly, this happens with zero operational work and near-zero cost.

IntentX

IntentX is an intent-based perpetual contract trading platform where traders express their desired outcomes (intents) which are then fulfilled by market makers known as solvers.

The platform leverages SYMMIO as a settlement layer, using SYMMIO-Core contracts to settle trades and facilitate direct on-chain bilateral trade agreements. SYMMIO is an intent-based on-chain peer-to-peer derivatives trading backend that enables OTC derivatives trading through symmetric contracts, a set of trustless and permissionless smart contracts based on bilateral agreements.

These symmetric contracts continuously monitor the solvency of all participants and mediate any parameter disagreements. This ensures trustless and permissionless settlement of derivatives between parties. Essentially, SYMMIO pairs a requester with a responder, locking them into an isolated symmetric transaction. This looks similar to how intents are implemented on Across or deBridge:

• A user submits an intent, specifies position details, and whitelists solvers.

• Whitelist solvers monitor intents using subgraphs or event listeners.

• The first solver to lock onto an intent can open a position if it fits their strategy. Solvers can hedge positions in the secondary market, or choose not to hedge.

• Open positions include intent ID, transaction amount, average price, and oracle signature.

• Oracle signatures ensure solvency of traders and solvers, preventing positions from being closed.

One of the main benefits provided by IntentX/SYMMIO is the ability to obtain liquidity from other chains or even CEXs. Since solvers can obtain liquidity from multiple sources and leverage cross-chain liquidity pools, users can get better prices and can complete large orders with minimal price impact.

Typically, without intent-based trading, users would have to bridge to obtain liquidity from other chains, increasing complexity on the user side. This complexity and risk is passed on to solvers, who may have to hedge their positions and receive a taker fee in return for fulfilling the intent.

(2) Account abstraction

Account abstraction allows users to store their assets in smart contract-based wallets instead of in EOAs (external accounts). This greatly enhances programmability and functionality.

EOA and Smart Contract Accounts

EOA and Smart Contract Accounts are the two main types of accounts in the blockchain, each with different characteristics and specifications. EOA accounts are controlled by private keys and provide direct user control, while Smart Contract Accounts are managed by on-chain smart contracts and provide programmability.

EOA is created off-chain by generating a public-private key pair (a typical wallet setup process), which does not incur any fees. In contrast, Smart Contract Accounts are created on-chain through transactions, which require the payment of gas fees.

While EOAs provide basic and essential functionality for blockchain interactions, such as sending transactions, interacting with smart contracts, and managing native assets, smart contract accounts can perform more complex operations based on their programming logic, allowing complex automated transaction types and on-chain interactions. This is because smart contract accounts contain EVM code and storage, enabling them to perform complex operations and maintain state on the blockchain.

Gas fee management also differs between these account types. EOAs require native tokens to pay gas fees, which requires users to maintain native token balances for transactions. Smart contract accounts may use other fee mechanisms that provide greater flexibility in how transaction costs are handled. The payment system introduced by ERC-4337 and EIP-7702 is an example of this, which supports gas payment subsidies.

Account abstraction may seem to be only slightly related to chain abstraction, as it does not directly abstract cross-chain interactions. However, it introduces several key improvements to the user experience that support chain abstraction.

It allows users to interact with protocols and chains without having to pay gas fees or manage their private keys, simplifying the bootstrapping process of new chains and appchains. Protocols and chains can pay users' gas fees, and paymasters allow cross-chain gas payments, allowing fees on the target chain to be paid with tokens on different chains. Gas abstraction allows users to pay transaction fees with one token on different chains, which is done by relayers who handle gas payments.

In addition, multiple transactions can be combined into a single transaction through transaction batching, reducing overall gas costs. Meta transactions allow users to sign messages off-chain and have third parties submit transactions, which may enable gas-free transactions from the user's perspective. Wallets can be programmed to automatically execute certain transactions based on predefined conditions, even on different chains. Interoperable smart contracts can interact with contracts on different chains, allowing for simplified cross-chain atomic transactions.

A general problem with implementing account abstraction in Ethereum and the EVM is that the base layer is very important given the large number of assets that exist on it. Making changes at the protocol layer is very difficult and can be extremely costly, and this cost can often be avoided. This is one of the main reasons why account abstraction has not yet fully prevailed on the EVM, and only smaller chains can implement it in a more flexible way (for example Polygon PoS has implemented some account abstraction principles).

ERC-4337

ERC-4337 was co-authored by Vitalik Buterin, Yoav Weiss, Kristof Gazso, Dror Tirosh, Shahaf Nacson, and Tjaden Hess.

It introduces account abstraction while avoiding changes at the Ethereum protocol level to reduce the possibility of introducing vulnerabilities at the consensus level. Instead, ERC-4337 introduces account abstraction using the Alt memory pool.

ERC-4337 introduces several new components for account abstraction. UserOperations allow users to package transactions together instead of manually executing a series of transactions one after another. The simplest example is token approval and token swap, which usually require two separate transactions to complete, but can be packaged into a single transaction. The Bundler (usually a validator or searcher) receives submitted UserOperations and packages and submits them along with other transactions. The submission of UserOperations can be handled by a contract account, which can programmatically initiate transactions based on a set of instructions or goals.

Finally, ERC-4337 introduces paymasters smart contracts, which can implement flexible gas policies, such as allowing dApps to sponsor operations for their users (theoretically supporting free transactions), or accepting the use of ERC20 (such as USDC) instead of the blockchain's native currency (ETH) to pay gas fees.

Paymasters can pay user operation fees and reimburse the bunders who performed these operations on behalf of the sender.

This process involves several steps:

* Verify the user operation on the sender's wallet.

* Verify the paymaster operation if a paymaster address is provided.

* Abandon all user operations that failed verification.

* Execute the user operation on the sender's wallet.

* Tracks gas used for execution.

* Transfers ETH to bundler to pay for gas used.

* If a paymaster is involved, the ETH in that paymaster contract is used to pay for gas.

* If no paymaster is used, the sender wallet is reimbursed for ETH.

Paymasters remove friction from the user experience and open up new models for users, allowing them to pay network fees with non-gas tokens, or even ask third parties to pay for those fees.

EIP-7702

EIP-7702 introduces a new transaction type that allows EOAs to temporarily act as smart contract accounts.

It does this by adding a "contract_code" field that allows EOAs to adopt smart contract code and functions in a single transaction, enabling features such as gas sponsorship and batch transactions without having to permanently migrate to smart contracts.

Building on the EIP-3074 concept, EIP-7702 takes a more conservative approach, making upgrades more transient and avoiding the introduction of new opcodes. The proposal introduces key features such as batching (allowing the same user to perform multiple operations in one atomic transaction), sponsorship (allowing one account to pay fees for a transaction on behalf of another account), and privilege downgrade (allowing users to sign subkeys with specific, limited permissions).

It is designed to be forward compatible and consistent with ERC-4337, allowing existing wallets and infrastructure to take advantage of the temporary upgrade mechanism. The proposal makes minimal changes to the Ethereum protocol, focusing on the core functionality of temporary smart contract account upgrades. In practice, an EOA obtains a temporary account code for a transaction, which is executed when the transaction is sent, performing operations like a smart contract. After the transaction is completed, the account code is deprecated, restoring the EOA to its original state. It is expected to be included in the upcoming Ethereum network upgrade, the Prague/Electra (Pectra) upgrade.

Similar to ERC-4337, EIP-7702 allows a third party (paymaster) to pay transaction fees on behalf of users.

With paymaster under EIP-7702, users do not need to hold any ETH to interact with Ethereum-based protocols. Instead, the paymaster contract will pay the gas fees.

Compared to ERC-4337, the gas sponsorship mechanism in EIP-7702 is more flexible. It supports a variety of sponsorship models:

• Free sponsorship: An application may pay all gas fees for its users to encourage user adoption.

• Fungible token payments: Users can pay gas fees with ERC-20 tokens instead of ETH. Paymaster will accept these tokens and pay the actual gas fees in ETH.

• Subscription model: The service may offer gas sponsorship as part of a subscription package.

• Conditional sponsorship: Paymaster can set conditions for paying gas fees based on transaction type, user behavior, or other factors.

(3) AI Agents

AI agents are on-chain entities that are able to take actions after receiving commands, prompts, or intentions from external actors (i.e., users).

They are general-purpose artificial intelligence systems designed to interact with on-chain smart contracts. They can be user-controlled or autonomous. They can autonomously perform complex multi-step tasks, interact with smart contracts and protocols, provide personalized help and advice to users, and generate and execute blockchain transactions based on user input. They are designed to easily navigate the crypto environment, including understanding on-chain interactions and mechanisms, wallets, protocol mechanisms, DAOs, and smart contracts.

The key components of the on-chain AI agent can be divided into the following three basic things:

• User crypto wallet: This is the foundational element for secure key management and transaction execution. The crypto wallet enables users to sign and authorize transactions recommended by the AI ​​agent, ensuring safe and verified interactions with blockchain-based applications.

• Specialized crypto-centric language model: The intelligent core of the agent is a large language model (LLM) that has been specially trained on a wide range of crypto datasets. This includes comprehensive information about blockchains, wallets, decentralized applications, DAOs, and smart contracts. The specialized training enables the agent to effectively understand and navigate the complex crypto environment. More importantly, the LLM is fine-tuned to evaluate and recommend the most suitable smart contracts to users based on predefined criteria, focusing on security.

• Long-term memory system: This component involves storing user data and information about associated applications locally or on a decentralized cloud. It provides a broader context for the AI ​​agent’s behavior, enabling more personalized and accurate assistance based on historical interactions and user preferences.

AI agents offer several key improvements, including enhanced privacy and data control for users, improved incentive alignment between users and agents, and the ability to autonomously transfer value.

But perhaps most importantly, they have the potential to greatly simplify and improve the experience for crypto users, especially in the context of cross-chain interactions. Instead of manually navigating between different chains and tokens, users can simply tell their AI agent: “Convert $100 worth of ETH to USDC and send it to Alice,” and the agent will then handle the technical details to ensure the most liquid and cheapest path is taken. In addition to simple interactions, they can also complete more complex operations such as yield farming or cross-chain LP rebalancing, all without the user having to actually do a lot of clicks, because the user can give the agent natural language commands.

Unfortunately, AI agents and their potential on-chain applications are not yet truly viable. Recent AI agent protocols are not yet effective and have not yet reached their full potential. We highlight two protocols that we think may be relevant, but they are still in their early stages. One of the main concerns about AI agents, especially on-chain, is the potential for misbehavior, either malicious or accidental. Since users are allowing these agents to use their funds, it is understandable that they may be skeptical about whether to fully trust them, especially since AI models tend to hallucinate or not follow prompts and instructions. Some preventative measures can be taken to prevent this from happening, such as setting constraints or injecting prompts regularly to ensure correct behavior - but these are more of a stopgap measure.

However, AI agents represent a huge potential improvement to cross-chain interactions, potentially removing the need for on-chain interactions from users altogether, allowing them to only give prompts using natural language commands.

Wayfinder

Wayfinder is a chain-agnostic AI agent framework and toolkit designed to run only on the Solana blockchain. Its main function is to provide an interface for AI agents to interact with blockchain technology and execute transactions. To achieve this, Wayfinder deploys validating agents that evaluate and propose new interaction and execution paths for AI agents. These paths define the processes and steps that AI agents follow to execute specific transactions. While AI agents can use these paths to perform transactions, they operate under predefined constraints. They can only perform authorized actions, such as token swaps, and cannot use funds without owner interaction.

Morpheus

Morpheus is a protocol focused on incentivizing the development of AI agents. The project aims to develop a general-purpose peer-to-peer network of personal AIs that act as agents capable of executing smart contracts for individuals.

The Morpheus network involves four key stakeholders: coders who develop smart contracts, off-chain components, and agents; capital providers who stake stETH into the network's funding pool; computing power providers who provide computing power (mainly GPUs); and communities who create front-ends to interact with the network and its agents and work to expand the ecosystem. To align incentives for acquiring inferences, the project adopts the Yellowstone computing model, which operates under a simplified structure designed to manage resource allocation and usage within the ecosystem.

11. Conclusion

The proliferation of rollups, new chains, and application chains in the crypto space has led to severe liquidity and user fragmentation and a decline in user experience, due to well-intentioned efforts (continuous innovation and new improvements at the protocol level) and incentive misalignment (valuation premium for infrastructure).

This fragmentation, in turn, has led to a complex and often frustrating user experience, with users having to shuttle between multiple chains to bridge assets and manage different gas tokens. For developers, this means having to launch projects on multiple chains and try to guide liquidity and users on all chains.

Chain abstraction has emerged as a potential solution to these problems. It aims to provide such a user experience that allows users to avoid the manual operation process required to interact with multiple chains. This includes abstracting the complexity of bridging, gas tokens, account and wallet fragmentation, liquidity fragmentation, and key management. The goal is to create an experience similar to traditional Internet applications, where users can interact with blockchains without experiencing a steep and difficult learning curve.

Various chain abstraction approaches are under development, ranging from comprehensive solutions to component-level solutions. Comprehensive solutions like NEAR, Particle, and Okto aim to provide end-to-end abstraction across multiple chains. Ecosystem-specific solutions, such as Polygon’s AggLayer and Optimism’s Superchain, focus on unifying liquidity and improving interoperability within their respective ecosystems. Component solutions, such as intent-based protocols and account abstraction mechanisms, address specific challenges of chain abstraction.

Intent-based protocols, whether for trading or bridging, promise to simplify cross-chain interactions and improve capital efficiency. They allow users to express desired outcomes rather than specific execution paths, and solvers compete with each other to efficiently execute these intents. This approach has the potential to unify cross-chain liquidity and simplify complex cross-chain operations.

Account abstraction, especially through proposals like ERC-4337 and EIP-7702, provides improvements in user experience by supporting more flexible gas payment mechanisms and enabling smart contract functionality for standard accounts. These innovations can greatly reduce the barrier to entry for new users and simplify interactions across multiple chains.

The potential of AI agents in chain abstraction is particularly noteworthy. While still in the early stages of development, AI agents could revolutionize how users interact with blockchain technology by enabling natural language commands for complex cross-chain operations. This could greatly simplify the user experience and make blockchain technology accessible to a wider audience.

Chain abstraction is critical to the development of crypto technology, especially given that Ethereum has adopted rollups as its scaling plan and the modularization idea and the narrative of application chains are growing. By solving the fragmentation and complexity problems, chain abstraction can create a more unified and user-friendly on-chain experience. However, it is more important to note that chain abstraction itself faces challenges. Ironically, the fragmentation of chain abstraction solutions is a reflection of the problems they are trying to solve. Many of the proposed solutions are still in the early stages of development and face significant technical and adoption barriers.

It is worth noting that there has been a lot of research on chain abstraction in the past few months, and there has been a lot of discussion about chain abstraction at various recent crypto summits, during which time many protocols, infrastructure projects, and researchers have focused on chain abstraction in one way or another. Given this, it is likely that the user experience and fragmentation issues will be improved in the coming years.