Cross-L2 interoperability — synchronous calls, EIL, atomic execution

1. TL;DR

Ethereum’s rollups scaled execution but fragmented the user experience into dozens of separate chains, each with its own gas token, bridge, and finality timeline, so research asks how to make moving and composing across L2s feel instantaneous and trust-minimized without a centralized intermediary. Three answers are live in research today: the Ethereum Interop Layer (EIL) puts the user’s own wallet in control of every leg of a multi-chain action, funded by liquidity providers fronting gas and assets through atomic-swap vouchers; realtime-proving synchronous composability lets a contract on one chain directly CALL a contract on another inside one atomic transaction, verified by a single validity proof; and shared-sequencer atomic-execution designs coordinate multiple rollups’ block production so a bundle of cross-rollup transactions either all land or all revert. None has shipped in production as of 2026-08 — the frontier of “one chain, many execution environments.”

2. Explain it simply

Analogy

Doing something that spans two rollups is like needing a passport stamp and a currency exchange at every land border you cross — you get through eventually, but spend the trip managing logistics. The proposals here remove that friction three ways: EIL is a universal travel card that handles currency and paperwork at each border the instant you swipe it, with no local agent involved. Synchronous composability is two shops in different countries sharing one till receipt for a single purchase drawing from both shelves at once. Shared-sequencer atomic execution is a tour operator who won’t let the bus leave any city until every passenger has boarded everywhere — if one city’s crowd doesn’t show, the whole schedule is redone.

ELI5

A rollup is a smaller blockchain that leans on Ethereum for security, but each one is its own separate world with its own local money for fees. Doing something that touches two rollups at once — like sending a friend money on one and using it on another — usually means trusting a company in the middle to make both halves happen. These ideas try to remove that company: one lets your wallet handle every step directly, borrowing gas money from helpers who get paid back automatically; another lets a program on one rollup call a program on a different rollup and get an answer back instantly; a third has the rollups agree ahead of time to only accept a group of actions if every rollup says yes.

Step-by-step walkthrough

Scenario: Arbitrum Alice wants to send 100 USDC to Base Bob, using the Ethereum Interop Layer’s (EIL) CrossChainPaymaster design, with Xander as a registered cross-chain liquidity provider (XLP) active on both Arbitrum and Base.

1. Before (state: Alice has 100 USDC on Arbitrum, 0 on Base; Xander has funds deposited in the CrossChainPaymaster on both chains, plus an L1 stake). Alice pastes Bob’s Base address into her wallet and enters 100 USDC — her wallet handles the rest.
2. Request. Alice’s wallet signs a multichain UserOp: on Arbitrum, it locks 100 USDC and requests a matching Base voucher, listing Xander (and other acceptable XLPs) plus a reverse-Dutch-auction fee schedule.
3. Voucher race. Because the request and a matching claim can be bundled in the same block, Xander (also a bundler) claims Alice’s Arbitrum funds with a signed voucher, valid to release Xander’s Base funds to Alice too.
4. Fulfillment. Alice appends Xander’s voucher to her Base UserOp; Base’s CrossChainPaymaster verifies it, confirms sufficient deposited funds, and credits Alice.
5. After (state: Alice has ~100 USDC on Base within one block; Xander’s Arbitrum funds stay locked one hour as a dispute window). If the voucher had been insolvent, another XLP could dispute it, freezing funds until L1 resolves it — but Alice already has her funds, since the swap was atomic at redemption.

Common misconceptions

• Myth: These proposals are cross-chain messaging protocols. Reality: EIL is not one — it uses the canonical bridge only when a dispute needs L1 arbitration; normal flows involve no message passing, only the user directly transacting on each chain (ethresear.ch/t/23437, 2025-11).
• Myth: Synchronous composability requires an Ethereum hard fork. Reality: The realtime-proving design is built entirely from proxy contracts and existing standards (EIP-4337, EIP-7702), with no L1 protocol change required (ethresear.ch/t/23998, 2026-02).
• Myth: “Atomic execution between rollups” means rollups literally share a virtual machine. Reality: Atomicity comes from a trustless sequencing/proving protocol coordinating independent rollups’ block construction — each still executes and proves its own state transition independently.
• Myth: Faster interop always means weaker trust. Reality: EIL’s fast path accepts real reorg-griefing risk on the source chain that a slower, messaging-based design (its own proposed future CrosschainMessagingPaymaster) would avoid.
• Myth: These designs replace intent solvers. Reality: EIL is an alternative to intents for a user directly transacting across chains; for an offchain counterparty or complex solver logic, intents (see /cross-chain/intent-solvers/) remain the better fit.

If you only remember one thing

Cross-L2 interop research converges on removing the “mid-state” where a third party finishes your cross-chain action for you — by having the user execute every leg themselves (EIL), proving every leg in one shot (synchronous composability), or making every rollup’s block conditional on every other’s (shared-sequencer atomicity).

3. How it works

EIL: account-based interop via atomic-swap vouchers

The Ethereum Interop Layer targets a trilemma: a cross-chain protocol relying on any third party can choose only two of privacy, safety, and UX (ethresear.ch/t/23437, 2025-11) — on-chain intents give privacy and UX but expose the transaction to front-running; reputable off-chain solvers give safety and UX but leak the user’s IP and intent; splitting the flow into separate transactions gives privacy and safety but degrades UX. EIL’s answer removes the third party entirely: the user’s own ERC-4337 account performs every call on every chain, using a Merkle root signed once over multiple per-chain UserOps (one signature authorizes N chain-specific operations, accommodating hardware wallets that can’t co-sign many messages). Token transfers go through a CrossChainPaymaster, a permissionless hub where XLPs (Crosschain Liquidity Providers) deposit funds on multiple chains, backed by an L1 stake with an 8-day unstaking delay (longer than the longest L2 finality window). A transfer is an atomic swap: the user locks funds and requests a voucher; the first XLP to provide a signed voucher claims the locked funds (after a 1-hour dispute window) and the same voucher releases the XLP’s funds to the user downstream. Fee discovery uses a reverse Dutch auction — the fee rises each second until an XLP accepts.

Synchronous composability via realtime proving

A separate line asks whether a contract on one chain can call a contract on another and get a result back within the same transaction. The realtime-proving proposal builds this on based rollups (see /mev/based-rollups-and-preconfs/) where the block proposer is also the prover, submitting data availability and a validity proof as one atomic unit — collapsing the usual gap between “posted” and “proven.” The mechanism is a proxy smart contract on L1 representing a contract that lives on a rollup. When an L1 contract calls the proxy, the call resolves against an execution table — entries recording which rollups are affected, their state-root transitions, and the next action — accompanied by a single validity proof covering every step. The proxy applies the recorded changes and returns the result, indistinguishable from a same-chain call; reverts propagate via REVERT/REVERT_CONTINUE actions unwinding nested calls exactly as a same-chain revert would. It requires no L1 fork and is orthogonal to preconfirmations, but inherits a prover-centralization concern: only whoever builds the block can construct the execution table, since only they know the exact pre-state (ethresear.ch/t/23998, 2026-02).

Atomic execution via a shared sequencer

A third framing, closer to a flash loan’s atomicity guarantee, asks how to make a bundle of transactions spanning multiple rollups either all succeed or all fail, without the rollups trusting each other’s operators. The proposal separates each rollup’s sequencer (order) from its executor (execution), sharing one sequencer across rollups. Atomicity has three phases: Proposal Block Sequencing — users encrypt transactions under a timelock puzzle, the sequencer preconfirms order while still encrypted (can’t censor on content), then decrypts and sequences — guaranteeing “Atomic Inclusion”; State Execution — each executor runs its proposal block and proves validity, deciding whether to revert; Finalized Block Sequencing — a corrected block excludes transactions whose counterpart failed elsewhere, guaranteeing “Atomic Execution” while inheriting censorship resistance (0xTariz, ethresear.ch/t/18776, 2024-02). Committing to an order before seeing contents is what prevents the sequencer from becoming the trusted intermediary being removed.

Formalizing the trust reduction

Let $T_{\text{fast}}$ be time via a trusted intermediary and $T_{\text{trustless}}$ time via a canonical bridge (bounded by the slower chain’s finality, e.g. ~7 days for optimistic rollups). Each design targets $T_{\text{trustless}} \to T_{\text{fast}}$ without a trusted intermediary in the common case: EIL’s normal-path latency is one source block plus one destination block (~2s combined), falling back to an 8-day dispute only if an XLP misbehaves; realtime-proving latency is bounded by full-block proving time (~7 seconds on 12 GPUs, as of the post’s writing); the shared-sequencer design’s latency is bounded by State Execution time, treated as dominant but not quantified.

4. Worked numeric example

Continuing Alice and Xander’s EIL transfer from §2, with a reverse-Dutch-auction fee starting at a market rate of 0.05% and rising by 0.01 percentage points per second if unfilled, capped at 0.5%:

Time after request	Fee offered	Outcome
T+0 (same block as request, if bundled by an XLP-bundler)	0.05% (5 cents on $100)	Filled immediately — Xander bundles his voucher with Alice’s request UserOp
T+1s (if unfilled)	0.06%	Any listed XLP may now claim the higher fee
T+5s (if still unfilled)	0.10%	Fee continues climbing
T+45s	0.50% (cap reached)	Request expires if still unclaimed; Alice’s locked funds are released back to her

In the common case — an XLP that also runs a bundler sees Alice’s request and its own voucher-claim UserOp land in the very same block — Alice pays close to the starting 0.05% and receives her 100 USDC-equivalent on Base within roughly one Arbitrum block plus one Base block, without ever having bridged in the traditional sense: no message crossed from Arbitrum to Base, only two independent, atomically-linked transactions that Alice herself authorized with one signature.

5. Where it’s used

Ethereum

• EIL (Ethereum Interop Layer) — proposed ERC-4337-based account interop standard with a CrossChainPaymaster liquidity layer; not yet shipped as of the thread’s latest replies (2025-11 to 2025-12). ethresear.ch/t/23437
• Synchronous composability via realtime proving — proposed by jbaylina with a public reference implementation (sync-rollups) and an independent PoC by Martin Köppelmann (synchronous_surge); research-stage. ethresear.ch/t/23998
• Atomic execution via shared sequencer — proposed by the Radius team, building on their earlier Practical Verifiable Delay Encryption (PVDE) work and Curie testnet for trustless/encrypted-mempool sequencing. ethresear.ch/t/18776
• Based rollups (Taiko) and shared-sequencer research generally — the underlying “one sequencer serving several rollups” substrate these atomicity proposals build on; see /mev/based-rollups-and-preconfs/ for the base layer these ideas extend.

Solana

• n/a — no Solana-specific cross-L2 interop research in sources. Solana lacks an equivalent rollup-fragmentation problem (a single execution environment, not dozens of rollups), so none of EIL, synchronous composability, or shared-sequencer atomicity appears in Solana-side material. Its analogous cross-domain problem — bridging to Ethereum’s rollup ecosystem — is addressed by /cross-chain/bridge-designs/ and /cross-chain/intent-solvers/.

6. Risks, attacks, and incidents

• Reorg griefing in EIL’s voucher flow. A source-chain reorg after an XLP has issued a voucher could, in principle, let the XLP resubmit the original transaction to reclaim payment — but a reply notes a user able to predict reorgs at will “can probably do worse than stealing a voucher,” since that capability profits far more from ordinary MEV (ethresear.ch/t/23437, reply, 2025-11).
• Prover/builder centralization in synchronous composability. Only the block builder knows the exact L1 pre-state, so only the builder can construct a valid execution table — a reply warns this risks becoming “another private channel to the builder duopoly,” since commit-reveal can’t help when constructor and secret-keeper are the same party (ethresear.ch/t/23998, reply, 2026-02).
• Complexity and DoS surface in multi-hop EIL flows. A user chaining many hops bears the gas cost of their own large Merkle proofs; “users can only DoS themselves” under the fee design, assuming fee-sizing correctly accounts for destination gas.
• No production incidents yet. All three designs are pre-production research; no live exploit has occurred at the scale a lock-mint bridge (see /cross-chain/bridge-hacks/) has.
• Institutional-scale transfers are explicitly out of scope. EIL’s author states neither EIL nor comparable intents are designed to move very large sums (example: $100M) in one voucher, since reorg risk becomes disproportionate — large transfers should use the canonical bridge (ethresear.ch/t/23437, reply, 2025-11).

7. Open problems

• Path from builder-constructed to user-constructed execution tables. Decentralizing table construction away from the builder “requires proving infrastructure to be widely available,” and “proof delegation protocols” letting users outsource proving without revealing intent might be the missing primitive (ethresear.ch/t/23998, reply, 2026-02).
• L1 keystore dependency in EIL. Multichain validation assumes the same key signs across every chain; the long-term fix requires an L1 keystore and L2 support for L1SLOAD, an external dependency outside EIL’s control.
• Standardizing the multichain signature format. EIL’s Merkle-root-over-UserOps scheme needs a shared ERC so accounts with different implementations (ECDSA, passkey, social recovery) validate a common format — described as forthcoming, not finalized.
• Whether atomic-execution bundle failures cascade. Excluding a failed transaction from a Finalized Block can cause “a cascading failure of subsequent transactions” on the unaffected rollup; the proposal says this resolves “with just one additional communication” round in the common case, without formally analyzing worse cascades.

8. Ethereum vs Solana

Aspect	Ethereum	Solana
Underlying problem	Dozens of independent rollups with separate gas, bridges, finality	Single execution environment; no rollup-fragmentation problem in these sources
Account-based interop (EIL)	Active proposal, ERC-4337-based, no production deployment found	n/a — no equivalent proposal in sources
Synchronous cross-chain calls	Realtime-proving proxy-contract design, research-stage	n/a in sources
Shared-sequencer atomic execution	Proposed via encrypted mempool + timelock puzzles (Radius)	n/a in sources

This is the one page in this cluster where the Ethereum/Solana comparison is genuinely lopsided rather than symmetric: the entire problem class exists because Ethereum chose to scale through many separate execution environments secured by one settlement layer, while Solana scales a single execution environment directly. Solana’s cross-domain interop needs (moving assets to and from Ethereum’s rollups) are met by the bridge and intent designs covered elsewhere in this cluster, not by anything resembling EIL, synchronous composability, or shared-sequencer atomicity.

9. Reference doc

The reference

EIL: Trust minimized cross-L2 interop — yoavw, 13 November 2025. ethresear.ch/t/23437

Summary of the reference

The post opens by naming the cost of existing cross-L2 UX fixes: solutions that improve the multichain experience today typically sacrifice censorship resistance (routing through intermediaries), security (trusting third parties with funds or attestations), privacy (exposing IP address or intent), or openness (running critical logic off-chain and opaquely). EIL’s stated goal is the UX of a single chain with Ethereum’s own security and censorship resistance, achieved by having users initiate and settle every cross-chain action directly from their own wallet rather than through relayers or solvers.

The post frames two structural obstacles before presenting its design. First, general-purpose censorship-resistant intent solving is hard: permissionless solvers face Sybil and griefing risks (malicious contracts designed to make solvers revert without payment, echoing the “salmonella” incident that pushed MEV searchers toward token whitelists), and mitigating every possible intent-abuse pattern effectively requires whitelisting either solvers or intent types — which breaks either censorship resistance or generality. Second, it names a “Privacy/Safety/UX trilemma”: on-chain intents give privacy and UX but lose front-running safety; off-chain solver networks give safety and UX but leak identity to the solver; splitting a flow into two transactions gives privacy and safety but costs UX. EIL’s resolution is architectural: eliminate the third party from the execution path so there’s no “mid-state” — the analogy given is buying gas for your car (no dependency once purchased) versus buying a bus ticket (committed to the operator’s route and schedule for the whole trip).

The mechanism has two parts. Multichain calls use an ERC-4337 account signing a single Merkle root over N per-chain UserOps, so one signature authorizes an arbitrary sequence of cross-chain actions even for hardware wallets that can’t natively multi-sign. Token transfers (needed for both value movement and gas payment on unfamiliar chains) go through a CrossChainPaymaster, funded by permissionless XLPs who stake on L1 (8-day unstaking delay) and deposit liquidity per chain; a transfer is an atomic swap secured by a voucher — the same signed message that claims a user’s locked funds on the source chain also releases the XLP’s funds to the user on the destination chain, so there is no window in which value exists on neither side. A reverse Dutch auction on the fee, combined with XLPs that are also mempool bundlers, is expected to produce same-block fulfillment in the common case. The post closes by explicitly scoping EIL against alternatives: it is not an intent system (no delegated decision-making to a third party), not a messaging protocol (it uses the canonical bridge only for L1-adjudicated disputes), and not suited to very large single transfers, contract-to-contract calls that must trust the calling contract rather than the user, or offchain-counterparty flows like RFQ order books.

Key quotes

“We want the UX of a single chain, the security and censorship resistance of Ethereum, with the scalability, price, and speed of the L2 ecosystem.” (The vision)

“Since the solver must execute arbitrary logic on untrusted contracts, full censorship resistance and generality are fundamentally in tension.” (Why general purpose censorship resistant intents are hard)

“This presents a trilemma: {Privacy, Safety, UX} — pick 2 out of 3” (Why crosschain privacy is hard)

“If Alice initiates every transaction on every chain without intermediaries transacting on her behalf, no one can censor her, grief her, limit her to specific use cases, or compromise her privacy. Goal achieved.” (This can be solved by putting the user in full control)

“With intents or Bridges, there is this mid state where a 3rd party is supposed to ‘get you there’, and at that point you’re dependent on them. EIL does not have this mid state because the calls are made by the user, not a 3rd party.” (EIL is not Intents or Bridges)

How to read the original

Background needed: what ERC-4337 (account abstraction, UserOps, paymasters) and EIP-7702 (EOA delegation) do, and a rough sense of how an HTLC-based atomic swap enforces “both sides happen or neither does.” Skip the extended reply thread on reorg mechanics and stake-sizing arithmetic (replies discussing the exact 8-day/1-hour/5-minute timelock tuning) on a first pass — the core design is fully stated in the main post. The hardest paragraph is the fee/mempool-dynamics section: it’s easy to read “reverse Dutch auction” and assume users typically wait through a rising-fee climb, but the actual claim is closer to “if you offer the current market fee upfront, an XLP-bundler fills you same-block” — the auction only matters for users who deliberately underprice their request and are willing to wait.

What changed since

• Synchronous composability via realtime proving (2026-02, jbaylina) is explicitly framed by its own author and by replies as a complementary building block for EIL — proxy contracts and execution tables could, in principle, let EIL-style calls become synchronous rather than atomic-swap-based once realtime proving matures; see the “Synchronous composability via realtime proving” section above.
• EIL’s own thread records an evolving design between initial posting (2025-11-13) and later replies (through 2025-12-17), including clarified stake economics (why the L1 stake is O(networks) rather than O(funds)) and explicit scoping against institutional-scale transfers — a later addition, not present in the original post’s framing.
• No shipped implementation or production deployment of EIL is documented in these sources as of the thread’s latest reply.

Secondary references

1. Steps to Achieve Atomic Execution in Rollups (0xTariz, ethresear.ch, 2024-02) — read if you want the shared-sequencer, encrypted-mempool approach to cross-rollup atomicity that predates and differs structurally from EIL’s account-based approach.
2. Synchronous Composability Between Rollups via Realtime Proving (jbaylina, ethresear.ch, 2026-02) — read if you want the proxy-contract/execution-table mechanism for true synchronous (same-transaction) cross-chain calls, which EIL explicitly does not attempt.
3. Introducing OneBalance (ethresear.ch, 2024-05) — read for a related but distinct account-redesign angle (resource locks, credible commitment machines) covered in /cross-chain/intent-solvers/.

10. Sources

• EIL: Trust minimized cross-L2 interop — yoavw — 2025-11-13 — https://ethresear.ch/t/eil-trust-minimized-cross-l2-interop/23437
• Synchronous Composability Between Rollups via Realtime Proving — jbaylina — 2026-02-02 — https://ethresear.ch/t/synchronous-composability-between-rollups-via-realtime-proving/23998
• Steps to Achieve Atomic Execution in Rollups — 0xTariz (Radius) — 2024-02-23 — https://ethresear.ch/t/steps-to-achieve-atomic-execution-in-rollups/18776
• Introducing OneBalance — Stephane Gosselin, Ankit Chiplunkar (Frontier Research) — 2024-05-15 — https://ethresear.ch/t/introducing-onebalance/19557