# L2 Interop Working Group - Call #18 **Dec 17, 2025** - [Recording](https://youtu.be/GLSvSyAh54w) - [Calendar invite for future calls](https://docs.google.com/forms/d/e/1FAIpQLSfMFEJmyVgjLuiipgxprEkiQXwwK3F_PfGbWvU8ZmV6e_ka0A/viewform) ### [Agenda](https://github.com/ethereum/pm/issues/1838) 1. OIF updates on crosschain broadcaster from OpenZeppelin (Pepe) 2. ZKSync interop (Noah) 3. OIF updates and ERC-7930 from Wonderland (Orca) 4. Synchronous composability vs async composability: open discussion ## Call Notes *condensed notes below – watch the recording (above) for full discussion* --- ## 1) OIF update: Crosschain Broadcaster “oracle” (OpenZeppelin — Pepe) ### What was shared - Broadcaster: message-passing protocol now being polished/finalized by OpenZeppelin for OIF usage. - Purpose inside OIF: used as an oracle-style, trustless message-passing system (not optimized for “lightweight” UX). - Tradeoff: “trustless” implies heavier proofs / interactions and slower confirmation because it relies on settlement timelines. ### Key details / status - Architecture: requires - a core/broadcaster contract on each network, and - a network-specific prover per stack. - Provers mentioned as being developed/tested across multiple architectures, including Arbitrum, Optimism, zkSync, Scroll. - Audits - Core protocol contracts: already audited. - Audit report expected to be public “this week”. - Provers: audit in February (planned). - Rollout expectation: “real use cases” targeted for Q1 (first quarter). ### Takeaways - OIF is actively investing in a trust-minimized “oracle-like” interop primitive, with explicit acknowledgement that latency + complexity are costs. - Near-term opportunity: teams can test on testnets and provide feedback / find issues before mainnet deployments. ### Action items / follow-ups - Pepe/OpenZeppelin: share testnet deployments info + (when ready) the audit report. - Builders: reach out to Pepe (via Josh / Telegram) if interested in experimenting, testing, auditing. --- ## 2) zkSync Interop (Noah) — “Scaling Ethereum’s liquidity with L1 Interop via ZK Stack” ### Problem framing - New chains (L1s or L2s) face a repeated DeFi cold-start problem: - apps redeploy from scratch - liquidity must be rebuilt - incentives attract “mercenary capital” that disappears when subsidies stop - Thesis: Ethereum holds durable liquidity, and zk-based L2s can “scale Ethereum liquidity” by letting users access L1 DeFi without switching networks. ### What zkSync calls “L1 Interop” - Demo described: users on a zkSync / ZK Stack chain can: - deposit into Aave on Ethereum L1, - borrow assets (e.g., ETH/USDC/etc.), - without switching networks, maintaining “one wallet / one identity.” ### How it works (high-level flow) - User signs two L2 transactions: 1) withdraw funds to a cryptographically bound, deterministic “alias” account on L1 mapped from the user’s L2 account 2) submit an interop bundle: a list of arbitrary L1 actions (Aave/Morpho/Uniswap/Pendle, etc.) - Optional: bridge resulting tokens back to L2 automatically. - Emphasis: no commingling of user funds—actions happen via the user’s L1 alias account. ### Performance / constraints discussed - Noah: withdrawals can finalize on L1 “in minutes”; user-perceived latency is minute-scale, primarily limited by L1 finality / settlement frequency. - Orest asked about “1 second” proving vs L1 proving delay: - Noah: gateway aggregates proofs; also there are different proof types (fast internal proofs vs an L1-verified SNARK), and “snarkification” currently takes a couple minutes. ### “Prividium” (private execution environment) thread - Target customers: institutions who need privacy/compliance features. - Privacy model described as role-based access control + off-chain data availability (Validium-like), not “mixer-style” privacy. - Key clarification exchange: - Anjan asked about privacy guarantees / stealth addresses: Noah said it’s enterprise privacy, not Zcash-like. - Orest pressed on what is leaked: Noah argued execution details are not leaked; rules enforced via private RPC layer and PII remains in institution-controlled services. ### Adoption / pipeline - Noah: one Prividium live with Memento “operating it for Deutsche Bank.” - More announcements expected Q1; more in Q2 but constrained by NDAs. ### Takeaways - zkSync is positioning L2s (and private L2s) as distribution/compute layers that can directly tap into L1 DeFi liquidity using alias accounts + bundled L1 execution. - The approach prioritizes institutional workflows where minute-scale latency is acceptable, and “privacy” is framed as permissioned visibility rather than cryptographic privacy. ### Action items / follow-ups - Open questions raised by participants: - settlement frequency of the zk gateway, - practical latency bottlenecks and how they evolve with L1 improvements, - privacy threat model clarity (what is revealed on L1 vs protected behind private RPC / off-chain DA). --- ## 3) OIF updates + ERC-7930 (Wonderland — Orca) ### OIF: Asset discovery addition to the spec - Observation: interop providers typically expose APIs for chain/token/route support, but OIF spec previously focused on quotes + orders. - Wonderland added an asset discovery endpoint to OIF specs and asked for feedback: - different providers structure this differently (separate chains/tokens endpoints, route support, etc.) ### OIF SDK work: cross-chain module + spec compliance testing - Wonderland building an Interop SDK cross-chain module and testing against OIF-compliant implementations. - Found areas where existing implementations “are not aligned with the OIF specs.” - Actively coordinating with: - OpenZeppelin (solver/aggregator) - LIFI - Request: other teams with OIF-compliant endpoints should reach out to be tested. ### Quote validation in the SDK - Problem: if you request a quote from an API, it can return “something to sign” that might be malicious or surprising. - Wonderland exploring client-side quote validation for: - on-chain tx payloads - EIP-712 typed data - user intent packages - Orca solicited collaboration with teams thinking about “don’t blindly trust the API response.” ### ERC-7930: interoperable addresses & interoperable names (debate) - Orca: ERC-7930 has been heavily revised recently with help from Unruggable contributors; encouraged fresh review. - Current tension: 7930 defines both - binary interoperable addresses (machine-readable), and - interoperable names (string form) - Concern: having both in the same ERC may be confusing for implementers. #### Discussion thread - frangio asked: are interoperable names in 7930 and are you considering removing/moving them? - Premm.eth’s position: “7930 address” should have a single clear meaning (binary). Human-readable naming belongs elsewhere (e.g., 7828). - He referenced another spec effort that had to be very explicit about “binary vs name,” which he viewed as a burden. - Orca: implementations diverge; want feedback on asset discovery and spec alignment. - Orca: question is whether having both address + name in one spec is “confusing.” - Premm.eth: “it should be very clear when someone says 7930 address what they mean.” ### Takeaways - Wonderland is pushing OIF toward being more complete for real integrations (asset discovery, SDK validation). - ERC-7930 is approaching a decision point on scope: keep both binary + name forms vs split responsibilities across ERCs (e.g., keep 7930 binary, push human-readable to 7828). ### Action items / follow-ups - Interested teams: provide feedback on asset discovery spec + help test SDK against additional OIF endpoints. - ERC-7930 contributors: continue discussion on forum/Telegram about “names vs addresses” scope split. - https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365/14 --- ## 4) Open discussion: Synchronous vs asynchronous composability ### Framing by Josh - Josh invited thoughts on: - value/urgency/priority of full synchronous composability - whether async interop gets “most of what we need” - cost/benefit and ecosystem prioritization - See recent post from Alon: https://ethresear.ch/t/synchronous-composability-vs-intents-two-paths-to-ethereum-wide-interop/23426/7 ### Pro-synchronous composability perspective #### Alon (SSVLabs) - Ethereum (L1 + L2s) should feel like one execution environment, not separate chains. - intents / fast async messaging doesn’t achieve: - arbitrary reads/writes across domains in a stateful way - developer experience comparable to single-domain EVM composability - Pushback on “synchronous = shared sequencing”: - claims newer approaches do not require shared sequencing - referenced recent work (e.g., [“SCOPE” framework](https://ethresear.ch/t/scope-synchronous-composability-protocol-for-ethereum/22978)) enabling sync-like composability while keeping independent sequencers. - Urgency here: fragmentation makes it nearly as hard to launch an L2 as an L1; see recent examples of projects choosing to go the L1 route #### Friederike (Gnosis) - Strong agreement that synchronous composability is essential for Ethereum to feel unified. - Use cases beyond token transfer (business logic, identity, cross-domain contract calls). - Example: proving identity/attestations across networks “atomically” without long waits. ### Pro-async perspective #### Noah (zkSync) - Expressed skepticism: struggles to find compelling sync use cases beyond “cross-chain flash loans.” - Claimed most sync use cases can be handled by async “atomic interop.” - Added concern: as privacy-preserving tech grows, sequencer-level coordination becomes harder to adopt (though Alon objected that modern sync doesn’t require shared sequencing). #### Lumi (Offchain Labs) - Skeptical of “new programming paradigms” justification. - Argued: - Not every L2 needs to replicate the entire app set; specialization can work if cross-chain swaps are cheap/good. - Scaling concern: “no distributed computer system… is synchronous” at mass scale; real question is whether it can scale. #### Orest (t1) - Asked for concrete examples that truly require synchrony. - Suggested fast async composability can reach near real-time given fast proofs, and that sync vs async can be framed as DevEx differences rather than fundamental capability. - Disputed some latency claims by pointing to the possibility of frequent proof posting (economics permitting). ### Takeaways - There is alignment that interop likely needs multiple tiers (trust-minimized slower paths + faster paths with tradeoffs). - Core unresolved disagreements: - whether synchronous composability is necessary vs “fast async is enough” - what “sync” really entails in modern proposals (shared sequencing vs newer decoupled approaches) - feasibility/scaling and what guarantees matter most (atomicity, trust minimization, DevEx) - The discussion is moving toward a need for: - a clearer understanding of what is uniquely possible with sync composability - a shared vocabulary (sync composability vs fast async messaging vs intents vs proof-based reads) ### Follow-ups suggested - Continue debate in more durable venues (forum/Telegram). - Collect concrete “sync-only” examples and compare against best-known async alternatives (including security/trust assumptions). ---