Source: Digital Asset Research Company ASXN; Translation: Jinse Finance xiaozou
1 Introduction
The crypto industry is full of change, and one of the few constants is the growing number of blockchains. Whether it’s Ethereum L2, Lisk, or alt L1, there seems to be a constant stream of new blockchains emerging.
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 of 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. In order to solve the scalability trilemma, we have Solana , Cosmos and its application chain, Berachain and its PoL consensus mechanism, Ethereum L2 and fraud proofs, etc., each with its own unique way of innovation.
While innovation may be the primary driver behind the blockchain explosion, misaligned incentives are also partly to blame. Infrastructure trades at a higher premium than applications, so developers factor in fluctuations in valuation when deciding what to build and where to build it. This misaligned incentives has led to a myriad of blockchains or protocols that “own their own stack,” which is largely responsible for the crypto world we live in today.
2. The rise of modularity and rollups
The concept of modularity is a relatively new one, 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 division of labor is the source of economic growth, specialization (division of labor) drives scalability (growth) through increased 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 transaction package to the Ethereum mainnet, rollup increases transaction throughput while reducing transaction costs. This approach minimizes the amount of data processed on-chain, resulting in faster and cheaper transactions. However, as the number of rollups increases, the complexity of interacting with the Ethereum ecosystem will increase accordingly, 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.
To surpass Web2, Web3 UX (user experience) needs to provide an absolutely better experience (taking switching costs into account). 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 today’s crypto world, you need to bridge funds between many chains, navigate complex UIs, and pay for transactions with many different tokens, each with its own risk profile. 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 produces technology that hides these details and processes. These complexities still exist and play a role, but are invisible to the user.
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 conduct 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 go-to search engine, can be considered the ultimate abstraction. By acting as a broad guide to the internet, it simplifies the process of information retrieval, allowing users to enter search requests without having to understand the complexities of search algorithms or web crawling processes. Google’s algorithms index billions of web pages and rank them based on 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, as 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 layer". 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 removes the manual processes required for multi-chain interactions”
Let’s look at the problem that the chain abstraction tries to solve:
Bridging — Users need to connect value to different chains, which introduces both significant UX friction and security risks.
Gas tokens - Users need to obtain and manage different tokens on different chains to pay gas fees.
Account and wallet fragmentation — users need to interact with multiple accounts to access their full balance. This problem is exacerbated in non-EVM ecosystems because separate addresses and wallets are required.
Liquidity Fragmentation — As the number of blockchains increases, liquidity becomes fragmented and further isolated across these chains.
6. Fragmentation
As mentioned earlier, incentive misalignment, Ethereum’s rollup-centric roadmap, and the popularity of app chains, application-specific rollups, and “own your own stack” modularity have led to increased liquidity and user fragmentation, and the disintegration of a unified and smooth user experience.
Often, proponents of the “monolithic architecture” point to Solana and other non-EVM chains like Sui and Aptos as examples of the simplicity they offer their users.
If users bridge funds to Solana, they typically only need to interact with one form of USDC and one form of SOL. Solana has its own issues with USDC interchangeability due to the pre-existing Wormhole and Axelar USDC, but these issues have largely been resolved or improved. The Solana "ecosystem" refers to Solana and the applications built on it. There is no L2 (yet), and there is no need to bridge to get more liquidity or a different subset of applications.
In contrast, once users log into 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 the same asset for all intents and purposes—both are bridged from the Ethereum mainnet using their respective 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 to obfuscate and abstract assets at the wallet level. Despite this, users will find themselves managing assets that are “fungible” (actually almost in an irreplaceable way), across multiple chains and rollups.
This difference is even more pronounced 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 promise, completely divested themselves of Ethereum users, and became their own “monolithic” 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 this later). Arbitrum has focused primarily on DeFi (particularly perpetual contracts and options DEXs), and has recently been increasingly focused on L3 (Arbitrum’s own additional modularity layer) with the launch of Xai and Sanko. Base is primarily focused on SocialFi applications.
As you can see, “general purpose” L2s have begun to develop their own specific focuses 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. Generally speaking, each general purpose L2 should be committed to providing 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 for gaming, rollup must adopt some form of modular architecture to transfer execution to other environments (such as L3).
Due to different incentive mechanisms and other methods of bringing users and developers onto their chains, each general rollup has inadvertently formed a different culture and ecosystem.
The same goes 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 execution layer's revenue and MEV can be eaten up by rollups (in the case of MEV) or other chains. This becomes more important as competition between execution layers increases.
The situation is very challenging for protocols, as they must launch on numerous chains and try to bootstrap liquidity and users on all of them. This is especially difficult for new products, as their goal is to acquire as many users as possible. In addition, each underlying chain that a protocol runs on and each bridge integration adds complexity and amplifies security risks.
Fragmentation within the crypto world in general, and within Ethereum in particular, is at an all-time high, leading to less than optimal user experience and traffic.
Solving the fragmentation problem: chain abstraction
This fragmentation problem gave rise to the idea of chain abstraction. As mentioned earlier, we set chain abstraction as the ultimate goal: crypto users can get a truly optimized and better experience without having to deal with the many issues related to bridging, gas payments, complex UIs, and multi-chain wallet management.
To reach the ultimate goal of chain abstraction, a large number of attempts have been made, ranging from comprehensive solutions such as AggLayer, Particle Network, and OP Superchain to component solutions such as 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 attempt to “own” the chain being abstracted. For example, Polygon’s AggLayer and Optimism’s Superchain both 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, all chains often want to own their own stack.
Furthermore, they do not work well together. While rollups on Polygon 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 wish to interact with both at the same time.
Besides the fragmentation of some abstraction 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 in terms of what problems should be solved and how they should be solved.
There have been some strong efforts to outline how chain abstraction should be handled, the most prominent of which is the CAKE framework proposed by Frontier Research. We strongly recommend that readers read through the CAKE framework on their own, 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 their intents, where users sign messages. The permission layer is responsible for identifying the user's assets and executing transactions.
The solver layer includes solvers and fulfillers, which provide quotes and execution intentions based on the fees and execution speeds estimated according to the user's assets and intentions.
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 it.
Compared to the CAKE framework, we believe that a more practical approach can help visualize the development 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
Considering 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 try 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 chain abstraction 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 players in the field of comprehensive solution design - NEAR, Particle, Okto, Polygon AggLayer, and OP Superchain. These 5 solutions can be further subdivided into ecosystem-agnostic 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 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 value transfer between them quite simple. Ecosystem-agnostic solutions provide a solution that is not limited to their respective 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. Considering that most CA solutions are still in the early stages of the development process, and the differences in the various 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 products, but once again, considering that these protocols are still in the early stages of development, it is indeed too early to make a comparison at this time.
(1) Particle
As the settlement and coordination layer for all on-chain users, Particle's modular L1 (which can be thought of as an underlying 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 with a single address, account balance, and interaction point across all chains (EVM and non-EVM), 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 verification and data availability to professional participants. Essentially modularity refers to its ability to handle different aspects of blockchain operations through interchangeable independent modules. This allows Particle to maintain control over its core functionality and governance while also being able to adapt and evolve its modules.
Particle relies on three 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: Unify 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 serves as the underlying layer to support seamless atomic cross-chain interactions, unifying the balances within 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 purchase an NFT on Chain 4 at a price of 1 ETH. 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 Particle Network) into one signature and sends it to Particle L1.
After executing the above signatures, the 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 is sent to liquidity providers (LPs).
LP releases USDC on chain 4.
USDC on Chain 4 is exchanged for ETH through DEX on Chain 4.
ETH on Chain 4 is used to purchase NFTs.
Universal Account
Particle's Universal Accounts play a core role in Particle's chain abstraction product, they provide users with a single address, balance, and interaction point across a multi-chain ecosystem. Particle Universal Accounts leverage Universal Liquidity to automatically execute cross-chain atomic transactions 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. This account is then used as the core interface for interacting with applications, as well as any other applications leveraging the Particle network SDK.
Hypothetical example about an end user:
Alice found a play-and-earn dApp. The dApp is hosted on Arbitrum and uses 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 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, throughout her entire experience, Alice only used one gas token.
Bob decided to take out a loan against his NFT on Solana and use the proceeds to buy a meme, Bitcoin Ordinal. He did all this 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 to extend computational limits beyond the Bitcoin base chain, examples of which include EVM-compatible BTC L2s such as Merlin, BEVM, and bSquared. These represent 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, and their goal is to resolve friction while bringing the benefits of account abstraction to Bitcoin. BTC Connect enables account abstraction on the Bitcoin network by unifying a user's Bitcoin account and EVM-based Smart Accounts. This is done by using a Bitcoin wallet as a Signer for Smart Accounts on the Bitcoin L2 or EVM network, leaving the user's existing Bitcoin wallet as the only point of interaction. The architecture leverages the EIP-4337 design (which supports multi-signature wallets, social recovery, and more complex transaction logic at the wallet level) and EVM-compatible chains, introducing Smart Accounts, Paymaster, Bundler, and a unique Bitcoin-specific wallet connection mode.
Therefore, 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 perform 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 transact 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 across applications.
NEAR account aggregation includes 3 core technologies:
NEAR Accounts — NEAR is built using a native account abstraction, so NEAR accounts map to human-readable account names rather than public key hashes. Additionally, 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 email and do not need 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 email via 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 Relayers - 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 intent relayers, 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 the MPC service, 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 solve both development experience and user experience challenges. For this purpose, they launched an orchestration layer that abstracts the complexity of Web3 and solves the development/user experience by solving 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 appchain 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 delegated signatures based on user permission, supporting EVM and non-EVM chains.
Decentralized Transaction Network (DTN) — coordinates asynchronous transaction management across multiple blockchains and handles sub-transactions for 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, DWN, and DTN. 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 ecological solutions/aggregated blockchain
Converged blockchains can be thought of as a blockchain scaling solution that provides the ancillary benefit of chain abstraction. It stands to reason that we will find ourselves in a multi-chain world, with no single chain currently able to support the throughput required to achieve mass adoption. In order 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 converged blockchains.
(1) Polygon AggLayer
Before we delve into the Polygon AggLayer, it is necessary to take a quick look at the Polygon ecosystem:
Polygon = A global network of aggregated blockchains
AggLayer (Unified Liquidity) = A protocol that unifies the liquidity of a multi-chain network by aggregating proofs from all connected chains, ensuring the security of near-instant cross-chain atomic transactions.
Polygon CDK (Extended) = A modular collection of open source tools that allows developers to deploy their own sovereign ZK (zero-knowledge proof) powered L2, or allow existing L1 and L2 chains to migrate to AggLayer.
Polygon expounds on the concept of chain abstraction from a different perspective. 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, which enables seamless and efficient cross-chain communication and unified liquidity, among other functions. 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.
The functionality of AggLayer is divided into three stages - assuming that chain A is a ZK-driven chain running in the Polygon ecosystem:
Pre-confirmation: Chain A submits the header of the new block/transaction package A1 and the light client proof to AggLayer. The header file contains commitments to all other blocks and transaction packages that A1 depends on (Bi, Ci, etc.). When a new transaction package without a validity proof is received, it will be recognized by AggLayer as "pre-confirmed".
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 the transaction bundles from other rollups into a single proof and published to Ethereum. This aggregate proof enforces the consistency of the dependent chain state and the transaction bundle.
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 them to Bob on chain B. Chain B needs to wait until these A1s are finalized on Ethereum and provide proof of validity 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 it before submitting to AggLayer, 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, which enables cross-chain transactions without exiting 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 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? From a high-level perspective, AggLayer will enable near-instant atomic transactions and unified liquidity across the 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 with shared bridging, decentralized governance, upgrades, communication layers, etc., all built on OP Stack. The launch of 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 part of the Superchain are standardized and intended to be used as interchangeable resources. Therefore, applications can be built that target the entire Superchain - the underlying chain on which the abstract application runs.
OP stack:
The Data Availability (DA) layer stipulates that the original input of the OP Stack-based chain mainly comes from Ethereum data availability.
The sorting layer controls how user transactions are collected and forwarded and is typically managed by a single sorter.
The derivative layer processes the 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 where the user specifies a desired outcome, rather than a specific execution path. Rather than detailing every step of the trade, the user simply states what they want to achieve. External agents, called "solvers" or "fillers," then compete to find the most efficient way to fulfill that intent, usually for a fee. They can be thought of as similar to limit orders, but can be applied in a variety of situations (not just trading), such as bridging.
Generally speaking, intent protocols follow a similar structure:
Intents are submitted by users. Each intent carries specifications related to the user's goal: desired size, target chain, target asset, requested price, desired solver (for some intent networks), etc.
Solvers and fillers use subgraphs, event listeners, etc. to monitor intents in different intent networks.
A solver/filler can choose to complete the user's intent.
The above structure varies across 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 agreements fall into two categories:
Intent-based transaction protocol
Intent-based bridging protocol
For all intents and purposes, they both have effectively the same functionality, allowing users to submit intents and potentially have them executed on or through different chains.
Intent-based bridging protocol
Traditionally, 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.
In contrast, intent-based bridging relies on users expressing their intent, owning tokens on a separate chain. A solver can fulfill this request for the user on the target chain, using their own funds. The solver is then rewarded on the originating chain.
Intent-based bridging avoids the need to mint or lock tokens, thereby alleviating some of the issues that can arise from this. However, it also has its own disadvantages, more specifically, fillers/solvers may face issues due to transaction failures and chain reorganizations or rollbacks.
Similar to traditional bridges, intent-based bridges 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 also face funding costs and gas costs (especially on the target chain).
The benefits of intent-based bridging are clear:
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 generally faster and easier than traditional bridges because they use fewer computing resources and require less waiting time.
By far the largest intent-based bridging protocol is Across, which has bridged over $10 billion in transaction volume across its supported chains since November 2021.
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 the relayers.
The Across protocol relies on several key mechanisms to enable cross-chain asset transfers. The first is the relayer mechanism. The relayer observes when a user deposits funds into the origin chain and then sends the requested funds to the user on the specified target chain. They can use their own funds to execute the request, so they may face liquidity constraints. However, Across also has a liquidity pool system as a backup solution for resolving intents. After the intent is completed, the data worker and the 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 funds to relayers, rebalance liquidity pools between chains, and occasionally perform slow execution (relayers complete fast executions and compete with each other on speed to get fees). They also monitor Across executed intents and propose transaction packages to the Optimistic Oracle. The optimistic oracle can then verify the transaction package proposed by the data worker (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 market can allow users to combine bridge and minting or bridge and purchase 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, trying to become a more modular component for cross-chain transactions rather than just bridging.
Across is particularly important in intent-based architectures and protocols as they have been working on standardizing cross-chain intents. UMA, the team behind Across's optimistic oracle, and 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 cross-chain orders.
Specifies the ISettlementContract interface used for the settlement contract.
deBridge
Similar to Across, deBridge uses solver and intent-based architecture to achieve cross-chain asset transfer and smart contract interoperability. It consists of two layers: protocol layer and 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 exist off-chain as part of the infrastructure layer. The infrastructure layer consists of validators operating deBridge nodes and full nodes of supporting chains. The former processes and signs cross-chain transactions, and the latter allows validators to monitor and fully verify transactions.
The deBridge liquidity network is built on top of this two-layer architecture. It enables users to create limit orders (similar to intents) for cross-chain trades. 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 transaction 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 met not only on a separate target chain (similar to how bridging works), but also from a separate chain to the originating chain. This greatly increases liquidity because 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 transactions make gasless transactions 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 intent. This allows users to not have to worry about gas fees. In addition, users usually have to pay gas fees for failed transactions, 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 trading orders, only need to commit 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 addresses the limitations of rebalancing and settling liquidity between chains. They propose a new primitive, the clearing layer, that allows market participants to capture net fund flows between chains before final settlement with the underlying chain and bridge. 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 an intent, 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 process of rebalancing is expensive, and these costs are ultimately passed on to users.
This is where Everclear comes in, they provide a shared system for all market participants to coordinate capital flows and enable cross-chain settlement. An astonishing 80% of all cross-chain flows can be netted - providing 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.
In this system, deposits generate invoices on 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:
Assume that Alice and Bob are solvers of UniswapX and Across respectively. Alice prefers Arbitrum, while Bob prefers Optimism.
Alice executed an Optimism-Arbitrum transaction of 10 ETH. Bob executed an Arbitrum-Optimism transaction of 20 ETH.
Assume that funds from two original transactions (10 ETH and 20 ETH) are deposited into Everclear on Optimism and Arbitrum respectively.
Everclear uses 50% of Bob’s 20 ETH deposit to instantly settle Alice’s 10 ETH to Arbitrum at near zero cost.
Everclear wants to settle Bob’s trade, but only has 10 ETH 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 and has made a profit of 0.01 ETH.
Alice and Bob both end up back on their respective chains, ready to complete more transactions. 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 called solvers.
The platform uses SYMMIO as a settlement layer, utilising 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 intent is implemented on Across or deBridge:
The user submits an intent, specifies position details and whitelists solvers.
The whitelist solver monitors intents using either a subgraph or an event listener.
The first solver to lock in the intent can open a position if it fits their strategy. The solver can hedge the position in the secondary market or choose not to hedge.
Open positions include intent ID, transaction amount, average price, and oracle signature.
Oracle signatures ensure the 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 utilize cross-chain liquidity pools, users can obtain better prices and can complete large orders with minimal price impact.
Typically, without intent-based trading, to access liquidity from other chains, users would have to bridge, adding 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 Account
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.
EOAs are 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 paying 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. EOA requires native tokens to pay gas fees, which requires users to maintain native token balances for transactions. Smart contract accounts may use other fee mechanisms, providing 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 seems 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 in favor of 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 application chains. Protocols and chains can pay users' gas fees, and paymasters allow cross-chain gas fees to be paid, allowing tokens on different chains to be used to pay fees on the target chain. Gas abstraction allows users to use one token to pay transaction fees on different chains, which is completed by the relayer that handles gas payments.
Additionally, multiple transactions can be combined into a single transaction through transaction batching, thereby 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, enabling 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 level 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. 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 by one. 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 a searcher) receives submitted UserOperations and packages and submits them 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 the paymasters smart contract, which enables flexible gas policies, such as allowing dApps to sponsor operations for their users (theoretically supporting free transactions), or accepting gas fees paid using ERC20 (such as USDC) instead of the blockchain’s native currency (ETH).
Paymasters can pay user operations and reimburse bunders for performing these operations on behalf of the sender.
This process involves several steps:
* Verify user actions on the sender wallet.
* If a paymaster address is provided, verify the paymaster operation.
* Abandon all user operations that fail verification.
* Execute user actions on the sender's wallet.
* Tracks the gas used for execution.
* Transfer ETH to bundler to pay for gas used.
* If a paymaster is involved, the ETH in the paymaster contract is used to pay the gas fee.
* If paymaster is not used, the sender wallet will be reimbursed for ETH.
Paymasters removes friction from the user experience and opens up new models for users, allowing them to pay network fees with non-gas tokens and even request that third parties pay these fees.
EIP-7702
EIP-7702 introduces a new transaction type that allows an EOA to temporarily act as a smart contract account.
It does this by adding a “contract_code” field, which allows EOAs to adopt smart contract code and functions in a single transaction, enabling features like gas sponsorship and batched transactions without having to permanently migrate to smart contracts.
Based on the EIP-3074 concept, EIP-7702 takes a more conservative approach, making upgrades shorter 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 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 is given 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 with ERC-4337, the gas sponsorship mechanism in EIP-7702 is more flexible. It supports various sponsorship models:
Free sponsorship: An application might pay all gas fees for its users to encourage user adoption.
Alternative 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 service package.
Conditional Sponsorship: Paymaster can set conditions for paying gas fees based on transaction type, user behavior, or other factors.
(3) AI Agent
AI agents are on-chain entities that are able to take actions after receivin
