Written by: imajinl, Paul Timofeev, Shoal Research
Compiled by: Yangz, Techub News
“Necessary puzzle pieces to achieve mainstream blockchain adoption (with complementary case studies)”
Why a multi-chain future is inevitable
A multi-chain future with hundreds of chains is inevitable. Over time, nearly every team and developer will want their own economics and users, and even though this can be achieved in a general-purpose execution environment like Solana, applications rely on the throughput of that environment, which has 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. Additionally, L2 scaling solutions are likely to coexist alongside L1, as smaller groups of nodes can communicate significantly faster around the world than larger groups of nodes. This would allow L2s (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 status quo of only a few dozen L1 and L2, concerns have been raised about the 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. So far, there is no way to completely abstract away the complexity of the user experience in the current situation. If the multi-chain ecosystem continues to develop without first solving these major user experience obstacles, it is conceivable how unusable blockchain will be for end users.
The Internet is what it is today not because users understand its core protocols, such as HTTP, TCP/IP, UDP. Instead, it abstracts the technical details and makes it accessible to laymen. Over time, the same will be true for blockchain and blockchain-native applications.
In the cryptocurrency space, users need to deploy liquidity on multiple L1 and L2 to meet suboptimal user experience and understand the technical details of these systems. It is time to abstract everything - as far as ordinary users are concerned, they don't need to know that they are using a blockchain, let alone how many L1 and L2 are underneath, because this is the only way for the industry to gain mass adoption.
Why chain abstraction can solve all problems
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.
A deeper look at the components of the chain abstraction
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.
Account 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 to chain abstraction.
When converting EOA to SCW, it effectively separates who executes the 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, the user does not give up custody of the wallet, as the user retains their own 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, exchanging it, and then lending the proceeds to the Aave market.
With executors, there is no need to interact directly with smart contracts, while users can 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.
Additionally, account abstraction allows users to self-custody their assets and open DeFi positions on many chains without the need for different wallets, RPCs, or having to worry about different signature types, all without even having to consider which chain you are using. (More demos and articles on account abstraction)
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 users' family members, etc.
“The next billion users are not going to write 12 words on a piece of paper. The average person isn’t going to do that. We need to give them 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 allow chain abstraction to flourish.
For more details on the inner workings of account abstraction, see this post by Jarrod Watts.
Intent
The so-called intention refers to having experienced participants or "solvers" execute transactions on behalf of users in an optimal manner. In simple terms, it is to implement the on-chain operations required by users in an optimal manner off-chain. For example, when you submit an order to CowSwap, you are actually submitting an intention to exchange the above token for another token at the best price. By submitting this intention 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 intention 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 implement the chain abstraction?
The answer comes back to the line 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 of their on-chain needs to mature participants who are responsible for finding the best execution. These mature 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 don't have to consider the various complexities and risks associated with using on-chain products and services, but outsource them to mature participants who charge users accordingly. Because there is competition between solvers, the fees charged to users will be compressed to near zero because there will always be solvers ready to undercut 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 want to execute at the best price. Through a request for price (RFQ) system, the intent market passes on order flow and seconds later, the user is holding SOL on Solana. It is worth noting that Ethereum has a block time of 12 seconds, which means that although solvers have no settlement guarantees, by running their own nodes, they can be fairly certain that the USDC deposit transaction is valid and will go through. Additionally, by using their own balance sheet, solvers can prepay the funds to buy SOL on Solana and essentially execute the intent before obtaining the funds. Since the risk is not borne by the user, but by the sophisticated participants, users can execute their intent with sub-second latency and the best price without knowing the cross-chain bridge used, RPC or gas costs.
In this case, the user still knows which chain they are using. This example shows how intents work in the current context, 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 completed 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 loan at the lowest interest rate. The solver will then deposit 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 a different risk profile 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 deposits should not be made to “risky” contracts. 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 familiar with blockchains may choose from a few presets (such as low, medium, or high risk) and solvers can act on these presets.
Utilizing a set of authorized solvers to satisfy the subjective needs of users creates competition between solvers, incentivizing them to complete user orders in the best possible way without causing any trouble to the user. Additionally, users can revoke the executor privileges of a solver at any time, thereby "revoking" the 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 sophisticated technology is just that, speculation. Still, it’s not surprising to see intents evolve in this way. We believe intents will play the most important role in enabling the future of chain abstraction.
CowSwap and deBridge are two intent-focused projects. We have already covered CoWSwap and its intent-based architecture. Similar to CoWSwap, deBridge also adopts an intent-based architecture, but its purpose is to enable lightning-fast cross-chain transactions. Like most intent-based solutions, deBridge leverages a network of solvers consisting of MMs, HFTs, and other sophisticated 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 allowing solvers to compete with each other to provide users with the best execution possible, deBridge also differentiates itself by shifting risks (such as reorganization risk) and other inconveniences (such as gas fees and different RPCs on different chains) to solvers.
The diagram below illustrates the deBridge model. In the example below, a user with USD stablecoins on Solana wants to own EUR stablecoins on Ethereum, and they express their intent to deBridge, which propagates it to the network of solvers, allowing the solver to exchange their ETH on Ethereum for ethEUR, a Euro stablecoin on Ethereum. After the deBridge validator group verifies that the solver has fulfilled the user's intent 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 funds on the destination chain.
To get a better understanding of deBridge and its intent-based design, listen to this podcast episode.
Liquidity Aggregation
One of the manifestations of the growing development of multi-chain in the future is the extreme fragmentation of liquidity. In a world with hundreds of Rollups, validiums, L1s, etc., each hosting liquidity on its own network, the end-user experience will become increasingly poor due to the fragmentation of liquidity pools.
If there was only one CEX hosting all the liquidity of the crypto market, instead of hundreds of CEXs and more on-chain DEXs (all sharing the same liquidity pool), then end-user execution would likely be optimal, aside from censorship and overall centralization issues. However, this is only a hypothesis, as it is not feasible in the real world where competition is fierce and the power of decentralization exists.
The advent of DEX aggregators was an important step forward in user experience, aggregating dispersed sources of liquidity from a single network into a unified interface. However, as the inevitable multi-chain future begins to emerge, DEX aggregators will no longer be relevant, as they can only aggregate liquidity on a single chain, not multiple chains and their liquidity. Additionally, for blockchains like Ethereum, the associated gas costs required to route liquidity across multiple source chains or between 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 aggregators themselves are still limited in the liquidity sources they can route trades to.
In the future of chain abstraction, it is critical to have technology that aggregates decentralized liquidity, because 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 promote multi-chain liquidity fragmentation. Below we will mainly introduce Polygon AggLayer and Optimism Superchain.
Polygon AggLayer
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 between them. 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 withdrawals to first go 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.
How AggLayer works
The core of AggLayer is to aggregate zero-knowledge (ZK) proofs on all chains connected to it, thereby 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 this works in practice. 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 has no DAI, they must quickly find the best way to fulfill this intent. They discover that DAI on Optimism is cheaper than on Zora. The solver then publishes a proof to the 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 will swap in DAI and perform the same process to obtain the same amount of DAI on Zora and then complete the NFT purchase. Behind the scenes, AggLayer will also settle 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 take the form of DAI being arbitraged on Optimism, rising NFT costs, falling ETH prices, or any other risk in user order flow from generation to execution, resulting in losses to the parties involved. DEX aggregators on a single chain have atomic composability, which is different from solvers interacting with different state machines. 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 through pricing to users. For example, solvers can guarantee execution by covering losses (if they occur) or using their own balance sheet to meet the user's intent.
Optimism Superchain
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 let all chains that are part of it 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 shared sorters, but you can refer to this article to understand how shared sorters can unlock advantages in the field of seamless interoperability across chains and, to a certain extent, atomic composability.
Since Superchain requires opt-in chains to use a shared sorter, the execution environment available to opt-in chains may be limited. In addition, other cumbersome challenges arise, such as chains being unable to access MEVs created by their users, as well as other challenges outlined in this article. However, teams such as Espresso are working on 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 also limits the execution environment available to chains connected to the AggLayer.
Chain abstraction "cake" framework
Frontier Research developed the CAKE (Chain Abstract Key Elements) framework. This framework outlines the three layers (not including the user-facing application layer) required to achieve the following state:
“In the chain abstraction world, users visit the dApp website, connect their wallet, sign the intent action, and then wait for final settlement. All the complexity of obtaining the required assets on the target chain and final settlement has been abstracted from the user side and happens in CAKE’s infrastructure layer.”
The framework defines CAKE’s three infrastructure layers 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 abstractions and policies - what we call authorization, while the settlement layer includes underlying technologies such as oracles, cross-chain bridges, pre-confirmations, and other backend functions.
As such, the settlement layer is expected to bring huge benefits to solvers and other mature participants as well as user-facing applications, as the settlement components in the framework can collectively help solvers manage risk and provide better execution for users. This will further extend to other components such as data availability and proof of execution. These are all requirements for blockchain to provide a secure building experience for application developers and provide security guarantees that 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.
Chain Abstraction Case Study
We’ve already covered a few projects that are working towards a chain-abstract future, here are a few more.
Particle Network
Particle Network is launching a modular L1 based on the Cosmos SDK, which 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, which can then be used in dApp embedded interfaces. Since then, the protocol has expanded its service scope, aiming to promote chain abstraction in the wider 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. Therefore, the underlying L1 will act as a coordinator of the multi-chain ecosystem, unifying users and liquidity in the EVM and non-EVM worlds.
Particle Chain Abstract Stack
Universal Account (UA)
From an 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), aggregating 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 complexity 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 synchronized 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.
Therefore, Particle L1 is the coordination and settlement layer that handles all cross-chain transactions through user agreements.
Universal liquidity
Another key component of the Particle chain abstraction service is the universal liquidity function. The user agreement provides a way for users to express transaction requests through an interface, while 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 wishes to purchase an asset on a blockchain that has never been used before and does not have any funds, the liquidity required for the purchase is automatically taken from the user's existing balances, which may be on a different chain and in a different token. This is largely achieved through Particle's decentralized messaging network (DMN), which supports specialized services (called relayer nodes) to monitor off-chain events and settlement of state events. More precisely, relayers in the DMN use messaging protocols to monitor the status of user operations on external chains and then settle the final execution status to Particle L1.
General Gas
The third pillar of the Particle chain abstraction stack is the implementation of a universal gas token. Universal gas allows users to pay for gas with any token by interacting with Particle's UA.
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 a portion 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 phase, allowing early participants to try out Universal Gas in an experimental UA implementation.
Near Protocol
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 Chain Abstract Stack
Near Account
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:
Full-Authority Keys: These keys can be used to sign transactions, effectively acting on behalf of the account, and therefore should never be shared.
Function Call Keys: These keys are used to sign permissions specifically for calls to a specific contract or set of contracts.
Near’s proprietary key management system, FastAuth, lowers the barrier to entry and further abstracts blockchain from end users. FastAuth enables users to register blockchain-native accounts with a simple email address and replaces lengthy and complex private keys and passwords with passkeys (biometrics that replace passwords).
Multi-chain signature
Multichain signatures are a key component of the Near chain abstraction, allowing any NEAR account to have related remote addresses on other chains and sign messages and perform 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 shares and nodes change.
Making an MPC signing node part of the NEAR network also 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 ID, NEAR account ID, and a specific path.
Meta Transactions
Currently, another key issue that hinders the development of a seamless user experience in a universal blockchain environment is that each blockchain requires gas fees to be paid in its own native token, which requires users to obtain these tokens before using the underlying network.
NEP-366 introduces meta-transactions to 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 costs. 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 operations on behalf of the user.
Other noteworthy chain abstraction projects
The following are other noteworthy teams building solutions for chain abstraction services. This list is not necessarily exhaustive, but provides a foundation for those interested in further research on the chain abstraction model.
Connext
Connext is a modular interoperability protocol that defines chain abstraction in a blog post (May 2023) as "a pattern for improving the user experience of dApps by minimizing the user's focus on the chain they are on", accurately describing 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 as simple logic for developers to use.
Socket Protocol
Socket Protocol provides infrastructure for application developers to build interoperability-centric products and services for secure and efficient cross-chain data and asset transfer. Socket 2.0 marks the protocol's transition from cross-chain services to chain abstraction services, with its flagship product, the Modular Order Flow Auction (MOFA) mechanism, as its highlight. The mechanism is designed to provide a competitive mechanism 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.
Infinex
Infinex 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 Infinex Account is a set of cross-chain smart contracts that can be controlled, protected, and recovered through standard Web2 authentication.
Brahma Console
Brahma 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.
Agoric
Agoric 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 Generalized Messaging (GMP) for interactions outside the Cosmos ecosystem. By abstracting the complexities 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.
Summarize
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.
Just as importantly, chain abstraction can bring huge benefits to blockchain applications. Currently, Web2 developers do not need to "choose" where to deploy their applications. For example, Airbnb is available to anyone with an internet connection. However, in the Web3 environment, developers need to choose the environment where their application is deployed (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 their own right, 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 issues 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.
