What Is Chain Abstraction? How It Works, Approaches and Risks

TL;DR

• Chain abstraction simplifies cross-chain interactions, hiding manual bridging, network switching, and gas management.
• Four components enable it: accounts, intents, solvers, and messaging and settlement.
• There are multiple implementations. Universal accounts, MPC signing, intent-based execution, and messaging protocols address different parts of the process.
• Underlying risks remain, including solver concentration, verification assumptions, and smart contract vulnerabilities.
• Infrastructure reliability is essential. Validators, MPC operators, solvers, and relayers each have distinct security responsibilities.
• Teams should assess chain coverage, trust assumptions, operator independence, and recovery mechanisms before adoption.

What Is Chain Abstraction?

Imagine that a user holds USDC on one chain and wants to use the dApp on another. Before the application opens, the user has to bridge the USDC to the destination chain and then buy that chain’s gas token, spending extra time and money for the fees.

The user also needs to consciously switch the network in the wallet before the application will load. Chain abstraction hides those steps from the user’s experience, so the same transfer could take a single signature.

Chain abstraction is a user experience in which a person uses applications across multiple blockchains without manually:

• bridging assets,
• switching networks,
• acquiring each chain’s gas token.

Chain abstraction is a design goal reached by combining:

• accounts,
• intents,
• solvers,
• cross-chain messaging.

There is no single technical approach to chain abstraction. Different projects achieve this experience by combining different infrastructure components.

A typical manual flow looks like this:

1. Connect the wallet.
2. Approve the token.
3. Pick a bridge.
4. Wait for the transfer.
5. Switch networks.
6. Buy the destination gas token.
7. Execute the action.

With chain abstraction, these steps can be handled behind the scenes:

1. Sign one message.
2. Receive the result.

In the abstracted sequence, software acting on the user’s intent would handle every other step.

Why Does Chain Abstraction Exist?

As blockchain ecosystems expanded, users gained access to more applications, networks, and liquidity. But moving between these environments also introduced friction. Each chain brought its own gas token, wallet requirements, and liquidity pools. Using an application across networks could mean managing several assets, bridging funds, and switching networks just to complete one transaction.

Chain abstraction aims to make these interactions simpler by addressing four recurring challenges:

• Each chain charges transaction fees in its own gas token, requiring users to maintain separate balances.
• Chains can use different address formats and wallet standards. This is particularly relevant when moving between EVM-compatible networks and non-EVM chains such as Solana.
• Assets and liquidity are distributed across networks, so users may need to bridge funds before accessing a particular application or market.
• Applications deployed on a single chain may only serve users who already hold assets and operate within that network.

The scale of the ecosystem makes these challenges increasingly relevant. As of November 2026, there are 21 rollups, 3 validiums and optimiums, and 66 other L2s, with a total value secured of $36.12 billion.

Moving assets between these networks also introduces security considerations. Bridges have become attractive targets for attackers. In Q2 2026, bridge-related exploits, including the LayerZero OFT bridge exploit behind the KelpDAO hack, accounted for $351 million of the $755.3 million stolen across 83 hacks.

What Is State Fragmentation?

Every blockchain maintains its own record of activity, including account balances, transactions, and smart contract data. These records are not automatically available to other chains. As a result, applications and users often need additional infrastructure to access or reconcile information across networks. Blockchain interoperability protocols address this challenge by enabling chains to exchange data and communicate with one another.

How Does Chain Abstraction Work?

Chain abstraction brings together several infrastructure components to make interactions across blockchains feel like a single experience. Rather than requiring users to manage every network-specific step, protocols coordinate accounts, intents, solvers, and cross-chain messaging to handle those operations.

The four core execution components are:

• Accounts authorize transactions across networks.
• Intents express the outcome a user wants to achieve.
• Solvers find ways to fulfill those requests and provide the necessary assets.
• Cross-chain messaging carries information between networks, while verification and settlement confirm fulfillment and complete the transfer of assets between parties.

Other components support this process by simplifying gas payments, presenting balances across networks, and managing application permissions. They improve the user experience but do not independently execute cross-chain transfers.

The diagram above illustrates a typical flow. The exact sequence and settlement mechanism depend on the protocol.

The CAKE framework organizes chain abstraction differently, grouping its components into four layers and placing intents in the Permission layer.

CAKE, short for Chain Abstraction Key Elements, describes chain abstraction as an application layer on top of three infrastructure layers: Permission, Solver, and Settlement. Accounts and intents belong to the Permission layer because both define what the user authorizes, solvers handle execution in the Solver layer, and messaging and verification fall under the Settlement layer.

Accounts

Accounts provide the authorization needed to execute actions across networks. Depending on the architecture, a single user signature can authorize operations involving multiple chains.

On Ethereum, ERC-4337 smart accounts and EOAs upgraded through EIP-7702 support more flexible transaction authorization. EIP-7702 became available with the Pectra upgrade on May 7, 2025. Native account abstraction could eventually extend these capabilities to the protocol level.

Another approach uses multi-party computation (MPC). Instead of keeping a complete private key in one place, MPC distributes key shares among multiple parties, which collaborate to produce a valid signature.

Intents

Intents let users specify the result they want instead of manually defining every transaction needed to achieve it.

For example, a user might request at least a certain amount of a destination-chain asset by a specific deadline. The infrastructure then determines how to fulfill that request.

ERC-7683, a Draft standard as of November 2026, defines a common interface for solvers to access and process orders across different protocols. Individual protocols can still retain their own order formats, escrow mechanisms, and settlement designs.

Solvers

Solvers are market participants that compete to fulfill user intents. They identify a suitable execution route and may provide the required assets on the destination chain before receiving reimbursement.

Once fulfillment is verified, the solver receives repayment according to the protocol’s settlement rules. In return, it charges a fee for providing the service and committing its capital.

Competition can help reduce fees when multiple independent solvers have sufficient capital and are able to fulfill the same intent.

Messaging and Settlement

Once a solver completes the requested action, the protocol needs to establish that fulfillment actually occurred. This is where cross-chain messaging and verification come in.

Depending on the architecture, verification can rely on a messaging protocol, onchain proofs, or other verification mechanisms. These choices determine what the destination chain trusts when accepting a cross-chain message or confirming execution.

Settlement completes the economic side of the process. In escrow-first designs, the user’s source-chain assets are held in escrow and used to reimburse the solver after successful verification. The solver’s capital remains committed until repayment is complete.

Supporting Components: Gas Abstraction, Unified Balances, and Session Keys

Several additional components make chain abstraction easier to use, even though they do not perform the core cross-chain execution.

• Gas abstraction: Paymasters can sponsor transaction fees or allow users to pay them in tokens other than the chain’s native gas token, including stablecoins.
• Unified balances: Applications can present a consolidated view of assets held across multiple networks, reducing the need to check each chain separately.
• Session keys: These allow users to grant applications limited permissions for a defined period, reducing the need to approve every individual action.

An Example: A Cross-Chain Transaction

Consider a user who wants to exchange assets on one blockchain for assets on another. The following example illustrates how the components can work together. The exact execution and settlement sequence varies by protocol.

1. Accounts: The user authorizes the requested operation with a signature.
2. Intents: The signature communicates the desired outcome and its conditions.
3. Solvers: Solvers evaluate the request, compete to fulfill it, and one provides the required destination-chain assets.
4. Destination execution: The requested action is carried out on the destination chain.
5. Messaging and settlement: The protocol verifies fulfillment and, in escrow-first designs, releases the user’s source-chain funds to reimburse the solver.

How Is Chain Abstraction Different From Account Abstraction, Interoperability and Bridges?

These concepts address different parts of the cross-chain experience. Account abstraction changes how users authorize and pay for transactions. Interoperability enables blockchains to exchange messages and assets. Bridges provide one way to move assets between networks.

Chain abstraction brings these capabilities together to make applications across multiple blockchains easier to use. Instead of handling each operation separately, users can express what they want to achieve while the underlying infrastructure coordinates the execution.

Concept	What it addresses	Typical components or standards	What the user relies on
Account abstraction	How an account authorizes transactions, manages permissions, and pays gas	ERC-4337, EIP-7702, paymasters	Account implementation and wallet infrastructure
Chain abstraction	How users interact with applications across multiple chains	Intents (ERC-7683), solvers, unified balances	Solvers, settlement mechanisms, account providers
Interoperability	How blockchains exchange messages and assets	IBC, LayerZero, Wormhole, Axelar, Hyperlane, Chainlink CCIP	The protocol’s verification and security model
Bridge	How assets move between specific chains	Lock-and-mint, burn-and-mint, liquidity pools	Bridge contracts, validators, or liquidity providers

Bridges do not disappear in a chain-abstracted system. They can still provide the underlying infrastructure for moving assets between networks. The difference is that users may no longer need to choose a bridge, initiate a transfer, or monitor its progress themselves. Software interprets their intent and coordinates the necessary operations in the background.

What Are the Key Approaches and Components of Chain Abstraction?

Every chain-abstracted product needs the four components described above: accounts, intents, solvers, and messaging and settlement. The approaches below differ in where a protocol concentrates its abstraction, so they are not competing architectures.

Chain abstraction approaches operate at different points of the architecture, and products typically combine them. Each approach carries its own trust assumptions.

Account-Level Approach: Universal Accounts

Universal accounts, the approach behind Particle Network chain abstraction, give a user one address and balance across chains. OneBalance offers unified-balance tooling for apps.

In Particle Network’s default EIP-7702 mode, the user’s EOA acts as the universal account, which works with embedded wallets and server-side environments that support the authorization methods. Smart account mode serves JSON-RPC wallets that lack EIP-7702 support.

Signature-Level Approach: MPC Chain Signatures

Chain abstraction on NEAR starts at signing: a NEAR account can sign transactions for other chains through an MPC network. Chain Signatures let NEAR accounts and smart contracts sign for chains such as Bitcoin and Ethereum, and form one part of the NEAR stack alongside NEAR Intents and OmniBridge.

Threshold cryptography means no node can create a valid signature alone.

Intent-Level Approach: Solver Networks and ERC-7683

Users sign outcomes, and solvers compete to fill them. ERC-7683 lets solvers read orders from different protocols.

Across calls these participants relayers. They can fill intents in about two seconds using their own capital. Reimbursement happens later through settlement bundles, which are proposed approximately every 1.5 hours at minimum and then pass through a challenge period.

Comparison of Approaches and Components

Approach	Where abstraction happens	What the user trusts	Known limitation
Universal accounts (Particle Network, OneBalance)	Account	The account provider and its liquidity routing	Chain coverage is EVM chains and Solana as of November 2026, and the list changes
MPC chain signatures (NEAR Chain Signatures)	Signing	The MPC node set	Depends on the liveness of the signing network
Intents and solvers (Across, ERC-7683)	Execution	Solvers and the settlement contract	Relayers commit capital until settlement is finalized. Across uses periodic settlement bundles followed by a challenge period.
Messaging protocols (Chainlink CCIP, Hyperlane, LayerZero)	Transport	The verification model	Needs an application on top to hide chains

Where Does Chain Abstraction Stand in 2026?

As of November 2026, the term has cooled since 2024 while products shipped. Most major exchange wallets route assets across networks inside one interface.

EIP-7702 has been live since the Pectra upgrade on May 7, 2025. EIP-8141, which brings native account abstraction to Ethereum, moved from Considered for Inclusion to Scheduled for Inclusion for Hegotá on August 27, 2026.

That status commits client teams to shipping native account abstraction in Hegotá, without fixing the final specification, and Hegotá is planned for 2027. EIP-8141 remains a Draft, so its details may change before Hegotá.

What Are the Risks and Trust Assumptions of Chain Abstraction?

Chain abstraction can relocate risk to the solver network and the verification method, where the user may no longer see it.

1. Solver concentration and censorship: Dominant solvers can refuse or reorder intents when the solver network is centralized. Check the number of independent solvers that fill orders and whether any solver can be excluded.
2. Hidden bridge and verification risk: The $293 million KelpDAO exploit involved a LayerZero-powered rsETH bridge configured with a single verifier. Attackers compromised the RPC infrastructure used by the verifier, enabling it to attest to a forged cross-chain message. Check the number of independent verifiers that attest to delivery and who operates them.
3. Soft finality: A solver may pay out before the source chain finalizes, which requires deep liquidity and risk management. Check the finality assumptions the solver uses before paying out and the size of its inventory.
4. Smart contract surface: Each supported chain adds a settlement contract that might contain a bug. Check the audit reports for each settlement contract and the number of chains it is deployed on.
5. Centralized components: Paymasters and shared sequencers can concentrate control with one operator, and a proprietary solver network does the same. Check who operates each component and whether an alternative operator exists.
6. Stuck or partially executed transactions: The user may not be able to see where funds are during a cross-chain transfer, so status tracking and a documented recovery path become necessary. Check whether the product documents a recovery path and shows transfer status.

What Does Chain Abstraction Demand From Validators and Infrastructure Operators?

Validator performance on the source chain affects the finality risk a solver carries between fill and settlement. A solver fronts assets on the destination chain against a source-chain deposit, and it can rely on that deposit only once the source chain finalizes it.

Validator operators contribute to the reliability of the underlying networks, even when they do not operate the abstraction components themselves.

Finality and Uptime Dependence

Payout time for each solver depends on the protocol’s verification design and finality assumptions.

On Across, relayers bear chain-reorganization risk until a settlement bundle repays them.

Supporting Infrastructure Beyond Validators

Each infrastructure role has its own responsibility and security model:

• Validators: secure the source chain and determine when its transactions are final.
• MPC operators: hold key shares and cooperate to sign transactions for other chains.
• Relayers and solvers: front capital on the destination chain and carry finality and settlement risk until reimbursed.
• Verification networks: attest to cross-chain messages, and their configuration sets the trust model of the transfer.

The NEAR MPC network is operated by independent operators, and adding or removing an operator requires an on-chain vote by the existing operators.

Monitoring and Recovery

Signals an operator can observe include relayer lag and unsettled intents. Relayer lag is the delay between a user signing an intent and a relayer filling it, and rising lag can indicate thin solver liquidity or congestion on one of the chains.

Unsettled intents are fills that have not yet been verified and repaid. A growing backlog can point to a stalled messaging layer or a source chain that has not reached finality, and it shows where solver capital and user funds are held up.

Key Handling

The NEAR MPC network holds the signing key as shares across independent operators, and a signature is valid only when a threshold of them cooperate.

Everstake has operated a node in the NEAR MPC network behind Chain Signatures since September 2025, alongside other independent operators. The participant set and signing threshold are published on-chain, so anyone can verify which operators hold key shares.

As a participant, Everstake holds one key share and contributes to a signature only when a threshold of operators cooperates. No operator, Everstake included, can sign alone, and adding or removing an operator requires an on-chain vote by the existing operators.

On May 15, 2026, a newly churned malicious node operator used a flaw in the GG20 threshold signature scheme to reconstruct a full vault key and drain about $10.7M from one of five THORChain vaults. A single node recovered the key without cooperation from other operators, and systems that use the same scheme could share the exposure.

Everstake Validator Infrastructure

Every chain-abstracted transfer depends on a source-chain transaction being included and eventually finalized. Validators help secure that process, while some protocols allow destination-side execution before source-chain finality.

Everstake has operated validators since 2018, always on a non-custodial basis, so your assets stay under your control.

To keep your validators online through outages, Everstake builds its infrastructure around:

• multiple geographic regions and infrastructure providers,
• redundant connectivity to multiple beacon nodes,
• signers deployed independently of validator clients, in isolated environments.

If one provider, region, or network path goes down, the rest of the setup is designed to keep your validators signing.

Withdrawals stay in your hands too. On Ethereum, B2B and institutional customers set their own withdrawal credentials, typically an EOA or a Safe multisig.

Validators and MPC networks each play their own part in a transfer. Validator signers attest to and propose blocks on the source chain, while MPC networks sign transactions for other chains.

The setup is described in how crypto validators work.

What Should Teams Evaluate Before Adopting Chain Abstraction?

Teams should evaluate five points before they route user funds through a chain-abstracted product:

1. The components the user trusts, from solvers and MPC nodes to paymasters and settlement contracts.
2. The finality assumptions used before a solver pays out.
3. A documented recovery path for stuck or partially executed transactions.
4. Coverage of the chains the team needs, including non-EVM chains, with a date.
5. Support for the standards in use, ERC-7683 and EIP-7702.

Teams evaluating validator or wallet infrastructure can review our solutions or contact Everstake.

FAQs

What is chain abstraction?

A user experience that lets people use applications on multiple blockchains without:

• bridging assets,
• switching networks,
• holding each chain’s gas token.

Is chain abstraction the same as account abstraction?

No, account abstraction upgrades what one account can do on a chain, while chain abstraction coordinates the experience across chains.

Does chain abstraction require account abstraction?

Not necessarily, because products reach single-signature authorization through different mechanisms, such as:

• ERC-4337 smart accounts,
• EIP-7702 upgraded EOAs,
• MPC-based signing.

Does chain abstraction remove bridges?

No, bridges and messaging protocols remain in the stack, and software acting on the user’s intent operates them.

What is an intent in crypto?

A signed message stating the outcome a user wants, such as a destination asset and a minimum amount, which solvers would then execute.

What is the difference between an intent and a transaction?

A transaction specifies the exact steps to execute, while an intent states the outcome the user wants and leaves execution to solvers.

What is a solver?

A market participant that:

• competes to fulfill an intent,
• fronts the asset on the destination chain,
• is reimbursed after verification.

Who pays gas in a chain-abstracted transaction?

Depending on the product, the user pays fees in any supported token through a paymaster, or the application sponsors the fees.

Is chain abstraction safe?

Safety depends on each product’s solver network and verification method, so its trust assumptions should be reviewed before large transfers.

Which blockchains support chain abstraction?

Coverage varies by product: as of November 2026, Particle Network supports EVM chains and Solana, and NEAR Chain Signatures can sign for Bitcoin and Ethereum.