Chain Abstraction and Universal Accounts

2026-08-12

Ask a crypto app to do almost anything and it asks you a question back: which chain? Chain abstraction is the name for a bundle of techniques whose whole purpose is to stop asking it. Next to it sits account abstraction, which solves a different problem, and the two get mixed up constantly. This article separates them, walks through the standards each one leans on, and shows how to check whether a given piece is a finished standard or a draft that can still change.

What chain abstraction actually means

Chain abstraction is a goal before it is a technology. The goal is that you say what you want, and the software works out which chain or chains the request touches, in what order, and with which fee token.

Compare that with what you do today. Your balance is split across several networks, each wanting its own token for fees. The same address string can exist on many chains and mean a different account on each. Moving value between them is a separate errand with its own risks. Every one of those is a point where you have to know something about chains before you can get anything done.

No single protocol delivers all of it. In practice chain abstraction is assembled from four parts: a way to name a chain and an account on it without ambiguity, a way to express the outcome you want instead of the steps, a way for someone else to cover fees, and a settlement layer that actually moves value between chains.

It follows that there is no one specification to point at and no body that owns the term. Some pieces are Ethereum proposals, some are cross-ecosystem proposals from the Chain Agnostic Standards Alliance, and some are one company's product. So when a service says it has solved chain abstraction, the useful question is which of the four parts it means.

Account abstraction and chain abstraction: the division of labour

Account abstraction answers two questions about a single account: who is allowed to authorise a transaction, and who pays for it. It turns the account from a bare keypair into something programmable.

On Ethereum two proposals carry that load, and both are marked Final in the Ethereum Improvement Proposals repository. ERC-4337 defines account abstraction using a separate mempool, so full smart accounts can exist without changing the base protocol. EIP-7702 adds a transaction type that lets an ordinary externally owned account point at contract code, and names the three features it was designed around: batching operations into one transaction, sponsorship, and privilege de-escalation, where a sub-key gets narrow permissions instead of full control. EIP-7702 went live on mainnet with the Pectra upgrade, which the Ethereum Foundation announced for May 2025.

Chain abstraction answers a question account abstraction never touches. Your funds and your state are scattered across chains, and a perfect smart account is still an account on one chain, with a balance there, paying fees in that chain's token.

Here is a test that separates them. If the question is who may sign and who pays, it is account abstraction. If the question is where this thing lives and how value gets from one chain to another, it is chain abstraction.

The two compose rather than compete, and the seam is visible in the specifications. ERC-4337 lists EIP-7702 among the proposals it requires. In the other direction, an EIP-7702 authorisation is signed over a chain identifier, and the specification accepts the current chain's identifier or zero, where zero means the authorisation is valid on every chain. That one field is a chain abstraction decision inside an account abstraction standard, and the proposal flags the cost itself: the same address may point at different code on a different chain.

What a universal account is, and what it is not

Universal account is product language, not a standard. No specification of that name has been published. What products mean by it is one identity and one screen, where balances held on many chains are added up and shown as a single number, and where an action you start is routed to whichever chains it needs.

The part underneath that is genuinely standardised is naming. CAIP-2, a Final specification from the Chain Agnostic Standards Alliance, defines a chain identifier as a namespace plus a reference, so Ethereum mainnet is the namespace eip155 with the reference 1, and a Bitcoin or Cosmos chain gets a name of the same shape. CAIP-10 builds on it and defines an account identifier as the chain identifier plus the address. With those two, an account is unambiguous across ecosystems rather than only inside one.

Work continues on formats better suited to contracts. ERC-7930, called Interoperable Addresses, defines a compact binary form that binds a chain reference and an address together. Its page carries the status Review, meaning it is being peer reviewed and is not settled.

What a universal account does not do is merge chains. Assets still sit on specific chains, transactions are still included in specific blocks, and the risks of each chain still apply to whatever you hold there. Aggregation is presentation plus routing: a real gain in usability, not a change in where your money lives.

Gas abstraction: paying fees with something you already hold

Gas abstraction is the narrow piece most people meet first. You arrive on a chain holding the asset you want to use and none of the token that chain charges fees in, so you can do nothing until you go and get some.

The fix is to let someone else pay and settle up separately. ERC-4337 builds this in as a paymaster, a helper contract that agrees to pay for the transaction instead of the sender, and lists paying fees in ERC-20 tokens and developers subsidising their users among the intended uses. EIP-7702 describes the same shape in its sponsorship feature. Wallet interfaces are catching up: CAIP-25, the method a site uses to open a session with a wallet, lists a paymaster service among the capabilities a wallet can advertise per chain, and that specification is at Review.

Two things are worth checking. Someone is paying, so ask what they get: a fee taken from the token you are spending, a subsidy from an app that wants your business, or a spread. And a sponsor you depend on can decline to serve you, a mild form of censorship that does not exist when you hold the fee token yourself.

Intents and solvers do the moving

The execution half of chain abstraction usually runs on intents. Instead of signing a sequence of steps, you sign a statement of the outcome you want, and a competing third party, usually called a solver or a filler, performs the steps and gets paid for it.

Standardising that is an active area rather than a settled one. ERC-7683, titled Cross Chain Intents, targets the interface between intent protocols and solvers, so a solver does not need bespoke code for every protocol. Its status is Draft, and it depends on ERC-7930, which is itself only at Review.

Draft is not a formality here, and this proposal shows why. Its own text describes an earlier draft that standardised a different part of the process, with order structures and settlement interfaces, and explains why that design was replaced. Anything you read about it that is more than a year old may describe a version that no longer exists.

None of this removes the settlement question. Value that appears on another chain got there through a mechanism that has to convince the destination the source event really happened, and that mechanism is where the trust sits. Chain abstraction hides the step from you; it does not delete it.

Chain abstraction and universal accounts: what account abstraction covers, what chain abstraction covers, and the standards under each

How to read the status of a standard before you trust it

Everything above rests on documents that are still moving, so the most useful habit is to read the status line before the content. Both processes print it at the top of the proposal, and the three labels you will meet here are Draft, Review and Final.

Draft means it is written down and can still change in any direction. Review means other implementers are examining it and the shape is mostly agreed. Final means the text is fixed. It does not mean everyone has adopted it; adoption is a separate question you answer with data, not with the status field.

Final is also not the same as live. ERC-4337 needs its infrastructure deployed on a chain before anything can use it, and EIP-7702 needed a network upgrade. So a claim that some chain supports some standard carries two checks, not one: is the specification final, and has this chain shipped it.

Where to look is not a secret. Anything numbered as an EIP or ERC has a page in the Ethereum Improvement Proposals repository, and anything numbered as a CAIP has one in the Chain Agnostic Improvement Proposals index. Both show the current status and a changelog, and both will be more current than any article about them, including this one.

The bottom line

Account abstraction decides who controls an account and who pays its fees, through standards such as ERC-4337 and EIP-7702, both Final and both live on Ethereum. Chain abstraction deals with funds and state spread across many chains, through chain-agnostic naming like CAIP-2 and CAIP-10, intent-based execution, and fee sponsorship that reaches across chains. A universal account is the product wrapper around those parts rather than a standard of its own, and it aggregates rather than merges, so your assets still live on particular chains. Because much of the plumbing is still at draft or review, treat the status line of each proposal as part of the fact and check it at the source.

Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of August 2026; refer to the latest official information.