Chain Abstraction Landscape

7/22/2024

This report was sponsored by the Particle Network team. The report’s content and opinions were produced independently. Particle Network had no influence over the report’s substance or our stated views.

Introduction

One of the few constants in the crypto industry is the ever expanding number of blockchains. Whether an Ethereum L2, app chain, or alternative layer 1, there seems to be an abundant supply of new blockchains.

While a diverse set of blockchains provides users with many options, it introduces drawbacks for both developers and multichain users. An increasing number of chains fragments liquidity, usage, and adversely affects the UX – this creates a strictly worse experience for both multichain users and application developers. 

The story of how crypto ended up with this many chains is one of infrastructure iteration and incentive misalignment. Since the introduction of the PoS consensus mechanism, there has been an explosion in the number of chains in crypto. In comparison to Bitcoins PoW consensus mechanism, PoS drastically lowers the barriers to both spinning up and securing a new network, resulting in an Cambrian explosion of innovative projects in the L1 landscape. The pursuit of solving the scalability trilemma has brought us Solana, Cosmos and its app chains, Berachain and its PoL consensus mechanism, Ethereum L2s and fraud proofs, etc etc. Each innovative in their own way.    

While innovation may be the primary driver behind the explosion of chains, incentive misalignment is partly to blame. Infrastructure trades at a premium to applications, thus there is a valuation bump that developers factor in when deciding what and where to build. This incentive misalignment has resulted in umpteen different blockchains or protocols that ‘own their own stack’ and is largely at fault for the world we find ourselves in. 

The Rise of Modularity and Rollups

The concept of Modularity is a relatively new one, it was first laid out by Mustafa Al-Bassam in 2019 in an academic paper titled, “LazyLedger: A Distributed Data Availability Ledger with Client-Side Smart Contracts.” In this paper, he outlined a blockchain design where the functions of network consensus and data availability are decoupled from transaction settlement and execution. 

The benefit of modularity is specialisation, whether that be affordable DA or off-chain execution. Similar to Adam Smith postulating that the division of labour was the source of economic growth, specialisation (division of labour) aids scalability (growth) through increased efficiency. 

On the 2nd October 2020, Vitalik introduced a pivot to rollups as Ethereum’s primary scaling solution – Rollups are a natural extension of ‘The Rise of Modularity’. The end goal for Ethereum is to become the financial layer for global coordination, a goal that requires scale. However, thinking about the scalability trilemma, Ethereum has optimised for decentralisation and security, at the expense of scalability. Rollups increase transaction throughput and reduce costs by bundling multiple transactions into a single batch, which is then submitted to the Ethereum mainnet. This approach minimises the amount of data processed on-chain, leading to faster and cheaper transactions. However, as the number of rollups increase, the complexity of interacting with the Ethereum ecosystem increases as additional infrastructure needs to be built in order to connect the rollup to the rest of the ecosystem. 

Celestia’s scalability is enhanced by its unique approach to data availability sampling (DAS). This allows the network to scale as more light nodes join, enabling larger block sizes without compromising security or decentralisation.

In order to surpass Web2, the Web3 UX needs to offer a strictly better experience – given the switching costs. This is where chain abstraction comes in. 

Chain abstraction, as an idea, is more akin to an end goal than it is to a method of achieving the end goal. As such, ‘Chain Abstraction’ is a type of user experience, therefore any component/improvement can be considered one that ‘enables a chain abstracted future’. 

In order to be a multichain user today, one is required to bridge capital between many chains, navigate a complex UI and pay for transactions in many different tokens that each have their own risk profile, etc. Users are required to interact with the  ‘plumbing’ of the crypto economy, it’s complex and clunky – in tradfi, the equivalent ‘plumbing’ would be transacting on FedWire. Thinking about Chain Abstraction from a Web2 UX type end goal, there are a two key pain points that need to be solved: 

1. The Web3 UX complexity 

2. The fragmentation of users and liquidity   

Abstraction in Web2

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

The simplification or removal of technical complexities from the user’s experience, producing technologies which exist to hide such details and processes. These complexities are still at play, yet are invisible to the user. 

In the Web2 world, abstraction has played a crucial role in creating a seamless and user-friendly experience by hiding the technical complexities of various operations and presenting a simplified interface to the user. For instance, users interact with websites through browsers without needing to understand underlying protocols like HTTP, TCP/IP, or DNS. A user simply opens Outlook, composes an email, and sends it – they are entirely unaware that their email interacts with protocols such as SMTP for sending and IMAP/POP for receiving. Web hosting and cloud services abstract server management, data replication, and load balancing, providing user-friendly interfaces for deploying and managing applications with ease. 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 communication, allowing users to make transactions effortlessly. The point is that Web2 offers an experience that non-internet natives can navigate, this focus on abstraction in Web2 has made the technology accessible. 

As the go-to search engine, Google can be thought of as the ultimate abstraction. By serving as an extensive directory for the internet, it simplifies information retrieval by allowing users to enter search queries without needing to understand the intricate search algorithms or web crawling processes. Google’s algorithms index billions of webpages and rank them by relevance, presenting the most important results to the user. This abstraction means users don’t need technical knowledge about SEO, HTML structure, or web hosting, as Google hides these complexities and provides straightforward, organised search results. Moreover, Google offers most of the services outlined earlier – Mail (Gmail), Writing (Google Docs), Storage (Google Drive), and more. Through a unified and accessible interface, Google further enhances the user experience by centralising various functionalities into one cohesive ecosystem. 

To make this point abundantly clear – Web2 consists of many protocols that interoperate with one, ‘under the hood’ Web2 is not much different to Web3 in so far as the requirement for abstraction is concerned. To the average Web2 user, there is no need to understand these protocols, this simplified UX serves as a north star for chain abstraction.  

A Formal Definition

Chain Abstraction – ‘a user experience exempt from the manual processes required to interact with multiple chains’ 

Let’s define the issues Chain Abstraction seeks to solve:

1. Bridges – users are required to bridge value to different chains, this introduces both a material UX friction as well as a security risk. 

2. Gas Tokens – users need to acquire and manage separate tokens on different chains in order to pay for gas. 

3. Account & Wallet fragmentation – a user is required to interact with multiple accounts in order to access their entire balance. This issue is exacerbated with non-EVM ecosystems where separate addresses and wallets are required. 

4. Liquidity fragmentation – as the number of blockchains increase, liquidity fragments and is further siloed on these chains. 

Fragmentation

As mentioned previously, incentive misalignment, Ethereum’s rollup-centric roadmap, and the popularisation of appchains, app-specific rollups, own-your-own-stack modularity has led to the rise of fragmentation, both in liquidity and users, and the dissolution of a unified and smooth user experience.

Often, proponents of “monolithism” point to Solana and other non-EVM chains (such as Sui and Aptos) to showcase the simplicity that they offer users. 

If a user bridges or onboards onto Solana, they typically have to only interact with one form of USDC and one form of SOL. Solana has had its own issues regarding USDC fungibility, due to the existence of Wormhole and Axelar USDC prior to the native onboarding of Circle’s USDC, but these have largely been solved or improved. The Solana “ecosystem” is Solana and applications built on top of it. There are no L2s (yet), and no necessity for bridging to get more liquidity, or a different subset of applications.

In contrast, when a user onboards onto the Ethereum ecosystem (including rollups) they can encounter multiple forms of USDC and multiple forms of ETH. For example, although ETH on Optimism and ETH on Arbitrum are for all intents and purposes the same asset - both have been bridged over from Ethereum mainnet using their respective canonical bridges - they cannot be used interchangeably. Certain applications only exist on Optimism, while others only exist on Arbitrum. For all practical purposes, ETH on Optimism and Arbitrum are on completely different chains, with different ecosystems and different use cases. 

Even at the wallet level, these are recognized as different assets. Newer wallets like Rabby and Rainbow have made valiant efforts to obfuscate and abstract away assets at the wallet level. Despite this, users tend to find themselves managing assets that are “fungible” and practically equivalent in a non-fungible manner, across multiple chains and rollups.

The difference is more stark at the non-rollup level. With non-EVM chains (e.g. Solana, Sui, Aptos) and non-Ethereum EVM-based L1s (e.g. BNB and Avalanche C-Chain), users have to deal with non-native assets (axlUSDC, axlETH etc.) as well.

In theory, if rollups fulfil their promise and completely offboard users off Ethereum, and become their own “monolithic” chains on top of Ethereum, there shouldn’t be the need to bridge and seek liquidity. However, this has not been the case yet. The three largest rollups: Arbitrum, Optimism and Base, each have different ecosystems, use cases and user demographics. Optimism itself has moved towards adding an additional level of modularity: with the Superchain (discussed in extent later). Arbitrum has mainly focused on DeFi (perpetuals and options DEXes in particular), and lately has increasingly focused on L3s (its own extra layer of modularity) with the launch of Xai and Sanko. Base has largely been focused on SocialFi applications.

As it can be seen, “generalized” L2s have started to develop their own specific focuses and use cases. Users who want to play games would have to bridge over to Arbitrum and then bridge over the Xai or Sanko. If the same user wants to participate in Degen tipping on Farcaster or buy keys on friendtech they would have to bridge over to Base. If a user wanted to then use Synthetix they would have to bridge over to Optimism. The end result is high fragmentation, and not by design. In general, each generalized L2 should aim to offer a broad variety of apps, to suit a user’s every need: to offer a monolithic experience in a modular setting. This has not been the case, for two reasons:

• Rollups themselves have to adopt some form of modular architecture to move execution to other environments (such as Layer 3s) due to low TPS on the base rollup, especially in terms of gaming.

• Each generalized rollup inadvertently adopts a different culture and ecosystem, due to different incentive mechanisms and other methods in onboarding users and developers on their chain. 

The same exists for L1s. There are some applications and users that only exist on Avalanche C-Chain or BNB or Sui and Aptos.

Fragmentation does not only affect users, it also affects both execution layers and protocols themselves. Due to fragmentation, execution layers lose revenue and MEV to either rollups (in the case of MEV) or other chains. This is becoming more significant as competition between execution layers intensifies.

For protocols, the situation is challenging because they must launch on numerous chains and attempt to bootstrap liquidity and users across all of them. This is particularly difficult for new products, as they aim to acquire as many users as possible. Additionally, every chain a protocol launches on and every bridge integration adds complexity and increases security risks.

Overall, fragmentation within crypto, especially in Ethereum, is at an all time high, which has led to less-than-ideal user experiences and flows.

Fixing Fragmentation: Chain Abstraction

This fragmentation has led to the growth and development of the idea of chain abstraction. As discussed before, we take chain abstraction as an end goal: where crypto users can receive a strictly improved and better experience, and not have to deal with a multitude of issues related to bridging, paying gas, complex UI and multichain wallet management.

There have been a multitude of attempts at reaching the end goal of chain abstraction, ranging from comprehensive solutions, such as AggLayer, Particle Network and the OP Superchain, to component solutions, such as intent networks and bridging aggregators.

In general, one of the key issues with chain abstraction has been, ironically, the fragmentation of chain abstraction solutions. Typically, we’ve seen chain abstraction solutions attempt to “own” the abstracted chain. For example, both Polygon’s AggLayer and Optimism’s Superchain attempt to abstract away rollup fragmentation, either through unifying liquidity, messaging, bridging or other components. However, both need chains to opt-in to their solution, which comes with incentive misalignment. At the end of the day, often chains want to own their own stack. 

Additionally, they don’t work well together. While rollups on Polygon’s AggLayer benefit from unified liquidity, and rollups part of the Superchain benefit from unified messaging and interchangeable applications and resources, users still experience poor UX if they wish to interact with both at the same time.

Apart from the fragmentation of some abstraction solutions, especially at the component level, another issue that chain abstraction faces relates to how it should be approached. 

The reality is that chain abstraction is a multifaceted issue that can be addressed through many different angles: both in terms of what issues should be fixed, but also in terms of how they should be fixed. 

A few strong efforts have been made in outlining how chain abstraction should be approached, with the most prominent one being the CAKE Framework by  Frontier Research. We highly recommend that readers read through the CAKE Framework themselves, but at a high level, Frontier outlines that the Chain Abstraction Key Elements (CAKE) framework is made up of three infrastructure layers: the permission layer, the solver layer and the settlement layer. 

The permission layer refers to where users connect their wallet to protocols and applications and submit their intents, where users sign messages. The permission layer is responsible for recognizing the user’s assets and executing transactions.

The solver layer involves solvers and fulfillers who provide quotes and fulfill intents, based on estimated fees and execution speed depending on the user’s asset and intent.

The settlement layer ensures a user’s transaction. If the transaction is set to occur on a chain different from the origin chain, it bridges assets onto that chain and executes.

In contrast to the CAKE Framework, we think a more pragmatic approach can help visualize how the chain abstraction landscape is developing. In simple terms, we categorize chain abstraction solutions into two broad categories: comprehensive solutions and component solutions, each which have further subcategories. 

Comprehensive vs Component Design Space 

Given how nebulous a term chain abstraction (CA) is, let’s split the design space in two – comprehensive CA solutions and component CA solutions. A comprehensive CA solution is defined as a solution that seeks to abstract multiple frictions away, offering a ‘full stack’ solution to CA. A comprehensive solution is akin to a monolithic blockchain in so far as the UX is concerned. A component solution is one that tries to solve a single problem, contributing to part of the larger solution. It’s important to note that this report does not delve into every single chain abstraction related solution. Chain abstraction is a broad concept, and more of a motivation and end goal, rather than a category. The protocols, networks, infrastructure layers and EIPs that are discussed below help clarify and represent how certain types of solutions can help chain abstraction. There has been a wide range of research on chain abstraction over the past few months, many talks in recent conferences have focused on it, and many protocols, infrastructure projects and researchers have focused on abstraction one way or another over this period.

Comprehensive Solutions 

There are a few big players in the comprehensive solution design space – NEAR, Particle, Okto, Polygon AggLayer, and OP Superchain. These 5 solutions can be further broken down into ecosystem agnostic (NEAR, Particle, Okto) and ecosystem specific (AggLayer and Superchain). Put simply, the difference between agnostic and specific is the breadth of the CA solution. 

All chains on Polygon’s AggLayer are joined by a single bridge contract, this makes transferring value between chains in this ecosystem frictionless, however this UX is confined to Polygon CDK L2s. OP superchain has been designed similarly, a unifying bridge contract connects all the chains in the ecosystem making value transfer between them simple. Ecosystem agnostic solutions offer a solution that is not confined within their respective ecosystems, users are able to both move value between and transact on different chains. All three ecosystem agnostic solutions abstract away perform the role of moving assets on, to, and from other chains on behalf of the user – in essence, this is their primary offering. 

Chain abstraction solutions like NEAR’s have been in the pipeline since 2018, whereas the other protocols are relatively new to the abstraction scene. Given how early most CA solutions are in their development process as well as how differentiated the approaches are, it’s hard to pick out a leader. Thinking about leaders in the space boils down to understanding how much each protocol’s primary offering is used, again given the developmental stage of these protocols, it’s hard to draw comparisons this early. 

Particle 

Acting as a settlement and coordination layer for users across all chains, Particle’s modular L1 (which can be thought of as a base infrastructure layer as opposed to a general purpose L1) aims to deliver a chain abstracted experience to crypto. 

Particles primary offering is Universal Accounts – this allows users to operate with a single address, account balance, and interaction point across all chains (both EVM and non-EVM), while abstracting gas and unifying liquidity. Built on the Cosmos SDK, Particle is intrinsically modular, thus retaining sovereignty while outsourcing key functions such as validation and data availability to specialised actors. Intrinsically modular refers to its ability to function through interchangeable and independent modules that handle different aspects of the blockchains operation. This allows Particle to maintain control over its core functions and governance while also being able to adapt and evolve its modules. 

Particle relies on 3 core modules: 

1. Universal Accounts: these offer a single interaction point, user address, and balance across all chains (both EVM and non-EVM networks).

2. Universal Liquidity: Unifies the liquidity of all chains through the optimistic execution of cross-chain atomic transactions and swaps. This allows users to seamlessly interact with new chains, even if they don’t hold tokens on them.

3. Universal Gas: allows users to pay for cross-chain transactions with any token. 

Particle Network’s Universal Liquidity functionality acts as the underlying layer enabling seamless, atomic cross-chain interactions, enabling the unification of balances within Universal Accounts. Through the implementation of Universal Liquidity, users who leverage applications across chains have an experience akin to that of interacting with a single chain.

Universal Liquidity – a stylized example: 

1. User A wants to buy an NFT priced at 1 ETH on Chain 4 using their USDT, which is randomly distributed on Chains 1, 2, and 3. 

2. By clicking “Buy”, the user bundles UserOperations involving five chains (Chains 1, 2, 3, 4, and Particle Network) into a single signature sent to the Particle L1. 

3. Upon the execution of the above signature, the USDT on Chains 1, 2, and 3 is exchanged for an intermediary token, e.g. USDC, using the corresponding chains’ DEXs (Decentralised Exchanges).

4. The USDC from Chains 1, 2, and 3 is sent to a Liquidity Provider (LP).

5. The LP releases the USDC on Chain 4.

6. The USDC on Chain 4 is exchanged for ETH using a DEX on Chain 4.

7. The ETH on Chain 4 is used to purchase the NFT.

Universal Accounts 

Particle’s Universal Accounts play a central role in Particle’s Chain Abstraction offering, they provide users with a single address, balance, and interaction point across the multi chain ecosystem. Particles Universal Accounts leverage universal liquidity to automatically execute atomic cross-chain transactions as well as pool funds from a user’s balance across chains to meet the conditions of a given operation. Universal Accounts offer users a unified interface within the EVM and non-EVM ecosystem as well as offer them the ability to deposit and use funds on any blockchain. At the heart of Universal Accounts is Particles Universal Liquidity technology, which coordinates cross-chain transactions atomically on a per-transaction basis. Particle Network serves as the settlement layer for these transactions. 

Universal Accounts are essentially ERC-4337 smart account implementations attached to a pre-existing EOA (Externally Owned Address). Protocols implementing Particle’s Universal SDK will assign or resolve a Universal Account attached to a given EOA address, retrieved either via social logins with Particle Network’s Modular Smart Wallet-as-a-Service. That account is then used as the core interface to interact with the application, as well as any other application leveraging Particle Networks SDK’s. 

A hypothetical example for an end-user: 

1. Alice discovers a Play-to-Earn dApp. The dApp is hosted on Arbitrum and leverages Particle Network’s Universal SDK to enable Universal Accounts.

2. Alice starts using the dApp. The assets in her wallet (Polygon-native) are used for basic dApp interactions. Bridging is automatic, executed atomically as she interacts.

3. After playing for a bit, Alice earns some tokens. She uses them to buy an NFT for her friend Bob’s birthday. Unbeknownst to her, the NFT is hosted on Optimism. She can seamlessly send it to Bob’s Universal Account. Importantly, throughout her whole experience, Alice has only used a single gas token.

4. Bob decides to take a loan against the NFT on Solana and use the proceeds to buy a meme Bitcoin Ordinal. He does this in just a few clicks within a few minutes, all through the same account.

Bitcoin, Particle, and Account Abstraction (AA):

The introduction of inscriptions and ordinals has kicked off a renaissance of activity on the Bitcoin Layer 1. 

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

This is where Particle and BTC Connect comes in, they aim to tackle the frictions while bringing the benefits of account abstraction to Bitcoin. BTC Connect enables account abstraction on Bitcoin by unifying users’ Bitcoin accounts and EVM-based smart accounts. This is done by assigning a Bitcoin wallet as a Signer for a smart account on a Bitcoin L2 or EVM network, making users’ existing Bitcoin wallets the sole point of interaction. The architecture takes advantage of the EIP-4337 design (which enables multi-signature wallets, social recovery, and more complex transaction logic at the wallet level_)_ and EVM-compatible chains to introduce a Smart Account, Paymaster, Bundler, and a unique Bitcoin-specific wallet connection Modal. 

As a result, all interactions on the smart account and the original Bitcoin wallet can be controlled through the Bitcoin wallets interface. BTC Connect extends the functionality of Bitcoin wallets. With a single Bitcoin wallet, a user can send native BTC transactions, interact with Ordinals, and execute logic on compatible EVM dApps and Bitcoin L2s. 

This allows builders in the Bitcoin ecosystem to offer users access to gasless trades, account programmability, and many other abstraction oriented features. 

The public key of the Bitcoin wallet is used to execute native BTC transactions as well as generate an EVM EOA. The EOA is used to create a smart account with the Bitcoin wallet as its signer, thus the Bitcoin wallets signatures are EVM compatible. 

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 critical component of chain abstraction. This defragments Web3 for app users and increases their ability to move across networks or between applications. 

NEARs Account Aggregation consists of 3 core technologies: 

NEAR Account – NEAR has been built with native account abstraction, thus a NEAR account maps to a human readable account name as opposed to a public key hash. Moreover, NEAR accounts can hold multiple keys with different permissions for different functions. FastAuth offers users a Web2 like onboarding flow, users sign up with an email and aren’t required to manage a private key. Instead, a FastAuth account and keys are secured via biometric ‘Passkey’ security (think FaceID). Users are also able to recover their account at any time using their email through the multi-party computation (MPC) recovery service. 

Chain Signatures – this allows any NEAR account to control addresses on other chains. With chain signatures, the NEAR MPC network is the signer of transactions on these other chains – there is no need to manage a different wallet & private key. MPC signing allows a number of independent nodes to sign messages with key shares separately generated by non-trusting parties without needing to assemble them anywhere. 

Intent Relayers – in the pursuit of a smooth UX, users should be able to pay on the NEAR network and then be able to transact value on other chains. With intent relayers, a user can specify what they would like done without needing to know how it’s done. The intent relayer network is tasked with monitoring responses from the MPC service, handling signed transactions, submitting them to their respective chains and then completing the final transaction. 

Okto

Okto is a middleware solution designed to simplify the complexities of Web3 for both developers and end-users. It abstracts away the intricacies of blockchain interactions, making it easier to build and use decentralised applications. Okto believes there is a need for an end to end solution that solves for both developer and UX challenges. To that extent, they envision an Orchestration Layer that abstracts Web3 complexities and solves developer/user experiences via solving for the three-pronged challenge of fragmentation (liquidity, tech standards, and user experience). 

Components of the Okto’s Orchestration Layer:

Okto Appchain – A middleware chain that orchestrates transactions without holding user assets or total value locked (TVL). It functions as a rollup-based app chain, inheriting trust from the underlying secure/scalable blockchain. Key sub-components include the Bloc Hub and a unified set of APIs for app developers.

Decentralised Wallet Networks (DWNs) – Enable unified wallet accounts secured by MPC and allow delegated signing based on user permissions, supporting both EVM and non-EVM chains.

Decentralised Transaction Networks (DTNs) – Orchestrate asynchronous transaction management across multiple blockchains and handle sub-transactions for user actions, including nonce management, gas fee estimation, and data indexing.

Okto aims to offer a chain abstraction solution through its orchestration layer, which consists of the app chain, DWN, and DTN. This layer abstracts away the complexity of standards, chains, and protocols, providing a consistent developer experience. It allows developers to build dApps with simpler primitives and better user experiences, focusing on their core products while chain-related complexities are managed by Okto.

Ecosystem Specific Solutions // Aggregated Blockchains 

Aggregated blockchains can be thought of as a blockchain scaling solution that offers chain abstraction as an ancillary benefit. It is reasonable to assume we will find ourselves in a multichain world, no one chain can currently support the throughput required to reach mass adoption. In order to scale blockchains, we need to increase access to liquidity and shared state – adding blockspace isn’t a viable solution if it fragments liquidity. This is the thesis behind aggregated blockchains. 

Polygon AggLayer

Before diving into Polygons AggLayer, it’s important to look over the Polygon ecosystem quickly: 

1. Polygon = A global network of aggregated blockchains

2. AggLayer (unified liquidity) = A protocol that unifies liquidity across a multi-chain network by aggregating proofs from all connected chains, and ensuring safety for near-instant, atomic cross-chain transactions.

3. Polygon CDK (scaling) = A modular, open source collection of tools that allows developers to deploy their own sovereign ZK-powered L2, or permits existing L1 and L2 chains to migrate to the AggLayer.

Polygon comes at the chain abstraction thesis from a different angle, their unified bridge contract offers the benefits of both an integrated (monolithic) and modular architecture through the use of ZK technology. The AggLayer is the interoperability layer that CDK chains connect to,enabling features such as seamless and efficient cross-chain communication and unified liquidity. This brings uniform cryptographic security and atomic composability across aggregated chains without sacrificing sovereignty. Polygon claims that, similar to TCP/IP, the AggLayer will unite the blockchain landscape into a web of zk-secured L1 and L2 chains. 

The AggLayer functions in 3 phases – suppose chain A is a ZK powered chain running in the Polygon ecosystem: 

1. Pre-confirmation: Chain A submits a header for a new block/batch A1 to the AggLayer along with a light client proof. The header includes commitments to all other blocks and bundles that A1 depends on (Bi, Ci, etc). When the new batch is accepted without a validity proof, it’s considered “pre-confirmed” by the AggLayer.

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

3. Finalisation: After A1 is confirmed, its proof is aggregated alongside batches from other rollups into a single proof that is posted to Ethereum. The aggregated proof enforces that dependent chain states and bundles are consistent.

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

Think of an example in which Alice on Chain A wants to lock or burn some tokens in block A1 in order to mint and transfer these tokens to Bob on Chain B. Chain B is required to wait until these A1 is finalised on Ethereum with a valid proof before minting the assets, this process is slow. The AggLayer solves this problem by allowing Chain B to temporarily assume that A1 is valid and will be finalised on Ethereum. Chain B’s sequencer commits to the claimed Chain A state root A1 as a dependency in the header for B    (B1A1) before submitting to the AggLayer. The latency required for Chain B to build B1 is lowered from 20 min to a few seconds. 

The AggLayers unified bridge has a single bridge contract on Ethereum for all connected chains. Each chain has a local copy of the unified bridge root, thus enabling cross-chain transactions that don’t require withdrawing to Ethereum or the security risks of third party bridges. The AggLayer also contains a bridgeAndCall() Solidity library – this allows devs to to program logic that executes calls on different chains. A user is able to transfer assets to a different chain as well as trigger contracts on destination chains. In theory, this offers a UX akin to that of a monolithic chain. 

So, how does AggLayer enable chain abstraction? From a high level, the AggLayer will enable near-instant atomic transactions, unified liquidity across the ecosystem, create better capital efficiency, and offer an improved UX. L1s and L2s that connect to AggLayer can tap into unified liquidity,developers can reach a far wider set of users, and users interact with a UX similar to that of Web2. 

Optimism Superchain 

The OP superchain is a network of chains that share bridging, decentralised governance, upgrades, a communication layer and more – all built on the OP Stack. The launch of the superchain will merge OP mainnet and other chains into a single unified network of OP chains (many chains form the superchain). Unlike multi-chain designs, chains that form part of the superchain are standardised and intended to be used as interchangeable resources. Therefore, applications can be built that target the superchain as whole – abstracting away the underlying chains that the applications are running on. 

OP Stack: 

1. DA layer dictates where raw inputs for an OP Stack-based chain are sourced primarily through Ethereum DA.

2. Sequencing layer controls how user transactions are collected and relayed, typically managed by a single sequencer.

3. Derivation layer processes raw data into inputs for the execution layer, primarily using rollups.

4. Execution layer defines the system state structure and transition functions. EVM is the central module.

5. Settlement layer allows external blockchains to view an OP Stack chain’s valid state with the attestation-based fault proof.

Component Solutions 

Intents

Intents are a type of order in which users specify a desired outcome rather than a specific execution path. Instead of detailing every step of a transaction, users simply state what they want to achieve. External agents called “solvers” or “fillers” then compete to find the most efficient way to fulfil this intent, usually for a fee. They can be thought of as similar to limit orders, but can be applied to a variety of situations (not only trading) like bridging.

In general, intents protocols follow a similar structure:

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

2. Solvers and fillers monitor intents using subgraphs, event-listeners etc. across various intent networks.

3. Solvers/fillers can choose to resolve the user’s intent.

The above structure differs across various protocols and use-cases, especially in terms of what assets are used by solvers/fillers and if they are locked, where they are sourced from etc.

Typically, intents protocols are fit into two categories:

• Intents-based trading protocols

• Intents-based bridging protocols

For all intents and purposes, they both practically have the same function, allowing users to submit an intent and potentially get filled, on or from a different chain.

Intent-based Bridging Protocols

Historically, bridging involved moving assets directly between chains, which has been expensive, complicated and insecure. Generally, traditional bridges can be based on mint-and-burn, mint-and-lock or LP mechanisms, which can lead to issues such as infinite mints or exploitation of liquidity pools or locking mechanisms.

In contrast, intent-based bridging relies on a user expressing their intent, to have a token on a separate chain. The solver can fulfil this request for the user on the target chain, using their own funds. The solver then gets paid back on the origin chain.

Intent-based bridging avoids the need to mint or lock tokens, mitigating some of the issues that may arise from them. However, it has its own drawbacks, more specifically fulfillers/solvers can face issues due to failed transactions and chain reorgs or rollbacks.

Similarly to traditional bridges, intent-based bridging also has to consider liquidity constraints. Intent solvers/fulfillers need to maintain liquidity across multiple chains to execute and fulfil transactions, while also rebalancing these funds periodically. In addition, fulfillers/solvers face capital costs and gas costs (specifically on the destination chain).

The benefit of intents-based bridging are clear:

• They abstract away the backend from the end user. From the user’s perspective, intent-based bridging happens behind the scenes, and the user only has to worry about paying fees to the protocol and the solver.

• They are typically quicker and less complex compared to traditional bridging, since there are less computational resources used and less waiting time required.

As of date, the largest intents-based bridging protocol is Across. Since November 2021, the protocol has bridged over $10B USD in volume across chains they support.

Across

Across enables cross-chain asset transfers through an intents-based system. Users deposit assets on one chain, specifying their desired destination chain. Independent relayers then fulfil these requests by sending the funds to the user on the destination chain. The protocol verifies these transfers and reimburses the relayers.

The protocol relies on a few key mechanisms to fulfil cross-chain asset transfers. The first are relayers. Relayers observe when a user deposits funds on an origin chain, and can then send the requested funds to the user on the specified destination chain. They can use their own capital to fulfil requests and thus can face liquidity constraints. However, Across also has a liquidity pool system, to act as a backup to solve intents. After fulfilling an intent, a dataworker and optimistic oracle system must verify that the intent was solved, so that the relayer can be reimbursed. 

Dataworkers are whitelisted actors who reimburse/refund relayers, rebalance liquidity pools between chains and occasionally perform slow fills (relayers fulfil fast fills and compete against one another in speed for fees). They also monitor Across for filled intents and propose bundles (which recognize rebalances and repayments) to the Optimistic Oracle). The optimistic oracle can then verify the bundle proposed by dataworkers (after a one hour dispute window).

Across’ V3 has focused on building beyond bridging applications and focusing on more complex crosschain interactions. Across+ allows protocols to combine Across’ bridging infrastructure with other transactions, making them into one transaction. For example, an NFT marketplace could allow for users to combine the bridging and minting or bridging and buying interactions into a single transaction. considerably reducing the amount of clicks a user would have to go through, and potentially saving on gas costs and other user experience issues, such as not having assets on the destination chain. In addition to Across+, the protocol also launched Across Settlement, which executes the settlement of cross-chain transactions by allowing implementation of cross-chain settlement logic at the protocol level. With both Across+ and Across Settlement, Across aims at moving away from intent-based bridging, into more complex crosschain interactions, attempting to become a more modular component of crosschain transactions, not only bridging.

Across is particularly relevant in terms of intent-based architecture and protocols, since they’ve been working on standardizing cross-chain intents. UMA, the team behind Across’ optimistic oracle, and Uniswap introduced ERC-7683 earlier this year, which aims at establishing a standard API interface for crosschain intents. ERC-7683 focuses on creating a standardized API interface for crosschain intents aiming to enhance interoperability between different cross-chain intent systems, by:

- Defining a standard CrossChainOrder struct for representing cross-chain orders

- Specifying a ISettlementContract interface for settlement contracts

deBridge

deBridge, similarly to Across, uses solvers and an intent-based architecture for cross-chain asset transfers and smart contract interoperability. It’s made of two layers: the protocol layer and the infrastructure layer.

The protocol layer lives onchain, and consists of a set of smart contracts which exist on supported chains. It handles locking and unlocking of tokens involved in transactions across multiple chains, routes transactions from origin chains to target chains and verifies validators to ensure transactions are legitimate and true. Validators exist as part of the infrastructure layer, which is off chain. The infrastructure layer is made up of validators who operate deBridge nodes, which process and sign crosschain transactions, and full nodes of support chains, which allows validators to monitor and fully verify transactions.

The deBridge Liquidity Network is built upon this two layer architecture. It enables users to create limit orders (akin to intents) for crosschain trades. Similar to how Across works, the DLN allows users to submit an intent, with desired chain, token, size and receiver address. Offchain solvers can pick up intents to fulfil them on the destination chain. To fulfil orders, solvers need to provide details regarding the intent to a smart contract, which needs to verify that the order to be fulfilled matches the ordered submitted. If the order is verified, the contract will pull the necessary amount of tokens to fulfil the intent from the solver’s address and send them to the receiver address

Intents-based trading protocols

Intent-based trading, similar to bridging, relies on professional solvers and market makers to find an optimal path for execution. One of the key benefits this offers users is that not only does it allow users to be fulfilled on a separate, destination chain (similarly to how bridging works), but it can also allow users to be filled from a separate chain to the origin chain. This increases liquidity drastically, as it enables users to access shared liquidity and execution across multiple blockchains, as well as allowing them to potentially access offchain liquidity.

Apart from benefiting from shared liquidity, intent-based trading also allows users to potentially incorporate complex and previously multi-transaction programmatic orders and conditional executions into single transactions. For example users can implement time, volume or price-based conditional order, for assets that may not even exist on the origin chain, through a single transaction. In addition to these relatively simple order types, intent-based trading can even allow users to execute trades based on price movement of another, enable users to perform a series of trades in a particular order, or even allow triggering of trades based on offchain data.

Lastly, intent-based trading enables gasless transactions (to an extent). Users may still have to approve tokens for trading, however protocols like Matcha (0x) enable users to sign gasless transactions, which only submit intents. This allows users to not have to worry about gas fees. Additionally, users have typically had to pay gas for failed transactions, which intent-based designs mitigate.

In addition to simplifying the experience for users, and mitigating some UX issues associated with trading, intents-based trading also enables improved capital efficiency. Solvers, who are responsible for fulfilling trade orders, only need to commit capital when they’re actually filling an order. This on-demand capital commitment allows solvers to manage their resources more effectively and participate in a wider range of markets without increasing their capital requirements. As a result, there’s potential for increased competition among solvers, which could lead to better prices and improved liquidity for traders across various markets.

Everclear

Everclear is an intents based solution that solves for the limitations around how liquidity is rebalanced and settled between chains. They propose a new primitive, the clearing layer, which allows market actors to net flows of funds between chains, before ultimately settling with underlying chains & bridges. Everclear’s clearing layer is built as an Arbitrum Orbit rollup (via Gelato RaaS), and uses Hyperlane with an Eigenlayer ISM to connect to other chains. 

In summary, ‘The Rebalancing Problem’ can be understood as follows: During the process of filling intents, the solver’s funds moves away from chains where they are needed and toward chains where they are less needed. In order to effectively rebalance, a solver to integrate with bridges, aggregators, CEXs, OTC desks, and any other available sources of liquidity for each supported chain and asset. The process of rebalancing is costly and these costs are passed to the user. 

This is where Everclear steps in, they offer a shared system for all market participants to coordinate capital flows and settle between chains. Of all interchain flow, an astonishing 80% can be netted out – this offers a massive opportunity to lower end user costs. Perhaps the solution to liquidity fragmentation is not building another bridge or liquidity layer, but rather helping the existing players to better coordinate. 

Deposits into the system generate an invoice on the Everlear rollup, these invoices represent an obligation (backed by funds locked in gateway) for the system to settle to a user. A stylized example: 

Suppose Alice and Bob are solvers for UniswapX and Across respectively. Alice prefers to fill and settle to Arbitrum. Bob prefers Optimism.

1. Alice fills a 10 ETH tx from Optimism → Arbitrum. Bob fills a 20 ETH tx from Arbitrum → Optimism.

2. Assume that the funds from both original txs (10 ETH and 20 ETH) are deposited into Everclear on Optimism and Arbitrum respectively.

3. Everclear settles Alice’s 10 ETH using 50% of Bob’s 20 ETH deposit immediately to Arbitrum at near 0 cost.

4. Everclear wants to settle Bob, but there is only 10 ETH on Optimism to settle into. The system auctions off his invoice, discounting its price from $1 to $0.99

5. Charlie notices this and deposits 9.99 ETH on Optimism. Everclear settles Bob into 19.99 ETH on Optimism. Charlie now holds an invoice for 10 ETH, having made a profit of 0.01 ETH.

Both Alice and Bob end up back on their respective chains, ready to fill more transactions. Importantly, this happens with 0 operational work on their side and with near 0 cost.

IntentX

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

The platform leverages SYMMIO as its settlement layer, utilizing 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 symmetrical contracts - a set of trustless and permissionless smart contracts based on bilateral agreements.

These symmetrical contracts continuously monitor the solvency of all participants and mediate any parameter disagreements. This ensures trustless and permissionless settlements of derivatives between parties. In essence, SYMMIO pairs a requesting party with a responding party, locking them into an isolated, symmetrical trade.This looks similar to how an intent is fulfilled in Across or deBridge:

1. Users submit intents specifying position details and whitelisted solvers.

2. Whitelisted solvers monitor intents using subgraphs or event-listeners.

3. The first solver to lock an intent can open the position if it aligns with their policies. Solvers may hedge the position on secondary markets or choose not to hedge.

4. Open positions include intent ID, fill amount, average price, and an oracle signature.

5. The oracle signature ensures solvency for both trader and solver, preventing liquidation-causing positions.

One of the key benefits that IntentX/SYMMIO offers is the ability to source liquidity from other chains and potentially even from CEXs. Since solvers can source liquidity from multiple sources, and tap into crosschain liquidity pools, users can receive more favourable prices, and large orders can be filled with minimal price impact.

Typically, without intents-based trading, to source liquidity from other chains, users would have to bridge over, increasing complexity on their end. Instead, this complexity and risk is passed onto the solver, who may have to hedge their positions, and receives a taker fee in return for fulfilling intents.

Account Abstraction

Account abstraction allows users to store their assets in smart contract based wallets, as opposed to EOAs (External Owned Accounts). This allows for increased programmability and functionality.

EOAs versus Smart Contract Accounts

EOAs and smart contract accounts are the two main types of accounts in blockchains, each with distinct characteristics and specifications. EOAs are controlled by private keys, offering direct user control, while smart contract accounts are governed by smart contracts onchain, providing programmability.

EOAs are created offchain by generating a public-private key pair (a typical wallet setup process), which incurs no fees. In contrast, smart contract accounts are created onchain through a transaction, which requires gas fees.

Although EOAs provide basic but essential capabilities for blockchain interaction, such as sending transactions, interacting with smart contracts, and managing native assets, smart contract accounts can perform more complex operations based on their programmed logic, allowing for sophisticated and automated transaction types and onchain interactions. This is because smart contract accounts contain EVM code and storage, enabling them to execute complex operations and maintain state on the blockchain.

Gas fee management differs between these account types as well. EOAs require the native token for gas fees, necessitating users to maintain a native token balance for transactions. Smart contract accounts can potentially use alternative fee mechanisms, offering more flexibility in how transaction costs are handled. An example for this is the system of paymasters introduced by ERC-4337 and EIP-7702, which allow subsidized gas payment.

Account abstraction may seem only tangentially related to chain abstraction, as it doesn’t directly abstract away crosschain interactions. However, it introduces several key improvements to user experience that enable chain abstraction.

It allows users to interact with protocols and chains without the need to pay for gas fees or manage their private keys, simplifying the onboarding process to new chains and appchains. Protocols and chains can pay for users’ gas fees, with paymasters allowing paying for gas across chains, enabling the use of tokens on different chains to pay for fees on the target chain. Gas abstraction allows users to pay transaction fees in a single token across different chains, facilitated by relayers that handle gas payments

In addition, multiple transactions can be combined into a single transaction through transaction batching, reducing overall gas costs. Meta-transactions allow users to sign messages off-chain and have a third party submit the transaction, potentially enabling gasless 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 crosschain atomic swaps.

One issue that has been prevalent in implementing account abstraction into Ethereum and the EVM is that the base layer is significant, given the large amount of assets that exist on it. Changes at the protocol layer are difficult, potentially extremely costly, and are in general avoided. This has been one of the primary reasons why account abstraction has not yet completely flourished on the EVM, apart from implementations from smaller chains (e.g. Polygon PoS has implemented some account abstraction principles) who can be somewhat more flexible.

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 Ethereum protocol level changes, in order to mitigate the potential introduction of fragility at the consensus level. Instead ERC-4337 introduces Account Abstraction Using an Alt Mempool. 

ERC-4337 introduces several new components for the purpose of account abstraction. UserOperations allows users to bundle transactions together, instead of performing a sequence of transactions manually, one-by-one. The simplest example is token approval and token swapping, which typically takes two separate transactions, which can instead be bundled into a single transaction. Bundlers (who are typically validators or searchers) take UserOperations submitted and batch them together with others to submit them. Submitting UserOperations can be handled through contract accounts, which can programmatically initiate transactions based on a set of instructions or goals.

Lastly, ERC-4337 introduces paymasters: smart contracts that enable flexible gas policies such as allowing a dApp to sponsor operations for their users (theoretically enabling free transactions), or accept gas payments in an ERC20 (e.g., USDC) in place of the blockchains native currency (ETH).

Paymasters can cover user operation fees and reimbursing bundlers who execute these operations on behalf of senders.

The process involves several steps:

- Validate the user operation on the sender’s wallet.

- If a paymaster address is provided, validate the paymaster operation.

- Discard any user operations that fail validation.

- Execute the user operation on the sender’s wallet.

- Track the gas used for execution.

- Transfer ETH to the bundler for gas used.

- If a paymaster is involved, the ETH from the paymaster contract covers the gas fees.

- If no paymaster is used, the sender’s wallet reimburses the ETH.

Paymasters remove UX friction and open up new patterns for users, by allowing users to pay network fees with non-gas tokens instead, or even request any third party to cover those fees altogether.

EIP-7702

EIP-7702 introduces a new transaction type allowing EOAs to temporarily function as smart contract accounts. 

It achieves this by adding a `contract_code` field, which allows EOAs to adopt smart contract code and functionalities for the duration of a single transaction, enabling features like gas sponsorship and batch transactions without permanent migration to smart contracts. 

Building on ideas from EIP-3074, EIP-7702 takes a more conservative approach by making the upgrade ephemeral and avoiding the introduction of new opcodes. The proposal introduces key features such as batching (allowing multiple operations from the same user in one atomic transaction), sponsorship (enabling one account to pay for a transaction on behalf of another), and privilege de-escalation (allowing users to sign sub-keys with specific, limited permissions).

It’s designed to be forward-compatible and aligns with ERC-4337, allowing existing wallets and infrastructure to leverage the temporary upgrade mechanism. The proposal introduces minimal changes to the Ethereum protocol, focusing on core functionality of temporary smart contract account upgrades. In practice, an EOA gets an ephemeral account code for one transaction, which is executed when the transaction is sent, performing operations as a smart contract would. After the transaction completes, the account code is discarded, reverting the EOA to its original state. It is expected to be included in Ethereum’s upcoming network upgrade called Prague/Electra (Pectra).

Similarly to ERC-4337, EIP-7702 allows for a third party, known as a paymaster, to cover the transaction fees  on behalf of the user. 

With paymasters under EIP-7702, a user could interact with Ethereum-based protocols without needing to hold any ETH. Instead, the paymaster contract would cover the gas costs.

Compared to ERC-4337, the  gas sponsorship mechanism in EIP-7702 is flexible. It allows for various models of sponsorship:

1. Free sponsorship: An application might cover all gas costs for its users to encourage adoption.

2. Alternative token payment: Users could pay for gas using ERC-20 tokens instead of ETH. The paymaster would accept these tokens and pay the actual gas fee in ETH.

3. Subscription models: A service might offer gas sponsorship as part of a subscription package.

4. Conditional sponsorship: Paymasters could set conditions for when they’ll cover gas fees, based on transaction type, user behavior, or other factors.

AI Agents

AI agents are onchain entities capable of taking action after receiving commands, prompts or intents from an external actor (i.e. a user).

They are general-purpose AI systems designed to interact with smart contracts onchain. They can be either user-controlled or autonomous. They can execute complex, multi-step tasks autonomously, interact with smart contracts and protocols, provide personalized assistance and recommendations to users, and craft and execute blockchain transactions based on user inputs. They are designed to navigate the crypto, including understanding onchain interactions and mechanisms, wallets, protocol mechanics, DAOs, and smart contracts.

The key components of AI agents onchain can be broken down into three essential parts:

1. User’s Crypto Wallet: This serves as the foundational element for secure key management and transaction execution. The wallet enables users to sign and authorize transactions recommended by the AI agent, ensuring secure and authenticated interactions with blockchain-based applications.

2. Specialized Crypto-focused Language Model: At the core of the agent’s intelligence is a Large Language Model (LLM) specifically trained on extensive crypto datasets. This includes comprehensive information about blockchains, wallets, decentralized applications, DAOs, and smart contracts. The specialized training enables the agent to effectively navigate and understand the complex crypto environment. Importantly, this LLM is fine-tuned to evaluate and recommend the most suitable smart contracts to users based on predefined criteria, with a strong emphasis on safety.

3. Long-Term Memory System: This component involves storing user data and information about connected applications, either locally or on a decentralized cloud. It provides the AI agent with broader context for its actions, allowing for more personalized and accurate assistance based on historical interactions and user preferences.

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

Perhaps most significantly, they have the potential to greatly simplify and improve the crypto user experience, particularly in the context of crosschain interactions. Instead of manually navigating different chains and token types, users could simply tell their AI agent, “Swap $100 worth of ETH to USDC and send it to Alice” and the agent would handle the technical details, ensuring that the most liquid and cheapest route is taken. Apart from simple interactions, they can additionally fulfil more complex operations, such as yield farming or LP rebalancing crosschain, without the need for the user to actually go through click flows. Instead, users could give the agent natural language commands.

Unfortunately, AI agents and their potential onchain applications have not yet been possible. Recent AI agent protocols are not useful, and have not reached their full potential. We’ve highlighted two protocols that we believe may be relevant, but they are still in their early stages. One major concern with regard to AI agents, especially onchain, is potential misbehavior, either maliciously or on accident. Since users allow these agents to use their capital, it is understandable that they may hesitate to trust them completely, especially since AI models tend to hallucinate or not follow prompts and instructions. Some precautions can be taken against this, such as setting limits or injecting prompts periodically to ensure proper behaviors - but these are more band aid fixes.

However, AI agents represent a genuinely vast potential improvement to crosschain interactions, potentially removing the need for users to interact onchain at all, allowing them to instead only give prompts using natural language commands. 

Wayfinder

Wayfinder is a chain-agnostic AI agent framework and toolkit designed to operate on the Solana blockchain. Its primary function is to provide AI agents with an interface to interact with blockchain technology and execute transactions. To facilitate this, Wayfinder implements verification agents that evaluate and propose new interaction and execution paths for AI agents. These paths define the processes and steps AI agents follow to perform specific transactions. While AI agents can use these paths to execute transactions, they operate within defined constraints. They can only perform authorized actions like swaps and cannot spend funds without owner interaction.

Morpheus

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

The Morpheus network involves four key stakeholders: Coders, who develop smart contracts, off-chain components, and smart agents; Capital Providers, who commit stETH to the network’s capital pool; Compute Providers, who supply compute power, mainly GPUs; and the Community, which creates frontends for interacting with the network and its smart agents, and works to expand the ecosystem. To align incentives for accessing inference, the project employs the Yellowstone compute model, which operates under a simplified structure designed to manage resource allocation and usage within the ecosystem.

Conclusion

The proliferation of rollups, new chains, and appchains in crypto has led to significant fragmentation of liquidity, users, and a decline in user experience, as a result of both well-intentioned efforts (consistent innovation and new improvements at the protocol level) and misaligned incentives (the valuation premium placed on infrastructure).

This fragmentation has resulted in a complex and often frustrating user experience, where users must navigate multiple chains, bridge assets, and manage different gas tokens. For developers, it means having to launch on numerous chains and attempt to bootstrap liquidity and users across all of them.

Chain abstraction emerges as a potential solution to these issues. It aims to provide a user experience exempt from the manual processes required to interact with multiple chains. This includes abstracting away the complexities of bridges, gas tokens, account and wallet fragmentation, liquidity fragmentation, and key management. The goal is to create an experience akin to traditional internet applications, where users can interact with blockchains without the steep learning curve.

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

Intent-based protocols, both for trading and bridging, show promise in simplifying cross-chain interactions and improving capital efficiency. They allow users to express desired outcomes rather than specific execution paths, with solvers competing to fulfill these intents efficiently. This approach can potentially unify liquidity across chains and simplify complex cross-chain operations.

Account abstraction, particularly through proposals like ERC-4337 and EIP-7702, offers improvements in user experience by allowing for more flexible gas payment mechanisms and enabling smart contract functionality for standard accounts. These innovations could significantly lower the barriers to entry for new users and simplify interactions across multiple chains.

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

Chain abstraction is crucial for crypto moving forward, especially given that Ethereum has adopted rollups as its plan to scale, and the modular thesis and appchain narratives continue to grow. By solving the issues of fragmentation and complexity, chain abstraction can create a more unified, user-friendly onchain experience.However, it’s important to note that chain abstraction itself faces challenges. The fragmentation of chain abstraction solutions ironically mirrors the problem they’re trying to solve. Many of the proposed solutions are still in early stages of development and face significant technical and adoption hurdles.

Notably, there has been a wide array of research on chain abstraction over the past few months, many talks in recent conferences have focused on it, and many protocols, infrastructure projects and researchers have focused on abstraction one way or another over this period. Given this focus, it is likely that UX and fragmentation improvements will be made over the next few years.

Disclaimer:

The information and services above are not intended to and shall not be used as investment advice.

You should consult with financial advisors before acting on any of the information and services. ASXN and ASXN staff are not investment advisors, do not represent or advise clients in any matter and are not bound by the professional responsibilities and duties of a financial advisor.

Nothing in the information and service, nor any receipt or use of such information or services, shall be construed or relied on as advertising or soliciting to provide any financial services

Follow ASXN on Twitter