Abstraction to adoption
On the industry deciding crypto should be easy to use (or making a new buzzword?)
Chain abstraction has become the hot topic of right now, and for obvious reasons — everyone in crypto should be excited about tools that make it easier for consumers to engage onchain.
But much of the discourse is lacking perspective on how we got here in the first place, and I believe that it starts with the fact that developers are consumers too — and right now, they’re forced to choose among different ecosystems, tech stacks, and communities. This creates a lock-in mechanism and sometimes steers developers away from focusing on the right problems due to perverse and unsustainable incentives. Developers are users too, and they shouldn’t have to choose where to build.
A core challenge for developers is trying to integrate their applications with a bunch of different tech stacks and infra underneath — or building infra that works across a variety of apps — and dealing with community allegiances across ecosystems. It doesn’t help that there are also (what feels like) a million different standards in crypto.
Historically, this has often forced developers to “just pick one” ecosystem to build on — the makers of ecosystems know this and aggressively compete for developer attention, leading to further lock-in and unsustainability. The result is projects choosing halfhearted multichain expansion or going heavy into a singular siloed ecosystem. Both have issues, which chain abstraction is (hopefully) beginning to solve.
The end goal of chain abstraction is simple: developers can deploy anywhere — since it no longer matters to reach users — and users can seamlessly interface across ecosystems, with any liquidity and on any chain. Convenience sells, and the biggest beneficiaries may be those (increasingly consolidated) interfaces that users submit orderflow to.
Chain abstraction as a concept is broad, loosely defined, and, some argue, completely fake. Rather, it’s just a set of primitives, infrastructure, and tooling that simply make things easier for both the user and developer — and many things fit into the “chain abstraction” scope. I subscribe to the latter belief, and at the same time think these advances in aggregate are a positive and necessary step for the industry.
Below, I’ll go over a non-exhaustive overview of some of the companies building chain abstraction solutions, and share my prediction for the future.
CEXs as a subset of chain abstraction
The most used “chain abstraction” platform — though limited in the amount of assets it offers, and the fact that it’s centralized — is perhaps Coinbase itself. Via one interface, users can buy and sell all kinds of tokens across different chains, albeit in a custodied manner. This is one of the main reasons that Coinbase has had such strong adoption — and revenue — and it bodes well for the chain abstraction space at large. It proves that convenience sells, and users value and are willing to pay for functionality and simplicity in one interface.
This theme has proliferated into many different decentralized protocols, each working to make one or many onchain steps easier for the user and developer.
Core layer infrastructure
For chain abstraction to really take off, some argue that fundamental changes need to be made to established standards in crypto. One such case is OneBalance, which is working on natively augmenting the pre-existing JSON RPC (industry standard in crypto) so that the new standard allows apps to talk directly with wallets. Their new API essentially is backwards compatible with Ethereum, Bitcoin, Solana, and any assets and smart contracts that live on those chains. Beyond transacting across the three most dominant chains, this architecture — known as the CAKE framework — includes gas abstraction, social recovery, and auth as well. Users benefit from fast state transitions since solvers can request a state transition on a destination chain without waiting for finality on an origin chain. The end goal here is for wallets, specifically Metamask, to integrate their account model so users can directly benefit from this new architecture. Concretely, this means that users could in theory buy WIF with ETH at the speed of Solana (vs Ethereum).
Another company, Orb Labs, is aiming to be a chain abstraction provider that addresses chain abstraction on the node-level instead of the account-level. Their system is composed of the OrbyEngine (a smart RPC endpoint that can be leveraged by wallets to aggregate and orchestrate account state across all chains) and the OrbyKit (a dapp SDK that provides the same functionality to app frontends). The OrbyEngine aggregates and orchestrates account states using a combination of a general purpose intent protocol and a special node called an account unification node.
Together, they allow any wallet or dapp to enable chain abstraction, gas abstraction, etc with as little as five lines of code. This dynamic fundamentally changes the way users interact with wallets, apps, and chains, so they no longer have to worry about bridging and manually moving assets across ecosystems. The chain simply disappears because no matter where users are, they can transact using all of their accounts and assets from other chains. This fundamentally shifts the idea of a wallet as a medium to connect with specific chains to a chain-agnostic connection mechanism wholly concerned with managing the relationship between users, assets, and dapps.
NEAR, which also sits on the core infrastructure side, has natively integrated chain abstraction directly into their L1. With their chain abstraction stack, developers can:
Instantly opt to subsidize gas fees for their users — this includes cross-chain transactions via NEAR’s Multichain Gas Relayer.
Leverage NEAR’s multi-chain signature service, which enables users to use their NEAR account to transact on other chains.
Use FastAuth, giving users a familiar web2 experience of signing up for (or recovering) a NEAR account with their email addresses.
These primitives are key to enabling more seamless experiences for developers, which then extends positively to users via what’s created with these types of stacks.
Unification via bridges
Moving a layer up, there are many bridge providers working on chain abstraction — the most notable of which is Across. The protocol has a full-fledged (shipped) intents engine where relayers compete to fill users’ orders via the most optimal execution path.
Today, Across is the only live cross-chain intents-powered bridging protocol that actually works for large and small amounts. And the market is responding: Across has processed nearly $10B worth of volume and 6m+ transactions. Developers can also easily integrate Across+, their bridge abstraction framework, into dapps to natively enable chain abstraction. This serves as an early proof-of-concept of what chain abstraction is capable of, and how the market values it.
Socket, the makers of Bungee (a bridge aggregator), is also working on chain abstraction solutions via modular orderflow auctions, where users submit intents and solvers compete to fill. Via the SocketPlugin, devs can add a widget that integrates Bungee (Socket’s bridge aggregator that enables cross-chain asset transfers) directly into their project. Most of the time, Bungee actually routes through Across, with Across reaching ~50% of its volume share as of late June. And among Socket and other aggregators, Across is quoted as the cheapest bridge ~78% of the time.
Integrated swaps
More than bridging (and staking, minting, lending, …), swapping is the number one most popular action users take onchain — and therefore the biggest TAM for projects to leverage. Platforms like UniswapX and Matcha focus on swapping and aim to abstract away gas, aggregate liquidity sources for cheaper trading, and enable efficient cross-chain trading. Usually, this involves solvers of some sort that compete to satisfy orderflow in the most efficient way. Solvers pay gas on behalf of swappers, improving efficiency by batching orders together to compete for a better price, and the user benefits from not having to worry about gas tokens.
Middleware frameworks + interfaces
Some teams are building layers that power these protocols — Light, for example, can sit a layer below other cross-chain interoperability protocols (including potentially Across, UniswapX, …) and acts as middleware that powers chain abstraction that users interact with. Interestingly, Light supports any configuration — conditional, DCA, intent graphs, etc — across multiple chains expressive within the EVM, while most intent-based protocols only support limit orders, at least to start. In addition, Light uses an orderflow auction where users can programmatically define conditions, security, and settlement of cross-chain transactions which helps to ensure the best execution.
Another project in this space, Genius, is collaborating with Lit Protocol to build a chain abstraction solution where Lit serves as the underlying signature scheme on Genius’ liquidity architecture. Initially, they’ll support EVM, SVM, and Bitcoin, and are focusing on launching a decentralized relayer and aggregating liquidity versus going the intents route.
Intents as a subset of chain abstraction
Intents tend to focus on swaps specifically, where the end goal is to allow a user to transact with any asset, across any chain, without the need for bridging. These ones have caught my attention recently:
Slingshot is an intent-based onchain app where users can trade across different chains in a bridgeless, non-custodial way. By creating an incredibly simplified UX — no gas token, no connect wallet button, no bridging, sign in on any device, one click buy and sell — users are more willing to engage onchain. The drawback here is that users are ultimately limited by the amount of money held in each supported chain’s vault, but regardless, this architecture encourages more activity across more chains.
Blackwing is working on a decentralized exchange abstraction layer powered by Initia. Their edge is enabling liquidation-free leverage to traders by using Uniswap LP positions to collateralize margin positions. This effectively reduces downside risk for heavy losses while also turbocharging gains.
Essential is developing their own intents-oriented optimistic L2 where solvers directly propose their solution to an order in the form of new state. Here, fraud proving is concise in that incorrectness can be proven by showing that one constraint wasn’t satisfied, which is then posted to the L1. Developers can directly leverage Essential’s DSL to write applications with a built-in intents framework, which enables a broader and more complex set of applications to exist and interoperate on their L2.
These are just a few of many companies building in intents — for those interested, I wrote an article a few months ago that digs deeper into the space.
Towards mass adoption, via abstraction
Just like you can access any website regardless of the browser or OS you’re running, you should be able to access any crypto ecosystem regardless of the chain it is built on. And no matter what tech stack developers are building on, they shouldn’t be disadvantaged from accessing certain users in different ecosystems. Achieving this is definitely easier said than done, but once it happens, I believe it’ll serve as one of the bigger catalysts for mass crypto adoption.
Thanks so much to Joey Krug and Gaby Goldberg for their help on this piece.
I'm curious how this would look from a MEV standpoint. So apps will be probably roll up a bunch of intents and submit them to a L2/L1 for finalization? Will the app itself then order the resulting txes for MEV or will it be the rollup or will the masses do it? Food for thought I guess.