Chain Abstraction Providers and why everyone is wrong about chain abstraction

Chain abstraction has been a hot topic in crypto for the last few years. However, this year, it has taken center stage due to the rapid increase in chains and the associated degradation in crypto UX from account fragmentation. In this piece, we will explore three ideas; each meant to chart a path leading to what we will show as the endgame of chain abstraction.

The first explores the essence of chain abstraction and why current attempts at the problem cannot meet user needs. The second discusses chain abstraction as an orchestration and coordination problem rather than an account, interoperability, or standard problem. The last focuses on chain abstraction providers and the endgame of chain abstraction.

The essence of chain abstraction and why current attempts at chain abstraction are incapable of meeting user needs

There is a massive disconnect between what users and builders mean when they say chain abstraction. For users, it’s from the perspective of access to their accounts. Crypto accounts are like mosaics. Each chain has a fragment of the user account, but none of them has the whole picture. Currently, users are interacting with apps using fragments of their account. When users say chain abstraction, they are effectively saying they want to be able to interact on any chain with their full accounts and not just fragments. For users, the essence of chain abstraction is to bring these account fragments together and allow users to leverage their full accounts when interacting with any app on any chain.

Most teams working on the problem do not necessarily hold the same perspective on chain abstraction. You can ascertain this by examining their approaches to solving the problem. Currently, there are at least three perspectives on chain abstraction.

1. The first perspective is that chain abstraction is an account extensibility problem. Projects building new account systems typically hold this perspective. For developers building in this category, the missing piece for chain abstraction is an extensible account system linked together by a single key. Hence, Near is building an extensible MPC account system.
   The issue with this view is that extensible accounts do not automatically give you chain abstraction. We know this because we already have extensible account systems linked together by single keys, i.e., EOAs. EOAs have the same address across all chains using the same VM, and the same key controls the accounts. However, EOAs don’t have chain abstraction in the EVM, which shows chain abstraction is not simply a byproduct of account extensibility. Furthermore, there is nothing innate about an extensible account that enables users to use their whole accounts on every app on every chain.
2. The second perspective is that chain abstraction is primarily an interoperability problem. This view is typically held by interop projects, e.g., messaging protocols, shared sequencers, agglayers, composable bridges, etc. For folks building in this category, the missing piece for chain abstraction is the ability to call an application on one chain from another.
   Now, there are two problems with this view. First, we have had the ability to call applications across chains for at least 2–3 years, but most users will agree that we are far from chain abstraction. Second, being able to call an application from another chain does not mean that you, as a user, are leveraging your whole account, i.e., all your account fragments, to interact with the application.
3. The third perspective is that chain abstraction is a standard or framework problem. This view is typically held by teams looking to create standards or frameworks, i.e., the CAKE Framework. For folks building in this category, the missing piece for chain abstraction is a standard or framework that unifies existing layers and products to enable chain abstraction. The CAKE framework, for example, lists those layers as the application, permission, solver, and settlement layers. The primary purpose of the standard is to define a mechanism for these layers to interact. It’s important to note that it is not a fleshed-out solution to chain abstraction. In many ways, it’s just a placeholder meant to spark conversation, and it is bound to evolve into something else as the solution to chain abstraction becomes more apparent. That said, there are two issues with this view that standards are the missing piece to chain abstraction.
   First, there is no known configuration of the layers mentioned above that enables chain abstraction. This strongly hints at a missing layer critical to enabling chain abstraction. The need for this layer won’t simply disappear by standardizing how the other layers interact or communicate. Second, until we know the full nature of this missing piece, the call for a standard is premature. There is a world–and as we will show later–where this missing piece is the most critical piece to chain abstraction, and its existence dramatically minimizes the need for a standard. This is perhaps the most glaring critique of frameworks like CAKE: a framework highlighting chain abstraction’s key elements misses the most critical element of chain abstraction. It’s fair to say the framework is helpful as a conversation starter but certainly not a guide for enabling chain abstraction.

None of these three perspectives capture the essence of chain abstraction as far as user needs are concerned. Solutions to almost all the problems mentioned above exist, but we still don’t have chain abstraction. A more accurate perspective of chain abstraction would be that of it as an orchestration and coordination problem.

Chain abstraction as an orchestration and coordination problem

To understand why chain abstraction is an orchestration and coordination problem, we must look back at (1) how users interact on-chain and (2) the reason why we need chain abstraction in the first place. Most crypto interactions happen through application frontends. The typical interaction goes as follows:

1. Users go to the app’s website or page and connect their wallets.
2. The app sends queries to the user’s wallet to determine the state of the user account. The state could be gas tokens, token balance, token ownership, whatever.
3. The user wallet relays these queries to their node providers and returns the responses to the app.
4. Based on the response, the app constrains the kind of actions the user is capable of taking. For example, if you have more than 100 USDC in your account, Uniswap will let you attempt a transaction requiring 100 USDC. Otherwise, it won’t.
5. Once the user selects the action they want to take, the app creates a corresponding transaction, which it then relays to the user’s wallet to sign.
6. Once the transaction has been signed, the wallet sends it over to its node provider for that transaction to be sent to the blockchain.
7. The app’s contract’s on-chain state is altered when the transaction is mined. The change in contract state is picked up and rendered for the user in the application interface.

The purpose of the detailed step-by-step outline is to show that the actions/transactions a user can execute on an app are constrained by the user account’s state that the app receives from the user’s wallet/node. Now, to enable chain abstraction, you need a new layer that does three things:

Each of the steps combats a critical friction point for enabling chain abstraction.

Step 1 addresses the issue we highlighted earlier about an application frontend constraining user actions using a user’s account state. This step ensures that the actions a user can take on an app frontend are determined by their whole account state rather than a fragment of it.

Now, even if a user manages to convince an application frontend to use their whole account state to create transactions, the state onchain may be at odds with the state needed for the transaction to execute successfully. Step 2 addresses this problem by identifying all the state transitions that need to occur across all of a user’s account fragments for the transaction presented to succeed.

Lastly, knowing is not enough. Even if we know all the necessary state transitions for a transaction to succeed because of Step 2, the system must orchestrate and facilitate those state transitions, or the transaction will fail. This is the purpose of Step 3.

All of these are orchestration and coordination problems!

A new category emerges: Chain abstraction providers

With a system to handle the three orchestration and coordination problems described above, you can offer chain abstraction regardless of whatever you do on the account, interop, or standard levels. Any team that wants to provide users with chain abstraction will need access to a system that handles this orchestration and coordination, and building this system is a heavy undertaking.

Steps 1 and 2 necessitate the development of a special node dedicated to account unification. The account unification (AU) node, as we call it, must consistently sync with all chains to create a complete profile of account state for the millions of people using crypto. It must determine the state transitions that must occur across all these chains for any random transaction to succeed. Lastly, it must be able to support queries for this information at any moment’s notice.

Step 3, which is the orchestration and facilitation of state transitions, necessitates the creation of a marketplace for specifying arbitrary chain state. This marketplace could be centralized, but to stay compatible with the ethos of crypto, it’s better to turn it into a protocol. An onchain marketplace for specifying arbitrary chain state is a general-purpose intent protocol with its own DSL and onchain interpreter. Furthermore, much work is needed to extend the marketplace to every chain, including those that do not support smart contracts. Note: It’s important that this not be confused with bridges claiming to use intents, or RFQ exchanges.

The technical overhead required to build this system will necessitate the creation of a new category of middle layers dedicated to chain abstraction. We call these middle layers chain abstraction providers. We know this because we already have an excellent example in node service providers. Very few crypto projects run their own nodes. Most projects avoid it because running and maintaining a node is tedious. Building, running, and maintaining a chain abstraction provider will be just as tedious, if not more.

Chain abstraction providers as the endgame for chain abstraction

Chain abstraction providers are the endgame of chain abstraction. Their ease of integration and noninvasiveness, coupled with the boost they provide to web3 UX, will make them a critical piece of the crypto stack in the same way as node service providers.

Imagine a simple integration, similar to an RPC endpoint, that can provide any wallet using any account system with an onchain crypto experience similar to that of a centralized exchange — being able to interact with any application on any chain with your whole account and all your assets.

Imagine a world where a user with 10 USDC on Ethereum, 5 USDC on Polygon, and 5 USDC on Arbitrum can connect their wallet to an application on Base and execute a 20 USDC transaction while paying gas fees in $WIF on Solana.

Imagine a world where you can interact with applications on any chain using assets in your centralized exchange account, effectively blurring the lines between onchain and off-chain experience.

This is the world enabled by chain abstraction providers.

Next week, we will unveil Orby, the first chain abstraction provider. We at Orb Labs have been working on this for the past year, and it will provide a glimpse into the future of crypto UX.

Work with us

We are always excited to chat about many of the ideas mentioned in this blog post. If you want to chat or learn more about what we are building, find us on X (Twitter) at @0xOrbLabs.