What is Chain Abstraction? Arriving at a Formal Definition

TL;DR for non-nerds: “Chain abstraction” is a term already widely used in Web3. It refers to creating infrastructure that allows anyone to use decentralized applications without being aware of the problems associated with interacting with their underlying chains (such as bridging assets, managing multiple gas tokens, balances etc.)

To continue impulsing this technology—which aims to make Web3 more usable and, therefore, accessible to the masses—we are proposing to formally define chain abstraction as “A user experience exempt from the manual processes required to interact with multiple chains.” This definition emphasizes chain abstraction as a user experience rather than a technology, fostering an inclusive field where different approaches work together to attain an ecosystem-wide goal. It’s also congruent with the organic developments in the field while remaining unattached to any single approach to facilitating chain abstraction.

–Many thanks to Everclear , Agoric and Frontier Research for their feedback.

Introduction 

“Chain abstraction” as a term has grown significantly in usage in 2024. Yet, its exact definition remains broad and elusive. 

Chain abstraction holds a slightly different meaning and scope depending on who you ask –not unlike other early verticals, such as intents, RWAs, Web3 AI, etc. This lack of a widely acknowledged definition speaks positively about the term’s organic origin in response to the very real problem of a fragmented user experience across blockchains. However, lack of clarity can also be detrimental to the vertical itself, making the concept either too broad (rendering it irrelevant) or too narrow (reducing its scope and perceived impact).

This article will seek to produce a formal definition of chain abstraction that: 

• Improves social consensus among different initiatives pursuing it.
• Drives a better understanding of the vertical and what it attempts to achieve.
• Solidifies chain abstraction as an ecosystem-wide goal

What is “chain abstraction” really trying to say?

“Chain abstraction”, while growing in popularity, is undoubtedly a confusing term. 

The word “abstraction” is used commonly in computer science. One of its definitions is:

“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”

Abstraction layers are universally present at every level of computing and networking. Thanks to them, systems like the Internet can remain simple and accessible yet contain immense complexity underneath. Something as simple as sending an email actually comprises multiple such complex processes and protocols, all of which are abstracted away from the user so that they only have to access an application, write their intended message, enter a destinatary address, and click “send”.

In the Web3 world, the term has been used in concepts like “account abstraction”. Account abstraction refers to the removal of traditional account structures from the experience of end-users, aiming to minimize the amount of interactions a user has with their account to achieve their goals.

But, what exactly does chain abstraction seek to abstract?

Since “chain abstraction” doesn’t outright tell us what about a chain needs to be abstracted, it can be helpful to first define the problem chain abstraction seeks to address. Luckily, there is a broad social consensus for this, which can be summarized as follows:

Chain abstraction aims to solve the fragmented user experience in Web3 stemming from the proliferation of public blockchains, including L2s and even L3s. This fragmentation results in multiple user experience (UX) problems for users –such as costly and time-consuming cross-chain operations, the need to hold multiple gas tokens, etc.– and is detrimental to Web3's adoption, as it requires highly technical and proactive users with liquidity spread across multiple chains, siloing dApps within an ever-growing number of ecosystems. Simply put, in a chain-abstracted world, a user connects to a dApp and purely signs an operation which may span any number of chains, automatically being executed and settled.

This consensus has lead the industry to organically spark several organic definitions of “chain abstraction”, which typically include the following:

• Some would say that the concept refers to abstracting “the difficulties of dealing with multiple chains”.
• Most will agree that chain abstraction is a much-needed evolutionary step for Web3's UX (i.e., a goal to be attained).
• Similarly, there’s an implicit agreement that chain abstraction should eliminate the manual process of users bridging assets from one chain to another to use multiple dApps.

From this, two few points can be extrapolated toward creating a formal definition:

1. It is more useful to consider chain abstraction as a collective goal rather than a specific technology or service. As such, “chain abstraction” can be considered a type of user experience, vision, or flow that can be encountered within certain realms but not in others.
2. Since “chain abstraction” primarily refers to a kind of user experience, any component that partakes in attaining it (other than the original, native infrastructure from which the problem stems) can be considered to enable or power chain abstraction.

To define chain abstraction, then, it’s helpful to first define exactly what the “difficulties of interacting with multiple chains are”, and what addressing them constitutes.

Interacting with multiple chains: Defining issues and solutions

Above, we’ve mentioned bridges, undoubtedly the most common and acknowledged pain point for users when they refer to their experience interacting across chains. However, other issues that stem from the fragmentation of Web3’s UX are:

1. Gas tokens: Perhaps one of the biggest friction points (i.e. annoyances) for users, besides the need to manually bridge tokens, is the need to acquire and manage separate tokens in different chains solely for gas purposes.
2. Account/wallet fragmentation: Another considerable pain point is the need to interact with multiple accounts for a user to access their whole balance. This issue becomes even greater in the case of non-EVM ecosystems, where a separate address and often wallet are needed, resulting in the need to handle multiple applications.
3. Chain-specific applications: Given the fragmentation of the ecosystem, multiple applications and opportunities are often siloed within certain chains, forcing users to undergo the above pain points to access them. Alternatively, this results in greater development costs, as deploying applications across multiple chains is often a burdensome process for developers.

The solution to these issues via chain abstraction would, therefore, entail a user experience where a user can:

1. Use fewer tokens as gas units than they otherwise would (ideally zero or one).
2. Maintain one balance usable across every application, regardless of its underlying chain(s).
3. Interact with any application without manually bridging tokens.

Or, perhaps more broadly, simply have the manual processes required for these interactions removed from users’ overall experience (while still retaining the option to return to these manual, chain-specific processes).

Narrowing down a definition

Having established users' different pain points, what a “chain abstracted” solution would look like, and the fact that chain abstraction should be used to refer to a type of user experience, we can gather a series of key elements that need to be accounted for in a formal definition.

As a recap, these points are:

• Chain abstraction should address the main complexities associated with interacting with a multi-chain ecosystem.
• Chain abstraction refers to an overall user experience, not the specific technology(-ies) making it possible.
• The chain abstraction experience should allow the user to interact with multiple chains and their dApp ecosystem, knowingly or unknowingly.
• Chain abstraction should free the user from interacting with any external interfaces or products (such as manually bridging assets) to achieve their goals across chains. 
• Chain abstraction should reduce the amount of manual steps users need to follow for basic functions, like managing their accounts and paying for gas across chains.

As such, we can give chain abstraction the following definition:

Zooming into this definition

Importantly, the definition above is tailored in a way that can encompass the variety of approaches we’ve seen to chain abstraction, from the comprehensive solutions by Particle Network or Polygon’s AggLayer to the foundational role cross-chain messaging solutions –like Hyperlane or Axelar– play in it. It’s also congruent with previous categorizations and analyses of the chain abstraction stack, such as those present in the CAKE framework and the pieces published by Particle Network and Agoric (1) (2).

Furthermore, under this definition, all infrastructure that in some tangible capacity enables experiences of this nature could be deemed as contributing to chain abstraction. It also allows other broad categories, such as intents and account abstraction, to continue referring to a broader experience or set of technologies while remaining directionally aligned with chain abstraction, solidifying chain abstraction as an organic industry-wide evolution.

Limitations and challenges

Arguably, criticism of this definition could arise from two angles:

• Directional disagreements: Projects and individuals working on chain abstraction could disagree with our view of chain abstraction as a type of user experience (or goal/movement), and approach it as a technology to develop/acquire. To address these cases, “Suggestions for commercial use” below briefly touches on a few recommendations for projects building within this vertical. For a wider view of the matter and why we understand chain abstraction as a gradual/joint process, visit the CAKE framework or our articles on different approaches to chain abstraction and its multiple levels.
• Methodical disagreements: It is entirely possible that some players might see the idea of solving Web3’s fragmentation as a worthy goal, but disagree with the processes the industry has followed thus far, which are covered within our definition. Certainly, there are voices that advocate for different approaches –including the return to the usage of siloed monolithic chains– considering that chain abstraction standards are impossible or impractical to attain. In such cases, we suggest those solutions find a different terminology since using “chain abstraction” might be detriment to both conceptions.

Suggestions for commercial use

Finally, it’s important to briefly discuss the usage of “chain abstraction” as both a branding concept and an industry-wide narrative, two deeply interrelated factors.

The definition and considerations presented in this article highlight the usage of the term as a user experience that can be enabled by the collective implementation of a stack of technologies. This definition aims to foster an inclusive environment that fulfills Web3’s secure and decentralized scalability roadmap and correspondingly enables the fair usage of distinct solutions and discourages monopolistic practices. 

As such, we invite projects building within this vertical to adopt this definition and its underlying mindset, abstaining from branding their projects as a single or ultimate enabler of chain abstraction. This not only reflects the ecosystem’s ideals and promotes healthy competition/collaboration but also has a better possibility of capturing much-needed ecosystem and directing it toward a major problem hurting Web3’s adoption.

About Particle Network

Particle Network is addressing Web3's fragmentation of users and liquidity through Universal Accounts. Particle's chain abstraction is powered by a Cosmos SDK L1 blockchain enabling the experience of a single account, balance, and address that can be used across all chains, allowing users to interact with any dApp and pay gas with any token.

Website | Docs | Discord | Twitter