Chain Abstraction Faces A Steep Hurdle

Chain abstraction promises to “unfuck Ethereum.” An antidote to the fragmented liquidity layer that has resulted from the horizontal scaling strategy. The proposition is to unify the UX and DX of Ethereum through an intent-based crosschain transaction infrastructure. It allows users to have one unified balance that can be instantly spent on any chain with one atomic interaction. For the developer, the promise is similar: One toolkit for integrating any chain, pushing all the complexity to the API provider and a network of solvers.

The dream state everyone imagines is a world where you, the user, have one wallet (think Metamask, but usable) that allows you to connect with any dapp on any chain and instantly transact. No configuration of the underlying network. No bridging of funds to the correct chain. No need to think about gas tokens.

However, one major hurdle prevents the ecosystem from realizing this dream state. When a user connects to a dapp, the standard flow is for the dapp to query an RPC, which returns a chain-dependent balance. As such, the dapp is blind to the true balance of the connected wallet and utterly ignorant of any chain abstracted systems that may be in place.

For this reason, most chain abstraction systems are geared toward serving embedded wallets and “superapps” that aggregate many protocols and chains (e.g., Instadapp and DeFiSaver-like experiences), or building a superapp (UniversalX by Particle Network).

Enter ERC-7811

ERC-7811 proposes a JSON-RPC method for wallets to share a user’s full asset list. The method supports filtering by chain, token type (ERC20, native, ERC721, etc.), and specific tokens (USDC, USDT, ETH, etc.).

The request takes as input an account parameters and optional filters. These filters allow apps to request only specific assets rather than the user’s entire portfolio. The response organizes assets by chain ID with each asset including its address, balance, type identifier, and optional metadata.

This does push complexity to the wallet provider. However, the standard is purposefully unopinionated about how the wallet formulates this crosschain data. Each chain abstraction system will likely provide a wallet service that acts as an intermediary backend service that maintains information about the user’s crosschain balance, factoring in asset balances and pending intents.

The high-level flow

The flow starts with an app requesting information about a user’s balance via wallet_getAssets. This gives the app a complete crosschain balance on supported networks, enabling it to present options based on the total available liquidity rather than just chain-specific balances.

The transaction proceeds normally if the user has sufficient assets on the target chain. However, suppose the required assets exist on a different chain. In that case, the chain abstraction system the wallet has integrated generates a path for sourcing the required assets and executing the desired transaction on the target chain. This crosschain interaction is perceived as one atomic interaction for the user.

Why this is a hurdle

If you were early on account abstraction — e.g., a Safe or Argent user before 2022 — you will remember that you couldn’t connect a smart wallet to OpenSea and a number of other major dapps. This is because most applications did not support the signature validation method for contracts (ERC-1271 and, more recently, ERC-6942 for un-deployed contracts).

The support of ERC-1271 was met with a chicken-and-egg problem. Smart wallets couldn’t connect to apps, so no one wanted to use a smart wallet as their daily driver. Apps couldn’t be bothered to support ERC-1271 because the addressable market for smart wallets was so small. Chicken-and-egg.

ERC-7811 will be met with the same chicken-ang-egg problem. Chain abstraction is most valuable to wallets if apps adopt a standard like ERC-7811, and integrating ERC-7811 only becomes appealing to apps once a critical mass of wallets have adopted chain abstraction.

Balances Services for Wallets

Supporting ERC-7811 is complex for wallets. They require a multi-chain indexer with knowledge of all the intents a user has inflight. These inflight intents are not recorded onchain and may not be created through the wallet’s UI, assuming the underlying account is self-custodial and portable.

All chain abstraction systems require a balance service with an API endpoint that reports the unified crosschain balance of a given user. For example, Omni Account, an intent-powered system to chain abstract any smart account and smart EOA, has the Orchestrator, a backend service that does accounting and sequences intents. The Orchestrator also has a balance database per Omni Account and an API endpoint for the wallet to read this balance.

Simplifying ERC-7811 for Apps

Apps need a standardised way to interface with smart account features. This is becoming increasingly important with the emergence of numerous smart account implementations that may not have the exact same interfaces and functions but support the same features. For example, each account implementation may have different gas abstraction or session key implementations, but the resulting product experience is the same.

This is no different for chain abstraction. How the wallet implements chain abstraction, or any other account abstraction feature, should not matter. An application only requires a common interface for these common features. ERC-5792 (Wallet Calls) provides this standardisation. The plan is for Wallet_getAssets to exist as a standardised method within this overarching framework for apps that wish to interface with and leverage smart account features, independent of the underlying implementation.

An alternative with ERC-7683

ERC-7683 (Auxiliary Funds Capability) provides the same function but is far more minimal and, perhaps, more elegant. Instead of returning the array of tokens and the balance, the ERC suggests returning a boolean that signals to the app that the user has auxiliary funds on another chain to pay for the transaction or does not.

Conclusion

Chain abstraction is a powerful upgrade to the wallet stack. However, its effectiveness for users and apps is stunted by the applications’ ability to discover assets and the wallets’ ability to surface the relevant information. ERC-7811 provides an antidote, but there needs to be an ecosystem-wide push to make this a reality. For this reason, we expect multi-chain applications with embedded wallets (with greater verticalised ownership of the UX) to be the trailblazers, along with up-and-coming wallets, when embedding chain abstracted features within their product.