10,000 words to explain the indispensable mechanism of multi-chain future: chain abstraction

Written by: imajinl, Paul Timofeev, Shoal Research

Compiled by: Yangz, Techub News

“Necessary puzzle pieces to achieve mainstream blockchain adoption (with complementary case studies)”

A multi-chain future with hundreds of chains is inevitable. Over time, almost every team and developer will want their own economics and users, and even if this can be achieved in a general-purpose execution environment like Solana, applications rely on the throughput of the environment, and these environments have historically proven to be unreliable at times. If we believe that a paradigm shift to blockchain technology is imminent, then the next logical conclusion is to have hundreds of specialized execution environments for applications built on blockchain technology. This is already happening today, with applications like dYdX, Hyperliquid, Frax, and other nascent projects all becoming independent appchains and rollups. In addition, L2 scaling solutions are likely to coexist with L1, as smaller groups of nodes can communicate significantly faster around the world than larger groups of nodes. This will allow L2 (like Rollups) to scale almost unlimited, while inheriting the security of L1 and having a 1/N trust assumption (rather than the high quorum required to reach consensus like L1). Essentially, we envision a future with hundreds of L1s and L2s.

However, even with the current multi-chain situation of only dozens of L1 and L2, some people have raised concerns about user experience. Therefore, the future of multi-chain needs to overcome many problems, including fragmented liquidity, the complexity of end users using multiple cross-chain bridges, RPC terminals, different Gas tokens and markets.

Until now, there has been no way to fully abstract away the complexity of the UX in the current scenario. If the multi-chain ecosystem continues to develop without first addressing these significant UX barriers, you can imagine how unusable blockchain will be for end users. The Internet did not develop to where it is today because users understood its core protocols, such as HTTP, TCP/IP, UDP. Instead, it abstracted away the technical details to make it accessible to laymen. Over time, the same will be true for blockchains and blockchain-native applications. In the cryptocurrency space, users need to deploy liquidity across multiple L1s and L2s to meet suboptimal user experiences and understand the technical details of these systems. It is time to abstract everything away - as far as the average user is concerned, they don't need to know that they are using a blockchain, let alone how many L1s and L2s are underneath, because this is the only way for the industry to gain mass adoption.

Chain abstraction is a means to abstract the nuances and technical details of blockchain for ordinary users, thereby providing a seamless user experience. It can be said that a breakthrough in user experience may be the missing piece for the next generation of enterprises and users to enter the blockchain and crypto-native ecosystem.

Before introducing the infrastructure projects that are critical to realizing the future of chain abstraction, it is necessary to understand some of the technical components of chain abstraction.

Wallets today face many limitations. In addition to various security vulnerabilities, they can only provide limited functionality unless used in conjunction with other smart contracts. Imagine what would happen if an Externally Owned Account (EOA) was turned into a Smart Contract Wallet (SCW)? Unlike an EOA, an SCW cannot initiate transactions independently (it needs a prompt from the EOA). By merging the functionality of both, we can effectively turn an EOA into a SCW, allowing it to not only initiate transactions, but also execute complex, arbitrary logic, which is the premise of smart contracts.

The merger of the two can unlock a plethora of use cases, and here we will focus specifically on its relationship with chain abstraction. When converting an EOA to a SCW, you effectively separate who executes a transaction from who signs it. This means that users do not need to execute transactions directly, but rather a sophisticated actor (called an executor) does it on their behalf. It is worth noting that in this process, users do not give up custody of their wallets, as they retain their private keys. There are other benefits to having an executor, such as not having to keep a gas balance on all different blockchains, as transaction/gas fees can now be abstracted away as well. In addition, users can execute bundled transactions with a single click of a button. For example, approving a token for use on a DEX, redeeming it, and then lending the proceeds to the Aave market. With an executor, there is no need to interact with smart contracts directly, while users retain custody of their funds. Imagine how cool it would be to use any blockchain application through a Telegram bot , and account abstraction technology makes it possible. In addition, account abstraction allows users to self-custody their assets and open DeFi positions on many chains without the need for different wallets, RPCs, or worrying about different signature types, all without even considering which chain is being used. (More on account abstraction in this presentation and article) Not only that, account abstraction also eliminates the need for users to hold private keys to protect their accounts from third-party management. In addition to social recovery, users can also choose more traditional verification methods such as 2FA and fingerprint to ensure the security of their wallets. Social recovery can recover lost wallets through the user's family, etc. "The next billion users are not going to write 12 words on a piece of paper. The average person doesn't do that. We need to provide them with better usability; they don't need to think about encryption keys." - Yoav Weiss, EF Since wallets are the entry point to crypto and blockchain, account abstraction will eventually enable chain abstraction to flourish. For more details on the inner workings of account abstraction, see this post by Jarrod Watts.

Intents are about having experienced participants or “solvers” execute transactions on behalf of users in an optimal manner. In simple terms, it is about implementing the on-chain actions that users need in an optimal manner off-chain. For example, when you submit an order to CowSwap, you are actually submitting an intent to exchange the above token for another token at the best price. By submitting this intent off-chain, the public mempool can be bypassed and routed directly to the encrypted private mempool. Solvers will then compete to meet or resolve your intent at the best possible price, whether using their own balance sheet, private order flow, or on-chain liquidity venues such as Uniswap and Curve. In this way, the solver's profit is compressed to zero, providing users with the best execution. Now that we have defined intents, how exactly do they help us achieve chain abstraction? The answer comes back to the boundary between signers and executors in the account abstraction. If all a user needs to do is click a button to sign a transaction, then they can outsource all on-chain needs to sophisticated participants who will be responsible for finding the best execution. These sophisticated participants then take on the risk of interacting with all the different applications on L1 and L2, the associated gas fees for different tokens on different chains, reorganization risk, and other execution risks. By taking on these steps and risks, solvers will price the fees they charge users accordingly. In this case, users do not need to consider the various complexities and associated risks of using on-chain products and services, but instead outsource them to sophisticated participants, who charge users accordingly. Because there is competition between solvers, the fees charged to users will be compressed to near zero, as there will always be solvers ready to undercut the price of the solver who wins the order flow. This is the magic of the free market - through competition, users will enjoy better services at lower prices. For example: I have ETH on Ethereum and want to get SOL on Solana and hope to execute at the best price. Through the request for quotation (RFQ) system, the intent market transmits the order flow, and a few seconds later, the user can hold SOL on Solana. It is worth noting that Ethereum has a block time of 12 seconds, which means that although solvers have no settlement guarantee, by running their own nodes, they can be fairly certain that the USDC deposit transaction is valid and will go through. Furthermore, by using their own balance sheet, solvers can prepay the purchase of SOL on Solana and essentially fulfill intents before they have access to funds. Since the risk is not borne by the user but by sophisticated participants, users can fulfill their intents with sub-second latency and the best price without knowing the cross-chain bridge, RPC, or gas costs used. In this case, the user still knows which chain they are using. This example illustrates how intents work in the current environment, rather than in a completely abstract chain. Intentions don’t stop here, there are more possibilities. It is not difficult to imagine that in the future, intents will meet all the needs of users. Users only need to specify what to do and it will be done in the most efficient way. For example, a user may want to borrow DAI with ETH and deposit DAI into a liquidity pool to earn CRV rewards. In this example, the authorized solver will compare all DAI with the borrowing rate of ETH and lend the lowest interest rate. The solver will then deposit the DAI into a vault similar to Yearn, automatically convert the highest yield into CRV, and transfer it to the user’s wallet. However, it is important to note that risk is subjective and cannot be expressed in terms of intent, unlike other objective inputs such as the maximum price slippage of a trade. So which lending markets, liquidity pools, and chains can be used to fulfill this intent? After all, each market has different risk profiles and trust assumptions. This is where “authorized solvers” come in. Each authorized solver is trusted to some extent by the user to fulfill the user’s intent in accordance with the risk and trust preferences expressed in advance by the user. For example, a user can specify that “risky” contracts should not be deposited. However, it is likely that only advanced users will specify a large number of subjective preferences to solvers. Even more sophisticated participants than advanced users (HFT, MM, VC, etc.) may directly connect to the chain to avoid any fees charged by the solver and customize the risk and trust assumptions themselves. Users who are slightly more familiar with blockchains may choose from a few presets (such as low, medium, or high risk) and solvers can act on these presets. Using a group of authorized solvers to meet the subjective needs of users can create a competitive situation between solvers, incentivizing them to complete user orders in the best way without causing any trouble to users. Additionally, users can revoke a solver’s executor rights at any time, thereby “revoking” authorization, which creates a system of checks and balances. This way, solvers have an incentive to remain honest and follow user preferences, otherwise different solvers can prove that they acted maliciously against the user who initiated the order flow. Of course, intents are still a work in progress, and speculation about how intents will turn into more complex technology is just that, speculation. However, it is not surprising to see intents develop in this way. We believe that intents will play the most important role in realizing the future of chain abstraction. CowSwap and deBridge are two projects that focus on intent. We have already introduced CoWSwap and its intent-based architecture. Similar to CoWSwap, deBridge also adopts an intent-based architecture, but its purpose is to achieve lightning-fast cross-chain transactions. Like most intent-based solutions, deBridge utilizes a network of solvers composed of MM, HFT, and other mature players to front-end funds on the target chain through their own balance sheet before collecting users’ funds on the source chain. In addition to pitting solvers against each other to provide the best possible execution for users, deBridge also differentiates itself by shifting risks (such as reorganization risk) and other inconveniences (such as gas fees and different RPCs on different chains) onto solvers. The following diagram illustrates the deBridge model. In the example below, a user with a USD stablecoin on Solana wants to have a EUR stablecoin on Ethereum, and then they express their intention to deBridge, which broadcasts it to the network of solvers, allowing the solver to exchange their ETH on Ethereum for ethEUR, a EUR stablecoin on Ethereum. After the deBridge validator group verifies that the solver has fulfilled the user's intention on the destination chain (in this case, giving the user ethEUR), deBridge quickly unlocks the user's funds on the source chain (in this case, Solana) and gives them to the solver. Importantly, the user does not need to wait for verification before receiving the funds on the destination chain.

To get a better understanding of deBridge and intent-based design, listen to this podcast episode .

One of the manifestations of the growing multi-chain future is the extreme fragmentation of liquidity. In a world with hundreds of Rollups, validiums, L1s, etc., each hosting liquidity on their own network, the end user experience will be increasingly poor due to the fragmentation of liquidity pools. If there was only one CEX hosting all the liquidity of the cryptocurrency market, rather than hundreds of CEXs and more on-chain DEXs (all sharing the same liquidity pool), then the end user execution would be optimal, in addition to censorship and overall centralization issues. However, this is only a hypothesis, because in the real world where competition is fierce and decentralized forces exist, this is not feasible. The emergence of DEX aggregators is an important step in user experience, aggregating decentralized sources of liquidity in a single network into a unified interface. However, as the inevitable multi-chain future begins to emerge, DEX aggregators will no longer be applicable because they can only aggregate liquidity on a single chain, not multiple chains and their liquidity. In addition, for blockchains like Ethereum, the associated gas costs required to transfer liquidity to or between multiple source chains make the cost of using an aggregator higher than the cost of direct liquidity sources. This model can have greater success on low-price, low-latency networks like Solana, although the aggregators themselves are still limited in the sources of liquidity they can route trades. In the future of chain abstraction, it is critical to have technology that aggregates decentralized liquidity, as the ideal user experience will be chain-free and will likely rely on third-party solvers to provide execution services. Many teams are developing solutions designed to drive multi-chain liquidity fragmentation, and below we will focus on Polygon AggLayer and Optimism Superchain.

As stated on the Polygon website: “AggLayer will be a decentralized protocol consisting of two parts: a universal cross-chain bridge and a ZK-driven mechanism that provides cryptographically secure guarantees for seamless cross-chain interoperability. With security provided by ZK proofs, chains connected to AggLayer can remain sovereign and modular while retaining the seamless user experience of a monolithic chain.” Fundamentally, there is a typical bridge between Ethereum L2 scaling solutions and Ethereum. This means that all user funds bridged from Ethereum to L2 reside in this bridge contract. However, this undermines interoperability between different L2s and their ability to seamlessly communicate data and transfer value. This is because, for example, if you want to cross from Base to Zora (both are Ethereum Rollups), as shown in the figure below, it will take 7 days for you to withdraw funds, first from Base to Ethereum, and then from Ethereum to Zora. For an OP-type Rollup like Base, it takes time to dispute the bridge transaction using fault/fraud proofs. Not only is this a long process, but it is also costly because it requires interaction with the Ethereum main chain. Polygon AggLayer subverts this process. As shown in the figure below, all chains share a cross-chain contract with other chains that utilize AggLayer.

At its core, AggLayer aggregates zero-knowledge (ZK) proofs from all chains connected to it, facilitating cross-chain transactions. AggLayer is essentially an aggregation place where all supported chains publish ZK proofs to prove that certain actions have occurred. To further illustrate this, let's consider how it works in a real-world situation. In this example, we assume that all mentioned chains are connected to AggLayer. The solver detects a request or intent from a Base user. The user has ETH and wants to buy 3000 DAI worth of NFTs on Zora. Since the solver does not have DAI, they must quickly find the best way to fulfill this intent. They find that DAI on Optimism is cheaper than on Zora. The solver then publishes a proof to AggLayer indicating that the user has ETH on Base and wants to receive the corresponding amount of ETH on Optimism. Since cross-chain contracts are shared, only one ZK proof is needed to transfer the same amount of fungible assets on the "X" chain to the "Y" chain. After publishing the ZK proof and unlocking the corresponding amount of ETH on Optimism, the solver swaps in DAI and performs the same process to obtain the same amount of DAI on Zora and then complete the NFT purchase. Behind the scenes, AggLayer also settles these ZK proofs to Ethereum, providing stronger security guarantees for end users and the chains connected to AggLayer. However, in this case, the solver/user/other actor bears inventory risk. This risk can manifest in the form of DAI on Optimism being arbitrage, NFT cost increases, ETH price drops, or any other risks between user order flow from generation to transaction, resulting in losses to the parties involved. DEX aggregators on a single chain have atomic composability, while solvers interacting with different state machines are different. Atomic composability ensures that all operations are executed in a single linear order, either all succeed or all fail. This is because there is always a delay of at least one block between different state machines due to the potential risk of reorganization (on the target chain). However, this does not mean that the above use cases cannot happen. Not only are there long-tail events, but solvers and other sophisticated participants can also take on these risks and compensate for them by pricing them to users. For example, solvers can guarantee execution by covering losses (if they occur) or using their own balance sheet to satisfy user intent.

Another example of aggregated liquidity is the Optimism Superchain. As defined in the Optimism document, Superchain is "a chain network that shares cross-chain, decentralized governance, upgrades, communication layers, etc., all built on the OP Stack." This project focuses on aggregated liquidity, similar to AggLayer. Superchain will allow all chains that are part of it to use shared cross-chain contracts. This is the first step in aggregating liquidity between chains in Superchain.

The difference between Superchain and AggLayer is that AggLayer relies on ZK proofs for a seamless experience, while Superchain relies on a shared sorter. This article will not go into the details of the shared sorter, but you can refer to this article to understand how the shared sorter can unlock advantages in the field of seamless cross-chain interoperability and, to a certain extent, atomic composability. Since Superchain stipulates that chains that choose to join must use a shared sorter, the execution environment that can be used by the chains that choose to join may be limited. In addition, other cumbersome challenges will arise, such as the chain being unable to access the MEVs created by its users, as well as other challenges outlined in this article . However, teams such as Espresso are studying how to redistribute MEVs enabled by chains using shared sorters. In addition, all chains connected to the Polygon AggLayer are also required to use the same ZK cycle, which will also limit the execution environment that can be used by chains connected to the AggLayer.

Frontier Research has developed the CAKE (Chain Abstraction Key Elements) framework. The framework outlines the three layers required to achieve the following state (not including the user-facing application layer): "In the chain abstraction world, users visit a dApp website, connect their wallet, sign an intent action, and then wait for final settlement. All the complexity of acquiring the required assets on the target chain and final settlement has been abstracted from the user side and occurs in the infrastructure layer of CAKE." The framework defines the three infrastructure layers of CAKE as the permission layer, the resolution layer, and the settlement layer. We have already discussed the resolution layer and the permission layer. The permission layer includes account abstraction and policies - we call it authorization, while the settlement layer, includes underlying technologies such as oracles, cross-chain bridges, pre-confirmations, and other backend functions. Therefore, the settlement layer is expected to bring huge benefits to solvers and other mature participants as well as user-facing applications, because the settlement components in the framework can work together to help solvers manage risk and provide better execution for users. This will be further extended to other components such as data availability and proof of execution. These are all requirements for blockchains to provide application developers with a secure building experience and provide security guarantees, which are ultimately passed on to end users. The CAKE framework encompasses many of the concepts mentioned in this article and provides a coherent way to look at the various components of the chain abstraction and how they relate to each other. Readers interested in the framework can read this introductory article .

We’ve already covered a few projects that are working towards a chain abstraction future, here are a few more.

Particle Network is launching a modular L1 based on the Cosmos SDK that will run as a high-performance EVM-compatible execution environment. Initially, Particle debuted as an account abstraction service provider, enabling users to create smart contract wallets connected to their Web2 social accounts and then use them in dApp embedded interfaces. The protocol has since expanded its service scope, aiming to promote chain abstraction in the broader blockchain space through its suite of wallet, liquidity, and gas abstraction services on L1. Similar to other chain abstraction service providers, Particle envisions a future where anyone can easily transact on multiple chains through a single account and pay gas fees in any token they wish. As a result, the underlying L1 will act as a coordinator of a multi-chain ecosystem, unifying users and liquidity in both EVM and non-EVM domains.

Universal Accounts (UA) From the end-user perspective, Particle’s chain abstraction stack starts with first principles — creating accounts. Universal Accounts on Particle are ERC-4337 smart accounts attached to pre-existing EOAs (Externally Owned Addresses) that aggregate token balances on multiple chains into a single address by automatically routing and executing atomic cross-chain transactions. Traditional cryptocurrency wallets can be used to create and manage accounts, and Particle’s WaaS also allows users to register using social logins. To abstract away the various complexities of blockchain-native operations, the function of UA is to build a unified interface on top of existing wallets, allowing users to deposit and use tokens in multiple blockchain environments as if they were on a single chain. To keep the state in sync between UAs, account settings will be stored on Particle L1 as the central source of truth for each instance. The network will then facilitate cross-chain messaging to deploy new instances or update existing ones. As such, Particle L1 is the coordination and settlement layer that handles all cross-chain transactions through user agreements.

Universal LiquidityAnother key component of the Particle chain abstraction service is the universal liquidity function. While the user agreement provides a way for users to express transaction requests through an interface, universal liquidity refers to the layer responsible for automatically executing these requests, which in turn enables the unification of balances between different networks. This function is key to enabling cross-chain transfers, which are otherwise hindered by current entry barriers (such as purchasing native gas tokens and creating native wallets for new networks). For example, when a user wants to buy an asset on a blockchain that has never been used and does not have any funds, the liquidity required for the purchase is automatically obtained from the user's existing balance, which may be on a different chain and may be in a different token. This is largely achieved through Particle's decentralized messaging network (DMN), which supports specialized services (called relayer nodes) to monitor the settlement of off-chain events and state events. More precisely, relayers in the DMN monitor the status of user operations on external chains using a messaging protocol, and then settle the final execution status to Particle L1. Universal GasThe third pillar of the Particle chain abstraction stack is the implementation of a universal gas token. By interacting with Particle's UA, Universal Gas allows users to pay for Gas with any token. When a user wishes to execute a transaction through Particle UA, the interface prompts the user to select a Gas token, which is then automatically paid through Particle's native Paymaster contract. All Gas payments are settled on their respective source and target chains, while part of the fees are exchanged for Particle's native PARTI tokens and settled on Particle L1.

Particle builds on its existing account abstraction infrastructure, which has reported over 17 million wallet activations and over 10 million user actions. Particle L1 is not intended to compete directly with existing blockchains; rather, it aims to provide an interoperability layer that works with key teams in the chain abstraction services space (including Near and Cake R&D teams) to connect them. Particle Network L1 is currently in the testnet stage, allowing early participants to try out universal gas in an experimental UA implementation.

As a sharded proof-of-stake L1, Near’s core revolves around bridging the gap between blockchain native applications and mainstream audiences. Near achieves this through Account Aggregation. Account Aggregation is a multi-faceted architecture designed to abstract away key pain points of using blockchain networks, such as switching wallets, managing gas fees, cross-chain, etc. It aggregates all operations into a single account.

Near accounts In addition to the alphanumeric public key hash standard on most blockchains today, Near's proprietary account model maps each account to a more readable account name, such as alice.near. Near accounts also use two types of access keys, which differ in nature and underlying functionality, enabling accounts to manage multiple keys on multiple blockchains, each responsible for various permissions and configurations unique to its domain:

Near's proprietary key management system, FastAuth, lowers the barrier to entry and further enhances the abstraction of blockchain for end users. FastAuth allows users to register blockchain-native accounts with a simple email address and replaces long and complex private keys and passwords with passkeys (biometrics instead of passwords). Multichain Signatures Multichain signatures are a key component of Near's chain abstraction, allowing any NEAR account to have associated remote addresses on other chains and sign messages and execute transactions from these addresses. To achieve this, multichain signatures use the NEAR MPC (multi-party computation) network as a signer for these remote addresses, eliminating the need for explicit private keys. This is made possible by a novel threshold signature protocol that implements a form of key sharing that allows MPC signers to maintain the same total public key even as key sharing and nodes change. Making MPC signing nodes part of the NEAR network allows smart contracts to initiate the signing process for an account. Each account can create an unlimited number of remote addresses on any chain using different combinations of chain IDs, NEAR account IDs, and specific paths. Meta Transactions Currently, another key issue that hinders the development of seamless user experiences in a universal blockchain environment is that each blockchain requires gas fees to be paid in its own native token, which requires users to acquire these tokens before using the underlying network. NEP-366 introduces meta transactions for Near, a feature that allows users to perform transactions on Near without owning any gas or tokens on the chain. This is achieved through third-party service providers Relayers, who receive signed transactions and forward them to the network while attaching the necessary tokens to subsidize their gas fees. From a technical perspective, the end user creates and signs a SignedDelegateAction (which contains the data required to build a transaction) and then sends it to the relay service. The relay service signs the transaction with this data, sends the SignedTransaction to the network via an RPC call, and ensures that the relay service pays the gas fee when performing actions on behalf of the user.

Here are some other noteworthy teams building solutions for chain abstraction services. This list is not necessarily exhaustive, but it provides a foundation for those interested in further researching chain abstraction models. ConnextConnext, a modular interoperability protocol, defines chain abstraction in its blog (May 2023) as "a pattern that improves the user experience of dApps by minimizing the user's concern about the chain they are on", which accurately describes the core principles that chain abstraction service providers are currently building around. Connext provides a set of smart contract modules for application developers through its Chain Abstraction Toolkit, the core function of which is xCall, a basic function that allows smart contracts to interact with each other in different environments. The xCall function can initiate funds, calldata and/or various cross-chain transfers, and the Chain Abstraction Toolkit encapsulates it into simple logic for developers to use. Socket ProtocolSocket Protocol provides infrastructure for application developers to help them build interoperability-centric products and services, enabling secure and efficient cross-chain data and asset transfers. Socket 2.0 marks the protocol's transition from cross-chain services to chain abstraction services, and its flagship product, the Modular Order Flow Auction (MOFA) mechanism, is its highlight. The mechanism is designed to provide competition for an efficient chain abstraction market. Traditional OFA involves a network of various participants performing specialized tasks that compete to provide the best results for end-user requests. Similarly, MOFA aims to provide an open market for execution agents called "transmitters" and user intent. In MOFA, transmitters compete to create and complete chain abstraction bundles, or ordered sequences of user requests that require the transfer of data and value between multiple blockchains. InfinexInfinex is building a single user experience layer that aims to unify decentralized applications and ecosystems. Its flagship product, Infinex Account , is a multi-layered service that serves as a platform to integrate any on-chain application into a simplified user experience for end users. At the core of the Infinex account is a set of cross-chain smart contracts that can be controlled, protected, and recovered through standard Web2 authentication. Brahma ConsoleBrahma Finance is building its flagship product, Console, an on-chain execution and hosting environment designed to enhance the DeFi user experience, with a particular focus on the EVM blockchain ecosystem. Brahma uses batched and chained transactions to synchronize transactions on different chains, and uses smart accounts for on-chain interactions. The end result is seamless cross-chain interaction within a single user interface. AgoricAgoric is a native L1 of Cosmos, designed with an asynchronous, multi-block execution environment, and aims to be the preferred environment for developing cross-chain applications. Agoric leverages the Cosmos IBC protocol for inter-chain communication, while leveraging Axelar's General Messaging (GMP) for interactions outside the Cosmos ecosystem. By abstracting the complex issues involved in cross-chain communication and smart contract execution, Agoric's coordination application interface (API) simplifies the developer experience, while end users benefit from applications with inherent chain abstraction capabilities.

Having written so much, I think the advantages that chain abstraction brings to end users should be obvious. The complexity of using blockchain-native applications will be completely abstracted into a unified interface layer, creating a global, chain-free touchpoint for any user who wants to participate. Equally important, chain abstraction can bring huge benefits to blockchain applications. Currently, Web2 developers do not need to "choose" where to deploy their applications. For example, anyone can use Airbnb as long as they have an Internet connection. However, in the Web3 environment, developers need to choose the deployment environment of their applications (for example, on Ethereum, Solana, or Cosmos). This not only limits the TAM (Technology Acceptance Model), but also means that developers need to choose the "right" chain to deploy. This choice is difficult but critical. Some applications are excellent in themselves, but they are troubled by the underlying blockchain. In addition, as the blockchain industry continues to grow and evolve, the so-called "right" chain may also continue to change. In the future of chain abstraction, application developers no longer need to choose a chain that is closely related to their success. It is clear that we are heading towards a multi-chain future, which will inevitably exacerbate user experience problems and hinder mainstream adoption. We believe that chain abstraction and its various components are a viable solution to the user experience problems of cryptocurrency today.