Before we begin…
Chain abstraction has emerged as one of the most discussed topics in crypto over the past few months, and for good reason. Not a single industry expert would argue that the status quo of hundreds of fragmented blockchains is ideal.
However, when one attempts to make sense of this topic, they're confronted with a barrage of jargon—intents, solver networks, clearing layers, and order flow auctions. Even for writers like us, who consider ourselves well-versed in crypto, it became somewhat overwhelming. We needed help.
Vaibhav Chellani is the founder of Socket, the first chain abstraction protocol. Vaibhav has been contemplating blockchain scaling for nearly a decade. As part of the Ethereum Foundation, he contributed to building the first ZK rollup. He also served as protocol head at Polygon, the chain that facilitated Ethereum's scaling when it was most needed. There, he spearheaded the development of the Ethereum-to-Polygon bridge, which now secures over $5 billion in value.
Vaibhav had a front-row seat to the evolving rollup, scaling, and bridging landscape. He anticipated the multi-chain, multi-bridge future we now inhabit and the user experience challenges it would pose for both users and developers. He founded Socket in 2022 to tackle these issues.
To gain a deeper understanding of chain abstraction, we collaborated with Vaibhav and the team at Socket. This piece is the result of that partnership.
If you’re looking to help us tell the story of a complex issue you’re working on, we’d love to chat with you.
Hello!
While it can be dangerous to reason by analogy, today's crypto landscape is strikingly similar to that of the Internet in the early 1990s.
At the time, there was America Online (AOL), often dubbed the 'training wheels for the Internet'. Users spent hours on the platform sending emails, crafting real and imagined personas, discussing niche topics, sharing pictures, and gaming. By 1995, AOL was boasting over three million users, a stock price that had skyrocketed nearly 2,000% in three years, and a brand already iconic in pop culture. All of this despite it buckling under its growing demand.
However, AOL, while an early success, wasn't open. It was a gated network of computers that required users to install separate software and subscribe to AOL's internet service provider (ISP). And AOL was far from alone. CompuServe, IBM's Prodigy, Microsoft's MSN1, AT&T's Interchange Online Network, and Apple's eWorld were all competing for the same prize with similar models of proprietary software, network, and ISP.
This situation was potentially nightmarish for users. If you were on AOL and wanted to chat with a friend on CompuServe, one of you would have to shell out for an additional subscription. Moreover, each network was locked in a battle to secure exclusive media content for their subscribers. The New York Times partnered with AOL, The Wall Street Journal partnered with CompuServe, and access to both required separate subscriptions and connections.
Fortunately, this scenario was fleeting. While these companies plotted online exclusivity and dominance, a group of researchers from Switzerland led by Tim Berners-Lee, along with a ragtag team of college students at the University of Illinois led by Marc Andreessen, were crafting a different vision. They imagined a community-driven network governed by universal standards, open to all for access or development. This network's portal? A web browser.
Today, we simply call it the Internet.
By being open, flexible (the HTML format allowed users to create freely) and standardised, the Internet thrived on network effects and user-generated content. It quickly became the network of choice for users and builders once the polished Netscape Navigator browser hit the market. First slowly, then all at once, the AOLs of the world realised their walled gardens couldn't compete with this brewing behemoth and reluctantly adapted to the Internet.
The Internet united a fragmented landscape and gave way to the greatest technological movement in history.
Today, in crypto, we have hundreds of different blockchains and rollups—each with its own set of wallets, applications, liquidity, users, standards, and culture—all operating in silos. Despite attempts at bridging these silos, the experience remains clunky. This fragmentation results in poor user experience and limits crypto's appeal to a wider audience.
Such variations in ideologies, implementations, and approaches are characteristic of early-stage technologies, as builders are still figuring out what works best. However, as a technology matures and becomes ready to scale, the need to standardise and consolidate arises. Crypto is now at that crucial juncture, transitioning from the domain of early adopters and geeks to a tool for the masses.
The industry recognises this need, and a movement known as 'chain abstraction' has emerged to address it. While the vision for chain abstraction—making the user experience in Web3 as seamless as Web2—is simple, getting there is anything but.
In today’s issue we examine the state of the multi-chain world, the problems it creates, the efforts taken to fix the problems so far, and where chain abstraction and Socket’s solution fits into all of this. We end by discussing a future where chain abstraction leads to a major shift in how value accrues in crypto, changing the face of the industry radically.
Let's dive in!
Disclaimer: This piece discusses crypto's UX issues at length and analyses them from an absolute newcomer's perspective—the kind of users who constitute 'the masses' that we want to onboard to crypto. If you're a crypto-native, you might not relate to these issues as strongly.
A Thousand Chains
In the beginning, there was Bitcoin. A revolutionary technology that introduced the world to blockchains and their unprecedented properties: a decentralised, censorship-resistant, and distributed ledger. While Bitcoin focused primarily on payments, its open-source codebase opened a Pandora's box for other technological experiments. These early experiments included special-purpose blockchains like Namecoin, Dogecoin, and Litecoin.
Then came Ethereum, a Turing-complete blockchain that allowed developers to use a common global ledger to create any application they envisioned. This spurred a flurry of innovation—from stablecoins to decentralised finance to games and intellectual property—that developed at an exponential rate. However, Ethereum soon started to suffer from the weight of its own success, with the influx of activity resulting in high fees and wait times.
General-purpose blockchains needed to scale. The solution emerged in two forms.
The first solution was to scale Ethereum itself through layer 2 solutions (L2s) or rollups. L2s aimed to handle transactions off the main blockchain while still leveraging its security by posting concatenated proofs on it. Even within L2s, there were multiple approaches; some, like Arbitrum and Optimism, used optimistic proofs, while others, like ZKSync and Starknet, used ZK proofs. Along the way, Ethereum itself officially adapted to a rollup-centric roadmap.
The second solution was to move away from Ethereum entirely and build for scale from scratch. This vision was embraced by teams like Solana, Near, and Cosmos, who created new blockchain architectures with distinct design choices and execution environments. Soon, other teams like Sui and Aptos also started building with a similar approach of owning their own stack.
Both Ethereum scaling solutions and alternative blockchains attracted hundreds of millions of dollars in capital and traded for billions on the open market. This wealth creation naturally drew even more builders, leading to the proliferation of even more blockchains. But these newer projects somehow needed to differentiate themselves.
Some did so through technology (a different variant of ZK proofs or a superior programming language), while others did so through specific use cases (decentralised storage or gaming).
Then a new trend emerged—applications with distribution building their own chains. One of the earlier instances of this was Axie Infinity, the top Web3 game on Ethereum, building Ronin2—their own blockchain. Coinbase, one of the biggest global exchanges, released Base, and Blur, the top Ethereum NFT marketplace, released Blast—both Ethereum L2s.
Major NFT projects like Pudgy Penguins, meme coins like Shiba Inu, and financial products like Ribbon have also taken this route. Recently, we've even seen the rise of L3s—chains that live on top of L2s.
These developments mean that crypto today has at least 300 live chains (as tracked by DefiLlama) and over 80 upcoming ones (as tracked by L2 beat). Neither source is comprehensive, so I suspect the actual number is much higher. Nevertheless, we have seen a Cambrian explosion of chains over the past two years, and there are multiple reasons to believe that this proliferation isn't slowing down any time soon. I list some of them below.
Financial Incentives.
The fat protocol thesis posits that 'the market cap of the protocol always grows faster than the combined value of the applications built on top.' So far, this has mostly held—the bulk of the value in crypto has accrued to the blockchain layer. This means that investors and the market value infrastructure layers higher than applications. Consequently, the financial incentives for both new and existing application builders are to create or move to a separate chain.
Sovereignty.
General-purpose chains require applications to share blockspace with other applications, and their users must pay gas fees in the blockchain's native token. This becomes problematic during periods of high demand, where a surge in activity in one application affects the rest. Additionally, if an application has its own token, its users must hold both that and the native token to pay for gas, leading to a worse user experience.
Moving to a separate blockchain allows sovereignty over both blockspace and token. Pudgy Penguins, one of the few crypto brands recognized by the masses (they've sold over a million toys), is building its own chain to 'vertically integrate from IP to base layer.'
Distribution.
Successful businesses are built on moats, and few moats are stronger than wide distribution. Projects are initially launched on a general-purpose blockchain to leverage its existing distribution. The ones that succeed build a sizable user base of their own. If this happens, they can accrue more value by transitioning to their own chain for other projects to leverage their distribution. The success of Axie Infinity spurred Sky Mavis to launch Ronin, which has evolved into a standalone gaming chain.
Infrastructure Availability.
The demand for builders to create chains has led to the commodification of chain infrastructure itself. Even a couple of years ago, building a blockchain required bootstrapping a validator base or having the technical skills to build an L2. Since then, the barriers have significantly reduced.
The combination of data availability solutions like Celestia, security solutions such as EigenLayer, open-source software development kits from Optimism, Arbitrum, and Polygon, and rollup-as-a-service platforms like Gelato has made the creation of a blockchain relatively simple.
Newer experiments.
Fundamental blockchain innovation is still ongoing. Teams continue to experiment with new designs. Monad is creating an Ethereum-Solana hybrid. MegaEth is experimenting with 'streaming transactions at lightning speed'. Additionally, chains like Solana and Bitcoin, which traditionally didn't support rollups, are now seeing teams building rollups on them.
In other words, all signs point towards our move to a world with thousands of chains.
The Fragmentation
The multi-chain world driven by financial, business, and technological incentives has fragmented the industry in several ways.
Liquidity Fragmentation.
Liquidity is the heartbeat of a healthy financial market. The more liquid a market, the easier it is to trade in. A high-liquidity DEX pair allows for better prices (reduced slippage) when making swaps. A high-liquidity lending pool facilitates safe, easy lending and borrowing.
Liquidity is a network effects game. High-liquidity pools are more attractive for investors and increase the utility of the tokens that make up the pool, leading to even higher liquidity. This is why liquidity pools in protocols like Uniswap and Aave follow power laws in which the top pools are orders of magnitude larger than the smaller ones.
When capital is fragmented across different chains, so are liquidity and its benefits. For example, the most efficient ETH–USDC swap pool might exist on Ethereum. However, you won't benefit from these lower prices if you want to make the same swap on Base.
State and Asset Fragmentation
One reason smart contract blockchains like Ethereum are game-changing technology is their composability. Developers can combine and interact with different protocols, apps, and assets seamlessly. This allows developers to build complex solutions without starting from scratch.
I maintain two Google Chrome profiles—one for personal matters and the other for professional ones. Oftentimes, I accidentally open YouTube in my work profile and am greeted by an unexpected set of recommendations, or I look for a work bookmark in my personal profile but then realise it doesn't exist there.
Each profile maintains its own history, extensions, saved passwords, connected accounts, and more. This is what state fragmentation looks like.
When working within the confines of a single chain, an aggregator can permissionlessly browse prices across many DEXs and provide users with the best execution. Or, a lending protocol can give a user a loan against a high-value NFT. USDY (Ondo's T-Bill backed stable) was previously just a yield-bearing stable that would sit idle in wallets.
But when a DeFi protocol such as Drift permissionlessly integrates it as collateral for trading perpetuals, the asset becomes even more attractive for users to hold.
Such composability breaks down across blockchains. A user cannot purchase an NFT on Ethereum with USDC on Base in a single transaction. Developers can't leverage the assets of one chain to provide users with products on another.
User and Social Fragmentation
Crypto is tribal in nature. Communities, driven by financial incentives, rally around and cheer projects to make them successful (and their holdings increase in value). This also leads to an 'us versus them' mentality, or maximalism. Bitcoin-maxis don't want anything to do with other blockchains. A Solana-maxi is likelier to try out Blinks on Solana than Time Dot Fun on Base.
The greater the number of chains, the more room there is for such maximalism. This leads to a fragmentation of users and culture.
These trends are problematic for developers. The truth is that no chain excels at everything. Each has its flaws and advantages. How, then, do they choose where to build? Factors like application-culture fit, programming language familiarity, financial grants, and technology advantages play a role. However, in choosing to build only on one chain, developers miss out on the user base of others. Users, on the other hand, don't get to experience the best application for their use case, irrespective of what chain it is on.
Broken UX
The fragmentations created by siloed blockchains are in no way a new problem but one the industry has been grappling with it for years. An analogy my colleague Saurabh likes to use is to think of these isolated blockchains as closed islands, each with its own citizens, culture, and assets. For there to be any movement across these islands, they need to be somehow bridged.
Crypto bridges function like real-world bridges, connecting different blockchains and allowing seamless movement of assets and data. When a user wants to transfer assets from chain A to chain B, a bridge, at its core, does the following:
It allows the user to deposit assets in chain A.
It asserts on chain B that the assets have been safely received in chain A.
It unlocks user assets in chain B.
Now, how a bridge goes about these steps, particularly the second one, can vary significantly depending on the mechanics of the bridge. A lot of ink has been spilled over bridge design (and its risks and security lapses), so I won't discuss them here. Besides, they are ancillary to the purpose of this post.
What we do need to know is that bridges exist, are one of the most funded sectors in crypto, have matured over time, and come in various forms. So what's all this chain abstraction fuss about? Aren't blockchains connected? Don't bridges solve fragmentation? Moreover, doesn't the user also have many options? That should be a good thing, right? Well, not quite.
Consider this scenario: Martin is new to crypto, and his favourite artist has just released new artwork as an NFT on Optimism for 0.1 ETH (~$300). Martin asks his crypto-native friend Joel to send him some funds. However, Joel only has USDC on Base. Because Martin is in a rush (it is a limited-edition mint), he asks Joel to send him the funds, and he'll figure out how to make the purchase. Martin might not be very familiar with crypto yet, but he is tech-savvy. How hard could it be?
Deceivingly hard, as it turns out. Here are the steps he will have to follow.
There are at least 10 steps and 28 separate clicks. And I'm being liberal here by assuming Martin already has a wallet set up, can use the same wallet for both chains and finds the information he's looking for (how to fund gas, the right bridge, the right DEX) in one go. This also does not count miscellaneous steps like signatures and transaction confirmations in the wallet. For an absolute beginner, this would be a nightmare. Buying an NFT on one chain using funds from another—one of the most basic user flows in crypto—should not be rocket science.
We live in a world with abundant options and a shortage of attention spans. Consumers lack the patience to wait even a few extra seconds longer than necessary. Web2 developers understand this. They obsess over reducing user complexity by minimising as many clicks as possible. Metrics, such as conversion rate and session durations, are measured with scientific precision.
Amazon had this realisation over 30 years ago and patented the '1-click checkout', a key breakthrough in their eCommerce dominance. The best companies pay designers millions of dollars to simplify their products.
While such thinking is largely absent in Web3 products today, it also reflects the nature of early-stage technologies. Ford's Model T, the first mass-produced car, was slower than a galloping horse. Early computers occupied entire buildings. For the longest time, they were text-based and didn't have graphic displays. The first 'mobile' phone weighed 2 kilograms. The Internet, too, as I noted earlier, was ridiculously slow and clunky to begin with (images, if any, loaded line by line).
In fact, when you think about it, it is remarkable that we have tens of millions of on-chain users who navigate these complex labyrinths to use crypto products. (It also illustrates, if it needed any illustration, just how powerful financial incentives are!)
But the tide is shifting. After years of investment in infrastructure, we now have sufficient blockspace. Next, we make crypto more accessible, user-friendly, and scalable for the masses. Slowly but steadily, projects, researchers, builders, and investors are coordinating to build better, slicker, more Web2-like experiences in Web3. Such a drastic change doesn't happen overnight. It's a gradual movement with many moving parts.
What is the end game? It is to bring the number of clicks Martin needs to mint his NFT to one. To get there, we start with simplifying bridging.
Crossing Chains
The process of finding a bridge, bridging assets, and swapping to the desired token on the destination chain is one of the most common user flows in crypto. But for a newcomer, it is also highly complex.
First, finding a bridge itself isn't easy. There are multiple options, including both native and third-party bridging solutions. Martin may find that while a particular bridge supports Optimism, it doesn't yet support the newer Base chain. Further, each bridge comes with trade-offs in speed, security, and fees. For a smaller transaction, a user might optimise for speed or fees. But if they're moving millions of dollars, they'd prioritise security.
Once you bridge an asset, you also have to swap it for your desired token. This further requires finding a DEX, paying gas fees, and conducting the swap. To add to a user's pain, certain bridges don't give users native tokens (like USDC) on the destination chain but an unofficial copy of the original (like USDC.e).
Socket started by aggregating existing bridges and DEXs into a single meta-bridge. The simple objective was to provide users with a list of options to go from asset X on chain A to asset Y on chain B based on their preferences of cost, latency, and security. They did this using a combination of on-chain smart contracts and an off-chain routing algorithm that dynamically selects the best bridge or route.
Socket spun this technology off into two products.
Socket API is for developers looking to give their users a cross-chain experience. It is used by platforms like Zapper and Zerion; wallets like Coinbase Wallet, Rabby, MetaMask, and Rainbow; and DeFi applications like Brahma.fi.
Polymarket, the predictions market consumer app that has exploded in popularity over the past year, also uses Socket API. While the app is built on Polygon and accepts deposits in USDC, users might have funds on other chains like Ethereum. Instead of asking users to bridge to Polygon from Ethereum separately, Socket API helps seamlessly integrate those steps.
Bungee is the consumer version of Socket's meta-bridge. It allows users to bridge and swap in a single interface without separately taking all the steps we discussed earlier.
For example, when Martin wants to swap 300 USDC on Base to ETH on Optimism, he inputs these parameters on Bungee. The protocol helps him find the optimal transaction bridge among four options. Based on his preference, he can complete the bridge-and-swap on Bungee itself.
This is what his flow to purchase an NFT now looks like. The number of clicks has gone down by almost half! It's still too complex, but we're making progress.
Bungee is also flexible. If a user is transferring $1 million USDC from Base to Optimism, they might not trust a third-party bridge with such a large amount and may want stronger security guarantees. In this case, they can use the native CCTP bridge from Circle (the USDC issuer).
The Bungee Exchange and Socket API have combined to serve a cross-chain swap volume of over $12 billion across the 16 (and growing) chains they support.
Other teams solving the cross-chain bridge and swap problem include Li.Fi and DeBridge.
Crypto-native users with gas tokens (like ETH) on another chain may consider bridging their tokens. However, bridging can be costly and slow, depending on the bridge used.
Socket offers an alternative with its service, 'Refuel'. Refuel uses indexers and liquidity pools to provide native tokens for gas on different chains. For example, a user with ETH on mainnet needing MATIC for Polygon deposits ETH into the Refuel contract. Centralised relayers confirm the transaction and fund the user's wallet with MATIC. Refuel only charges for destination gas fees, making it a cheaper and faster, although centralised, alternative to bridging tokens for gas.
But what about the absolute crypto novice unaware of gas fees?
The First Abstraction
Most popular crypto wallets (like MetaMask and Phantom) are externally owned accounts (EOAs). In simple terms, this means that a user's account exists outside of the state of the blockchain. EOAs are not ideal for crypto UX for a few reasons, including the following:
Users have to manage their own private keys. If their keys are lost or compromised, they risk losing access to all funds.
Users have to hold native tokens of a blockchain to pay for its gas fees.
Users can only sign one transaction at a time.
These limitations were finally addressed by a common standard: ERC-4337, more commonly known as account abstraction. We've written about account abstraction at length in a previous article, so I'll only touch upon the bits relevant to this story.
Account abstraction relies on the concept of smart contract accounts (SCAs). Instead of residing out of the blockchain's view, SCAs are accounts deployed as smart contracts on the blockchain. This means the user's interaction with their wallet is part of the chain's state. Instead of signing transactions, users sign messages known as 'opcodes', which are then processed by specialised players called 'bundlers'.
Among other things, account abstraction eases one major pain point for crypto UX: gas fees. New crypto users like Martin would find the concept of gas fees bizarre. It's like asking a user to sign up with a credit card before they can start using Facebook—unthinkable, really. Yet, each blockchain transaction does need gas fees. If not the user, can we get someone else to pay for it?
Account abstraction enables the sponsoring of gas fees on the user's behalf by introducing a new actor to the transaction supply chain—the paymaster. Paymasters, for a fee, either allow applications to sponsor gas fees on behalf of the user or allow the user to pay gas fees in a token of their choice.
For Martin, this means that he can pay for gas for his swap in USDC itself without having to procure ETH on Base separately. Similarly, the NFT application can now either sponsor gas fees on his behalf or allow him to pay for it in USDC on Optimism.
We're now down to 4 steps and 10 clicks!
Beyond Chains
Both cross-chain swaps and account abstraction meaningfully improved the crypto user experience. However, we're not at our one-click-mint endgame yet.
When bridging from one chain to another, even when using an aggregator like Bungee, a user must choose a source and a destination chain among many options. If there are only a few major chains like we had until a while ago, this is feasible. However, if the number of chains runs into the hundreds or thousands, the UX starts degrading. Further, once a user does bridge funds, they still have to switch between different chains in their wallet to use the funds.
The root of both these problems is that the user is being forced to think about their crypto experience as one spread across different chains. With their assets on one or more chains and the applications they want to interact with on another. Such thinking is inherently complex. Blockchains, after all, are just the underlying ledgers. When interacting with Web2 apps, users don't have to think about what servers or databases the developers have chosen to build on.
A world with an increasing number of chains is also problematic from a bridge scaling perspective. Recall that step two in how bridges operate was asserting on chain B that assets had been received on chain A. Depending on its design, a bridge does this by creating a messaging framework between chain A and chain B, deploying contracts so that each can understand these messages and then using relayers to pass messages from one to another.
This mechanism is problematic because these messaging systems must be deployed between each pair of chains separately. For example, if a bridge currently supports five chains and wants to add one more, it will have to deploy a messaging system between each of the five chains and the new chain. In other words, bridges scale quadratically—for n chains, there will be n-squared connections. Once you cross a certain threshold of chains, cross-chain scaling becomes infeasible.
The solution will now sound obvious: 'chain abstraction'. Users should interact with blockchain applications rather than the underlying chain where funds reside or the application is built. Martin should know of his NFT minting website, not of Base, Optimism or, for that matter, the bridge or bridge aggregator to get from one to another.
From a developer's perspective, they need a way to move beyond existing bridging solutions that don't scale. They need support from actors who can help them move funds from chain A to chain B, irrespective of whether a messaging system exists between them.
Chain abstraction is not a set process or product but an end goal with multiple paths (each with a set of tradeoffs) to reach it. What is common, however, between these implementations is the existence of 'intents' and 'solver networks'. These have become buzzwords surrounding the topic of chain abstraction. Let's understand what they mean.
Users perform on-chain activities to move from their current state to some desired end state. Martin, for example, wants to go from 300 USDC on Base to an NFT on Arbitrum. In the current state of crypto, we've left it up to the user to figure out the steps to get to that end state. This takes the form of them interacting with specific smart contracts that meet their exact demands.
This state of affairs is not always ideal for two reasons:
As we've seen repeatedly, steps to get to the end state can become extremely complicated, even for simple use cases.
Even if a user does find a path that helps them get to their end state, it may not always be the most optimal one.
Consider, for example, a user wanting to swap one million USDC on one chain for USDT on another. They could either directly use existing bridging and then swap solutions or interact with a protocol like Bungee to help them make their swap. However, it is also possible that there is an off-chain actor (maybe a market maker with deep liquidity on centralised exchanges) who is willing to service their swap for a lower fee than either of these solutions.
There is no way for the user to benefit from this, thus resulting in a market inefficiency.
Intents are a completely different way to think about crypto transactions. The premise is the same—a user wants to reach some end state. However, by using intents, instead of figuring out how to get to that end state, a set of sophisticated actors compete to help them reach there. Intents mean that all Martin has to do is express his desire to mint an NFT on Optimism and not spend more than 300 USDC on it, and these actors (also called solvers) help him achieve it.
Here's an analogy to help you understand intents better. Joel wants to get to Manhattan from Brooklyn. Fifteen years ago, he would've had to get on the street and wave at passing taxis to get them to stop. Some, already with passengers, wouldn't have stopped. Maybe no taxis are passing, and Joel needs to walk to a busier street in the rain. Once he gets into a taxi, he might have to help the driver with directions. This is what crypto looks like today—tens of steps amidst much uncertainty just to reach an end state.
Intents are like using Uber. Joel, while sitting comfortably at home, mentions his exact destination, browses through different options for getting there, gets a price quote and time estimate upfront, tracks the progress of his ride, gets into the vehicle once it arrives, and reaches his exact destination without any communication with the driver.
Uber provided a massive upgrade in experience and convenience over the status quo. Intents promise the same for on-chain transactions.
So, how do intents work? Here is a general framework for a simple cross-chain swap.
A user starts by expressing intent to reach an end state. In this case, say, it is spending 300 USDC on Base to get at least 0.1ETH on Optimism.
The intent protocol then holds an auction, called the Order Flow Auction (OFA), where solvers compete to fill this intent.
Based on the auction design (we'll discuss this in more detail soon), the protocol selects a solver and holds 300 USDC as escrow on Base.
The chosen solver uses its own liquidity to fulfil the user's order of 0.1ETH on Optimism by providing upfront capital.
Once fulfilled, the solver shares a proof with the protocol.
The protocol releases the escrowed funds and settles with the solver.
Because this is a general framework for intents, implementations for every step in this process can vary depending on the team or protocol building their solution.
The OFA, for example, can be designed in many ways depending on choices like the following:
Where is the order shared? An order can be posted in a public mempool visible to everyone, a private mempool enabled by technologies like TEE, or with only part of the intent details visible.
Who gets to be a solver? The solver list can be open for anyone to join, be gated to a certain selected set, or involve exclusive access where one solver is selected for a time period.
How is the winner selected? The winner of an auction can be determined based on different criteria like the fastest solving time, lowest fees for the user or maximum inclusion guarantees.
(You can read about the OFA auction design space in detail here.)
Similarly, the verification process, where the intent protocol verifies whether the solver has fulfilled the user order, can also be implemented in different ways:
Optimistic Verification. Once a solver claims to have fulfilled the order, there is a challenge period. If no one challenges the solver's claim within this period, they are free to claim the escrowed funds.
Messaging Systems. A message is passed from the destination chain to the source chain once the solver deposits funds. Existing messaging solutions provided by cross-chain protocols can be used for supported chains.
Light Clients. A light client is a simplified version of a full node that allows users to verify transactions without downloading the full ledger. A light client of the destination chain on the source chain can help verify a solver's fulfilment.
ZK Proofs. Zero-knowledge proofs (easy to verify and impossible to forge) are another way to prove the fulfilment of orders.
Even the settlement process, where the locked funds are released to the solver after verification, can have different mechanics. Some protocols only allow solvers to settle on the source chain, while others allow for more flexibility. Some settle individual transactions, while others settle them in batches.
A range of protocols are tinkering with these parameters to create their own intent solutions. These include the likes of Across, DLN, UniswapX, and Anoma. We even have dedicated solutions for specific layers of this stack. Everclear focuses only on making settlements as efficient as possible. Khalani Network helps solvers coordinate and collaborate to fill complex orders.
MOFA: Rethinking OFAs
The industry is excited about intents and OFAs as a solution to crypto's fragmentation and complex UX issues because this changes a user's role in the ecosystem. Users go from being left in the crypto wild to fend for themselves to a state where incentivised actors help them get to where they want.
Recall that developers building OFAs grapple with various design choices—the auction design, verification and settlement mechanism, allowed participants, and more—depending on their specific use cases. However, building an OFA from scratch can be very inefficient and resource-intensive for a variety of reasons.
First, once the developer decides on their solution design, they will have to deploy both on- and off-chain code for it. Given that these networks will handle high-value transactions, they need high-security guarantees. Developing such technology can be expensive, time-consuming, and risky. Furthermore, even minor changes in protocol design would require high incremental resources.
Second, to function, OFAs rely on solvers, which are specialised off-chain actors. It can be difficult and time-consuming for a new protocol to bootstrap a solver base. During the initial stages, a new protocol won't have much activity, so it won't be attractive to solvers without an incentive (this is the typical cold start problem). Also, because different intent networks would use different mechanics, solvers would have to create solutions for each separately, further increasing resistance.
Third, many applications may not need the services of dedicated solvers. Their needs could be served by the participation of existing actors in the transaction supply chain, such as validators, sequencers, block builders and proposers, bundlers, and paymasters. Further, they may not want to introduce a new message type in the form of intents, instead working with regular transactions or account abstraction opcodes.
The team at Socket have had a front-row view of this evolution. As early participants in the cross-chain space, they've seen the proliferation of chains and the emergence of intents and OFAs in real time. They believe that we are still in the very early stages of this paradigm (current solutions are limited to specific use cases like swaps), that the UX enabled by intents will be a key component in the mass adoption of crypto, and that there would a variety of intent networks serving different user needs.
Socket is no longer just a cross-chain aggregator and is now building the first chain abstraction protocol. Their goal is to transform a world with 10,000 rollups into a monolithic experience for users.
At the heart of this protocol lies MOFA, short for Modular Order Flow Auctions.
MOFA provides the tools for developers to create order flow auctions and implement their own design choices, all while remaining neutral. You can think of each design choice as a separate Lego block and MOFA as the solution that allows developers to mix and match the blocks to conjure the intent network of their choice.
By making it easy to create a flexible intent solution, MOFA significantly reduces the development and maintenance time and costs for a new protocol. Further, because all networks created with MOFA stem from the same building blocks, it becomes relatively easy for existing solvers to build solutions for and serve newer intent networks.
Thus, MOFA also helps protocols solve the cold start problem by providing an open marketplace for networks and solvers. (Think of this as similar to the role EigenLayer plays in blockchain security.3)
MOFA also rethinks the body of actors that comprise the solver set. In most existing intent network designs, solvers are specialised off-chain actors that function separately from on-chain actors like validators and sequencers. MOFA expands the solver set to include validators and sequencers as well, with this expanded body of actors called 'transmitters.'
To appreciate why this matters, we need to understand the concept of 'reorganisation (reorg) risk'. My colleague Saurabh explained reorgs in an earlier article.
For chains like Bitcoin, many miners compete to find a new block. At times, more than one miner may succeed. Assume two miners find new blocks (#1000A and #1000B) at the height of 1000. Due to propagation delays, some nodes will see block #1000A, and others will see block #1000B. Now, if a new block is found on top of block #1000B, the chain with block #1000B becomes the longest, and block #1000A is discarded or reorganised by the network.
Note that it is possible that a third block, #1000C, was found by another miner at the same height (1000), and the same miner or other miners building on this block found two more blocks (#1001 and #1002). In this case, both blocks #1000A and #1000B will be discarded, and #1000C will become part of the chain. Ethereum, too, faces reorgs, but the depth is rarely more than one block.
Recall that solvers commit to upfront capital to fulfil a user intent and get a settlement after a verification delay. Consider the scenario where a solver has just fulfilled an order on the destination chain but has yet to receive the user's escrow funds on the source chain. The risk here is that the source chain gets reorged to a point before when the user escrows their funds.
In such a case, the user would end up with funds on both the source chain (where the reorg returns the funds) and the destination chain (where the solver has already deposited funds), while the solver faces a loss.
Such a reorg is a massive risk for a solver to undertake. Reorgs, particularly among newer and untested chains, are quite common. The Degen chain, one of the first prominent L3s, recently experienced a reorg of over 500,000 blocks! As the number of newer chains grows, these risks only compound for solvers.
So how can reorg risks be eliminated (or at least reduced)? MOFA's solution is to directly allow for validators and sequencers to become solvers. Validators and sequencers are actors responsible for the block-building mechanism of a blockchain. Because they have maximum visibility into valid and invalid blocks and, by extension, the risk of a reorg, they are best positioned to take a reorg risk. An added advantage of having them as solvers is that they can directly include transactions in the block, making intent resolution faster.
Like Magic
Chain abstraction, in its purest sense, implies that the user is completely unaware of the existence of a blockchain. They could have funds scattered across multiple chains but are shown only a single balance. They shouldn't have to pay for native gas tokens across different blockchains. Finally, any cross-chain transaction, like Martin minting an NFT, should be as easy as a Web2 interaction—one click, instant results.
Socket recently rolled out a framework called MagicSpend++ (inspired by Coinbase's Magic Spend), which allows developers to use MOFA and account abstraction4 to create seamless user experiences. Here is how MagicSpend++ would work for Martin minting an NFT.
Martin uses a smart contract wallet that shows him a single chain-abstracted balance.
Martin clicks on 'mint NFT'.
The paymaster service checks Martin's smart wallet (across chains) for sufficient balance for the mint. Paymasters compete in an auction created using MOFA.
A userOP is created with the paymaster not only sponsoring gas but also funding the NFT purchase on the destination chain. (Thus, the paymaster acts as a solver.)
Once the userOP is completed and the NFT is delivered to Martin, the paymaster will be able to withdraw funds from the vault.
Martin can finally mint his NFT in one click!
Magic-Spend++, essentially a 'spend now, debit later' protocol, is designed to take advantage of the extensive account abstraction infrastructure already being rolled out to implement chain abstraction. This vision has attracted teams like ZeroDev, which are already prominent account abstraction service providers, to implement Magic-Spend++ in practice.
Magic-Spend++ represents a shift in perspective from chain-centric to account-centric. Such an approach, where wallet solutions adapt to make crypto UX smoother, is also being implemented by other teams in the ecosystem, such as Near Protocol, Particle Network, and OneBalance.
The AWS Moment for Blockchains
So far, the focus of our discussion on chain abstraction has been solving for the crypto user experience. However, that is only one side of the chain abstraction coin. On the other side lies an approach that can completely change how we think about scaling blockchain applications. Let me explain.
Today, developers deploy smart contracts for their applications on single blockchains. When Yuga Labs launched the Otherside collection on the Ethereum mainnet, it famously led to a massive congestion and gas hike. At that point (over two years ago), the multi-chain ecosystem was still in its infancy. Even if they chose to deploy on some other chain, there was no easy way for them to allow their users to move the NFT back to the mainnet if they wanted to do so.
However, in a chain-abstracted world, these restrictions no longer hold. Since there will be no distinction between chains, there will also be no concept of a user belonging to one chain but not another. Every user will belong to every single chain. Additionally, it has become much easier to move assets, both tokens and NFTs, across chains—thanks to existing cross-chain solutions and emerging intent solutions.
These developments mean that developers no longer need to make a definitive choice on what chain to deploy. There is a decoupling between the application and the underlying chain. Theoretically, applications can exist across multiple chains without the user knowing (since they don't know about the existence of chains at all).
This has massive implications. Consider how a developer interacts with a cloud service provider like AWS, which provides developers with on-demand computing capacity that scales or contracts horizontally depending on their requirements. AWS allocates more resources to the application when demand increases and reduces it when demand decreases. The developer doesn't care about what CPU or memory AWS is using as long as their requirements are served.
Chain abstraction now allows developers a similar scaling experience with blockchains. Freed from the technological and cultural shackles of a single chain, they can now expand and contract freely across different blockchains. Blockspace goes from being a scarce resource to an abundant commodity.
To understand how this would work in practice, consider the example of a common crypto event that often leads to chain congestion and fee hikes—airdrops. Traditionally, app developers deploy an airdrop contract to a single chain. Users interact with this chain via a transaction to claim their airdrop. As an increasing number of users rush to make a claim from a single contract on a single chain, the chain gets congested.
In a chain-abstracted world, the load of an airdrop would be balanced across multiple chains. A user wallet would sign a claim message (instead of a transaction) as an intent. Transmitters, rather than developers, would deploy the claim contract, starting with one chain. As the initial chain becomes congested, fulfilling user claim requests, transmitters would begin deploying the claim contract on other, less congested chains.
The decision to move to another chain can be triggered by a max-claim-fees parameter set by the developer. As soon as this fee is exceeded on one chain, transmitters can move to another. Thus, transmitters act as natural load balancers across different available blockspaces. If incentives allow, they can even deploy a rollup on demand to meet user requirements.
From the user's point of view, none of this would matter. Once their claim is complete, they only see the balance of the airdropped token, without any hint of what chain their token resides on.
While this vision of the future is still aspirational and possibly contingent on years of groundwork, its implications are massive. As blockchain becomes commoditised, apps will no longer show ‘alignment’ or a cultural bias towards one chain or ecosystem but will flow freely between many. If this happens, the fat protocol thesis we discussed earlier will no longer hold true. Instead, the application layer will start accruing more value, as is the case in Web2 today.
Such a change would require a rewiring of many core aspects of the crypto industry, not just value accrual. As the lucrative premiums placed on protocols decrease, investors will start allocating capital to applications. Most tribal communities, which currently exist around chains, may start moving their allegiances to products. MEV currently accrues mostly to validators; that equation might change as well.
Finally, and counterintuitive to the current thousand-chain landscape, we might see an eventual consolidation. With little to differentiate and reduced financial incentives, many chains might die, leaving a handful that will benefit from power laws and form the backbone of Web3 (much like a few hyper scalers and a long tail of specialised providers serve the web today).
Imagine a World
1 August, 2028.
You wake up to find your salary has been credited. Great! You make your monthly DCA investments and pay back a small loan you've taken. You then browse through X to catch up on the latest election news. There is yet another twist, of course. You quickly think about its implications and shuffle your election prediction bets. You get ready and leave for work.
On the way, you stop for a coffee and pay for it by tapping your phone. The barista informs you that you've accumulated enough points to also get a free snack. Cool! As you leave the coffee shop, you spot a billboard for the upcoming release of a new season for your favourite show. You scan a QR code to mint another digital collectable to add to your existing collection—one that gives you a chance to meet the cast.
After work, you meet a few friends over drinks to watch a football game together. As the banter heats up, you start placing bets on the result and goalscorers. Once the game is over, your friend settles the tab for both the bet you lost and the meal, and you send him your share.
Since you're a few drinks down, you book a cab back home. Once home, you put on the game you've been hooked on for the past month. Someone has made an offer to buy the sword you collected after a battle yesterday. Seems like a fair bid, and you have a stronger sword anyway. You sell it.
You're bored of the game after a while. You're also bored of the artwork in the digital photo frame on your wall. You want something new. You browse through an art marketplace and find something you like. You purchase it, and the artwork on your wall changes.
Finally, you complete your daily check-in with your AI therapist. Once you hang up, some of the credits you purchased are deducted.
As you lie in bed and reflect on your day, you realise the number of financial transactions you made. They all happened on the blockchain, many different ones, in fact. Yet, you never noticed. If you weren't familiar with crypto, you wouldn't even be thinking about this now. Your mind goes back to how complex things were just a few years ago.
You breathe a sigh of relief.
You silently thank chain abstraction.
Reading about networks,
Shlok Khemani
Bill Gates famously promoted the 'information superhighway' over the more open internet. He didn't think people wanted any of 'these weird URLs, HTTPS colon, slash, slash, www dot'. He never thought an average person would get any of this 'gobbledygook'.
Axie actually partnered with and built on Loom network after leaving Ethereum. But when Loom started to optimise for enterprise solutions instead of consumer applications, Sky Mavis ended the partnership and built their own chain.
There are strong parallels between restaking and MOFA. Restaking protocols act as a marketplace connecting blockchain services (rollups, bridges, anything else) looking for security and compute with operators that provide these resources. Similarly, MOFA aims to connect protocols and solvers.
We're seeing the continuing development of cross-chain smart contract wallet solutions. In its early implementations, smart contract accounts only existed on one chain at a time. That is now changing, and it's becoming possible for users to have the same smart contract account address across different chains and rollups.
Greetings Shlok,
Thank you for your deep dive into chain abstraction and the Order Flow Auction (OFA) mechanism. I love how you examine the breakdown and workflow friction that currently exists in the UX of engaging with blockchain ecosystems. We at RealityNet wholeheartedly agree with your assessment of the challenges plaguing our industry. I’d like your opinion on our cross-chain open order book system that facilitates order matching and trading.
RealityNet’s technical approach to achieving cross-chain interoperability implements advanced functional programming concepts to create a truly decentralized cross-chain open order book. We utilize a distributed interpreter built on functional reactive programming principles inherent in Scala, including:
- Monads, Monoids, Algebras, and Coalgebras for composable and type-safe consensus algorithms
- Functional Streams for efficient data processing across chains
- Partial Functions for flexible pattern matching in consensus stages
- First Class Objects for manipulating blockchain logic as data
These enable the following innovations:
1. Global Interpreter: Unlike traditional bridging solutions, we've created a "global interpreter" that can manage state dependencies across heterogeneous blockchain settlement layers. This is accomplished by encoding cross-chain state dependencies into a hypergraph topological structure, forming a "chimeral" state dependency graph between chains.
2. Composable Chain Abstraction: We use a Cell monad to encapsulate consensus logic, allowing for easy composition and extension of blockchain functionality through a Cell Monoid.. This approach allows different blockchains to be integrated more flexibly, enhancing interoperability.
3. Flexible Cross-Chain Communication: This system avoids the n-squared scaling problem typical of fixed messaging systems between chain pairs. By not relying on static connections, we maintain scalability as the number of chains increases, making it a more dynamic solution.
4. Dynamic Load Balancing: The system can automatically deploy claim contracts across multiple chains to balance load during high-demand events like airdrops.
5. Unified Developer Experience: Developers can create "first-class objects" out of computation using Arrows, allowing blockchain logic to be passed around and manipulated like data.
6. Advanced Type Safety: RealityNet’s use of recursion schemes and co/algebras provides compile-time checks for consensus stages, significantly reducing the risk of runtime errors. This ensures that developers can write more secure and reliable smart contracts.
7. Extensible Rule System: We implement a flexible system of Parlays and Rules that can easily incorporate external data or complex logic into the consensus process.
8. Novel Token Launch Mechanism: RealityNet’s approach allows new tokens to be listed with their own independent, decentralized directed acyclic graph blockchain, hosting an open order book where swap orders are matched within the mempool cache. The complexity of onboarding and managing validators is entirely abstracted away into a 2-click process where the miner simply decides which rApps to host on their device, where full nodes could be hosted on Android smartphones (iOS support forthcoming), Windows & MacOS laptops, and of course linux servers and VPS. This creates a competitive marketplace that eliminates the inefficiency and performance issues that traditional smart contract chains suffer from by enabling an opt-in approach to mining.
9. Execution Hashes: We've introduced a special type of dApp called an rApp (Reality dApp), which is built from a Turing-complete executable. Unlike traditional dApps that can only prove rudimentary state updates via non-Turing-complete smart contract opcodes, rApps operate by generating "Reality Checks". These Reality Checks implicitly generate a new type of proof called an execution hash, which creates a directed acyclic graph of hashes representing state updates of the actual program state. This can be iterated over and validated to prove the execution of the executable. Furthermore, Reality Checks can integrate with other proof systems like zk-SNARKs and rollups to create comprehensive state proofs for specific use cases.
We believe this system can compliment the OFA approach by enabling:
1. True Decentralization: By distributing the interpreter across the network, we avoid reliance on centralized solvers.
2. Improved Scalability: RealityNet’s architecture scales more efficiently as the network grows, avoiding the bottlenecks seen in traditional bridge-based models.
3. Enhanced Composability: The modular nature of RealityNet allows blockchain functionalities to be combined and extended easily, fostering innovation.
4. Better Transparency: The open order book provides more visibility into the market state.
5. Advanced State Proofs: The RealityCheck system allows for more comprehensive and flexible state proofs than traditional smart contract systems.
RealityNet’s open order book not only facilitates token swaps but can also be used to pay for dApps and rApps. This integration of executable proofs with the order book system creates a powerful platform for complex, cross-chain applications with verifiable execution.
While this approach introduces its own set of challenges, particularly in achieving the same level of user experience simplification as intent-based systems, we believe it offers a more flexible, scalable, and powerful foundation for cross-chain interoperability and advanced blockchain applications.
Do you see potential for these approaches to be complementary, perhaps with OFA-like systems operating within RealityNet’s more comprehensive framework? By networking diverse liquidity providers together we believe we can create a heterogeneous, cross-chain decentralized exchange.
Here is a link to our dev docs if you’re interested in reading more; https://docs.realitynet.xyz/
also, if you want to nerd out on our PoUW consensus algorithm, 2MEME, you can access the whitepaper from our main site: https://realitynet.xyz/2meme.pdf
The Best!
I hope all of this we will see around 2-3 year