The Ethereum Interoperability Layer (EIL) is a trust-minimised account-based interoperability protocol coordination protocol for Layer 2s built on Ethereum, proposed by Yoav Weiss and Marissa Posner on the Ethereum Chain Abstraction Team. The goal is simple: make Ethereum feel like one chain again - without relying on intermediaries who can grief, misappropriate or exploit user funds.

The EIL is a response to the fragmentation of logic, liquidity, and trust within Ethereum’s ecosystem – creating significant friction for onchain UX. The aim is to make moving around Ethereum a matter of opening your wallet, choosing an asset, address and hitting send. 

User actions all start with wallets, and wallets need to become first-class citizens to improve UX on Ethereum.

This essay examines how the EIL aims to unify Ethereum’s multi-chain ecosystem, the benefits it offers, and the challenges or limitations that remain.

Open, Choose, Send:

Weiss and Posner argue that wallets becoming first-class citizens is the sort of intuitive UX the Ethereum ecosystem must move to, but without compromising on a few values that are paramount to enabling optimal UX:

• Self-custody: users hold their assets and initiate transactions themselves.

• Censorship-resistance: no intermediary can block or delay your transaction.

• Privacy: you don’t have to reveal your IP address or intentions to a relayer or solver.

• Verifiability: any logic that matters can be checked onchain or in open-source wallet code.

This sounds ideal, but Weiss and Posner argue that today’s Ethereum experience still resembles a CEX-like model, dominated by bridge operators, relayers, solvers, and opaque off-chain infrastructure.

In crypto today, there are many chains and apps, but no standardised way for users to interact with them. Thus, EIL is built on the belief that execution and trust boundaries must be anchored in wallets, since wallets are where users ultimately authorize onchain actions, regardless of which application initiates them

If wallets are going to become the interface for ‘superapps’, they must support three capabilities without outsourcing trust to a third party:

• Transfer tokens: Alice has USDC on Arbitrum, Bob is on Base. She hits “Send” once, and tokens move from her wallet to Bob’s, without any knowledge of what chain she’s on.

• Mint tokens: Alice holds ETH on Arbitrum and Scroll. She wants to mint an NFT on Linea. She clicks once, and these balances are consolidated seamlessly across chains onto Linea to initiate the mint.

• Swap tokens: Alice wants to swap one token for another, but liquidity is better on another network she does not hold funds on. She clicks once, her wallet routes to the best liquidity source on another chain, and she gets her tokens on the chain she started on.

The EIL reframes the problem: blockchains shouldn’t merely move value — they should enable streamlined, user-centric experiences.

How the EIL Makes Wallets ‘Super’

Right now, frontends across the blockchain industry are converging around the idea of becoming crypto’s ‘superapp’, meaning that users can perform multiple functions like swapping, bridging, borrowing, lending, staking, and perhaps even perpetual trading – all on one platform. 

To date, solvers have been the key infrastructure engine enabling all crypto ‘superapp’ use cases, moving users from point A to point B as intended. The EIL is a response to the overreliance on contemporary ‘solvers’ who hold two key responsibilities:

• Fetching Routes: Solvers use algorithms to find the most optimal path from point A to point B, like planning a journey on a map – routes are typically optimised by the cheapest or fastest.

• Liquidity Provision: Solvers either hold inventory on-hand or use their routing algorithm to find the most optimal liquidity source to quote the user, this could be onchain (DEX liquidity in an AMM) or off-chain (private inventory, like a market maker) – the price quoted to the user typically shows the minimum quote that a solver can execute that transaction.

These solvers can be thought of much like drivers that can take you from point A to point B, but the final price determines the kind of ride you want:

• Fast: Will get you to your destination in the shortest amount of time, but may cost more as you might need to pay extra toll costs to use certain roads.

• Scenic: Will get you to your destination slower because the path avoids highways and toll roads, so the route will most likely go through slower, residential roads.

Instead of presenting the user with this choice, the action becomes more deterministic: ‘I want to get to the airport — take me there for $30. This matters because each time a user moves from app-to-app or chain-to-chain today, they need to choose which solver, bridge, or aggregator competes for their orderflow; deciding who to trust in an intent system is a defining step in the user journey today.

This is exactly the problem LI.FI addresses: it abstracts this decision-making by connecting users across chains and liquidity sources on their behalf. LI.FI Intents extend this by allowing users to specify only the outcome they want (e.g., “Give me token X on chain Y”), while LI.FI coordinates the computational logic, solver competition, and liquidity sourcing required to fulfil that intent.

Where the EIL proposes pushing this logic into wallets and enforcing trust-minimisation through protocol-level guarantees, LI.FI operates in the world that exists today. Fragmented liquidity, competing bridges, and incompatible execution environments still require an intermediary that can safely and efficiently coordinate them. LI.FI’s role, then, is to help users and developers handle this complexity until the broader ecosystem adopts new primitives (like UserOps, Paymasters, and XLPs) required for the EIL model to function at scale.

In other words: LI.FI is the app-layer glue for the multichain world we have, while the EIL is the trust-minimised coordination framework for the multichain world Ethereum wants to build with wallets.

The EIL Under the Hood

The EIL is account-based interoperability, where the user’s own account executes transactions on every chain – it is an alternative framework for cross-chain transactions, such as the OIF. To understand how the EIL restructures intent execution, it helps to examine the design constraints any cross-chain transaction framework faces.

The EIL assumes there are three choices a user has to make when completing a transaction – presenting a trilemma:

Onchain intents leak safety, offchain intents leak privacy, and split flows preserve both but ruin UX — meaning no existing system satisfies all three at once. The EIL attempts to solve this by introducing a few new components to minimise trust. To resolve the trilemma, EIL shifts the responsibility for constructing deterministic, privacy-preserving calls to the wallet layer with UserOps.

UserOps

A UserOp describes a transaction that a wallet wants executed on behalf of a user. Like intents, it expresses what the user wants. Unlike intents, it specifies how the transaction must be executed, removing solver discretion entirely.

Crosschain Liquidity Providers (XLPs): 

Register and deposit funds in CrossChainPaymaster on multiple chains. In addition, they lock a stake on L1 in L1CrossChainStakeManager. The unstake delay is 8 days - longer than the max L2 finality time. If an XLP starts the 8-day unstaking process, it immediately gets unregistered. XLPs provide vouchers for gas/liquidity without knowing the intent or what the funds are used for. It doesn't interact directly with users, nor transact on their behalf.

CrossChainPaymaster

An ERC-4337 paymaster contract that enables trustless crosschain gas payments and offers crosschain liquidity. Combined with a Multichain Account, it abstracts gas payments and liquidity, enabling users to send Multichain Transactions on chains where they hold no assets.

Voucher

A signed message that represents a claim for gas and/or liquidity for a specific account on a specific chain. Vouchers are redeemed via CrossChainPaymaster as part of a Multichain Transaction.

Together, these components form a pipeline where the wallet defines the exact crosschain calls, the XLP fronts liquidity, and the CrossChainPaymaster settles and verifies execution.

Source: EIL Flow, Yoav Weiss & Marissa Posner

In this system, wallets become the logic component responsible for building n amount of UserOps for the user’s desired transaction (no matter what chain, tokens, or actions the user wants to complete), and XLPs are offchain actors that use onchain CrossChainPaymaster contracts to provide liquidity. 

The EIL splits the role of the ‘solver’ in an ‘Intent System’ amongst the wallet, which constructs logic and the user controls, and XLPs – offchain actors who front liquidity on the destination chain and issue vouchers that allow the user to claim it.

The EIL’s components create a system where wallets define the exact calls, XLPs provide guaranteed liquidity, and the protocol ensures accountability. With this architecture in place, the EIL unlocks several meaningful improvements over today’s intent-based systems.

The Benefits:

By decentralising the role of the ‘solver’ in this way, the EIL improves on conventional intent systems by providing the framework for:

• Trust-minimised, Crosschain UX: Users today need to rely on solvers, bridges or relayers to handle and manage their funds crosschain. The EIL solves that by introducing XLPs who cannot steal user funds and can get slashed if they misbehave.

• Wallet-centric Architecture: The EIL shifts transaction construction into the wallet, reducing reliance on external execution environments controlled by apps or solvers.

• No Generic Crosschain Messaging: Crosschain messaging is hard to secure, slow to finalise, and hard to standardise. The EIL solves this by creating trust-minimised ‘checkpoints’ with the CrossChainPaymasters, vouchers, and slashing mechanism.

This framework makes wallets true first-class citizens by enabling them to handle user outcomes deterministically, without offloading trust to a third party. However, this comes with some trade-offs in economic game theory, as the entire model for how onchain value flows changes with the EIL.

The Drawbacks

If onchain trust assumptions are minimised in the way the EIL has described, there are still some trade-offs in performance:

• Liquidity Constraints: XLPs need to maintain sufficient liquidity to satisfy expected voucher issuance, though this liquidity is not locked or dedicated to the EIL. Solvers can also act as XLPs using their existing inventory without dedicating it to any single protocol. Since vouchers are user-verified, users can check an XLPs’ EOA to ensure sufficient liquidity exists before accepting a voucher. This means users are responsible for verifying counterparty liquidity before accepting vouchers. For institutions looking to initiate large orders or managing inventory during volatile markets, the system still relies on off-chain actors choosing to make liquidity available so liquidity on-demand remains a challenge.

• Market & Incentive Limitations: The stake required for XLPs is a fixed amount, not proportional to liquidity or voucher volume. It only needs to incentivize someone to call the dispute functions, so a stake as low as 1 ETH could suffice regardless of liquidity size. Capital efficiency for XLPs is on par with solvers, who also need liquidity available on the right chain to fill orders competitively. This means the EIL inherits the same market structure dynamics as solvers competing in intent protocols.

• Ecosystem Coordination Challenges: The EIL uses a singleton CrosschainPaymaster contract on each chain rather than individual XLP contracts. XLPs only need to keep sufficient funds for the next voucher or the maximum number of vouchers expected in a single block, with all other liquidity available for other purposes. The EIL shifts the logic burden into the wallet, which is already the user's fully trusted component, avoiding the need to trust additional intermediaries. This concentrates the security burden further around wallet providers.

Ethereum is a general execution environment, and many legitimate onchain interactions do not primarily involve tokens. The EIL extends this execution model across chains. That said, value transfer remains central to how most users, wallets, intermediaries, and apps engage with crypto today. It could therefore be argued that intent systems optimized specifically for value movement may have a competitive advantage, given that value is the greatest driver of the crypto industry and the object every actor wants and needs to be spent to drive activity on any blockchain.

Even though the EIL and OIF process value differently, they are not competing standards. Both standards operate at different layers of the stack and solve different problems. The EIL uses local (wallet-based) logic for transaction construction, while OIF relies on server-based logic operated by solvers.

The OIF excels at market-driven execution, where competitive solvers search for the best route, aggregate liquidity, and optimise for speed, cost, or settlement quality for apps. Intents are useful when the action is uncertain and the system must discover something. By comparison, the EIL focuses on trust-minimised coordination between chains: wallets construct all logic locally, XLPs cannot infer user intent, and execution does not rely on an off-chain solver interpreting what the user “meant.”

In practice, both models can coexist. OIF-style solvers can live on top of an EIL-enabled wallet, and act as XLPs – this provides more benefits for user-side logic and trust-minimised execution. The EIL provides a fallback path for users who want guarantees over optimisation. The result is an ecosystem where goal-oriented execution (OIF) and trust-minimised interoperability (EIL) reinforce one another rather than replace one another.

The EIL is best suited to use cases where the dApp knows the exact calls they want to execute. It extends Ethereum’s single-chain execution model across multiple chains.

Intents/OIF are essential for use cases where you have information asymmetry. For example when execution depends on offchain coordination or price discovery and an intermediary.

Conclusion

The EIL does not eliminate the complexity of a multichain world; instead, it reorganises it around the user, rather than intermediaries. By shifting routing logic onto wallets and replacing opaque solver networks with accountable, collateralised XLPs, it offers a path toward trust-minimised interoperability without relying on fragile cross-chain messaging or off-chain coordination. 

Yet, its adoption comes with real architectural trade-offs, particularly around the shifting role and responsibility of wallets themselves. Whether the EIL becomes a foundational layer of Ethereum’s future will depend on how well wallets, L2s, and liquidity providers embrace this model — and whether a user-centric approach to interoperability proves more resilient than the intent systems that came before it.

FAQ: What is the EIL?