# L2 Interop Working Group - Call #17 **Dec 3rd, 2025** - [Recording](https://youtu.be/3GwFrv-N0xU) - [Calendar invite for future calls](https://docs.google.com/forms/d/e/1FAIpQLSfMFEJmyVgjLuiipgxprEkiQXwwK3F_PfGbWvU8ZmV6e_ka0A/viewform) ### [Agenda](https://github.com/ethereum/pm/issues/1832) - Interoperable addresses aka chain-specific addresses (ERC-7828 and ERC-7930) [Unruggable + Wonderland] - binary format (7930) and human-readable (7828) e.g. `vitalik.eth@rollup-name` - Open Intents Framework - OIF updates [Barnabé, Pepe, Mislav, Orca, Kaimi] - [Nethermind OIF Starknet](https://github.com/NethermindEth/OIF-starknet) [John] - Updates on 7-day withdrawal window reductions - see [eth-magicians thread here](https://ethereum-magicians.org/t/i-think-its-ok-to-allow-stage-1-rollups-shorter-withdrawal-windows-1-2-days-but-we-should-be-more-conservative-on-stage-2/26392) ## Call Notes *condensed notes below – watch the recording (above) for full discussion* --- ## 1. Interoperable addresses (ERC-7828 & ERC-7930 – Unruggable + Wonderland) ### Overview & goals - “Interoperable / chain-aware addresses” for the Ethereum ecosystem, with support for non-EVM chains as well. - Aims to fix: - Wrong-chain sends and lost funds. - Typos / unreadable raw addresses. - Reliance on centralized chain lists for chain IDs → names. - Design goals: - **Chain-specific addresses** to prevent user mistakes. - **Onchain registry** for chain metadata, not off-chain lists. - **Compact binary format** for cross-chain messaging / intents. - **Human-readable format** (ENS-based, e.g. `vitalik.eth@base`). - **Universal compatibility** across chains and tooling. ### Technical design - Two-layer spec: - **ERC-7930** – *Binary representation* - Compact encoding for chain + address, suitable for messaging/intents. - **ERC-7828** – *Human-readable wrapper* - Wraps 7930 in ENS. - Uses ENS both for **address resolution** and **chain name resolution** → examples like `alice.eth@optimism` or `foo.eth@base`. - Wonderland’s **Interop SDK – addresses module**: - Demo site (not yet public) shows how a human-readable address decomposes into the binary representation. - SDK already exposes this parsing/encoding plus FAQs. ### ENS & chain resolver / registry (Thomas – Unruggable) - **7930 spec status**: - Terminology and semantics being refined to make the spec accessible. - “Very close” to completion; plan is to open a PR to the main ERC repo soon. - **7828 spec status**: - Adds ENS-specific functionality: - **Chain registry resolver** for `on.eth` (2nd-level name). - This resolver is the entry point for **chain metadata discovery**. - **ENS governance for `on.eth`**: - Josh posted a *temperature check* on the ENS forum to assign `on.eth` to a new multisig. - Feedback from ENS DAO: *unanimously positive*; no disagreement mentioned. - Next step: Thomas will prepare calldata for an **executable proposal** in ENS DAO to: - Assign `on.eth` to a multisig. - Set the chain resolver as the resolver for `on.eth`. ### Chain resolver details & admin model - **Chain resolver repo**: - “Complete and ready to go”; only final touches left. - Adding **aliases** so multiple labels map to the same chain ID, e.g.: - `OP` / `Optimism` - `ARB` / `Arb1` - **Chain list publication**: - Orca is assembling a canonical list of: - Chains - Labels - Associated metadata - Plan: publish on **ENS forum** + **EthMagicians** and circulate on social media - Goal: get chain operators to validate their entries. - **Admin / governance plan**: - Phase 1 (bootstrap): - Resolver controlled by a **multisig** with reps from: - Wonderland - Unruggable - Ethereum Foundation - ENS DAO, etc. - Phase 2 (decentralization): - **Authoritative ownership** of each chain’s metadata is handed over to chain teams. - Multisig relinquishes administrative control → chains manage their own entries. ### Adoption & next steps - **Wallets & standards**: - Ongoing conversations with wallets about integration. - Already showing up in other standards/efforts (e.g. “clear signing,” referred to as 7730 on the call). - **Implementation rollout**: - After the ENS executable proposal: - Final testing on `on.eth` in production. - PRs into “established frameworks” (e.g. client libraries, wallets, dapps) so this becomes standard infra. - **Immediate follow-ups**: - Share NPM package link (Orca dropped the Interop SDK link in chat; website still not public-ready). - ENS proposal + resolver deployment & testing. - Publish chain list for community review. **Key takeaway:** Interoperable addresses (7828/7930) are *very close* to being production-ready: specs are nearly finalized, ENS governance path for `on.eth` has broad support, and tooling (SDK + resolver) exists. Focus now is on final polish, governance execution, and ecosystem adoption (wallets, standards). --- ## 2. Open Intents Framework (OIF) updates ### 2.1 Patagonia “hack week” outcomes (Barnabé – EF) - Pre-Devconnect, teams from: - Ethereum Foundation, OpenZeppelin, Wonderland, LI.FI, others - Goal: **accelerate OIF integrations** and get an end-to-end intent demo that: - Is secure. - Propagates through all OIF layers. - Highlights of what was built: 1. **Payment request demo** - Used *interoperable addresses* + OIF - End-to-end settlement via the OIF stack. 2. **Cross-chain deposits via composable batching** - Built by Biconomy / Vaults FYI / Kaimi (more detail from Mislav later). - Gives apps a “toolbox” to easily expose interop flows to users. 3. **Compliant resolver using ERC-7683** - Makes solvers interpret orders in a standardized way → deeper solver markets with shared semantics. 4. **Hardened oracles / optimistic security game** - Design where: - Solver proposes settlement. - Others can challenge. - Disputes are resolved via the **Broadcaster** (trust-minimized proofs via canonical bridges). 5. **ZK proof integration for field proofs** - Work on using ZK proofs instead of storage proofs in some parts of the system. 6. **AI + agents experiments** - One project mixing AI agents, resource logs, TEE, etc., as part of an intent-based stack. **Barnabé’s meta-take:** Three days were enough to build several serious prototypes on top of OIF → the stack is far enough along to enable real experimentation, not just design docs. --- ### 2.2 OIF contracts, audits, and roadmap (Pepe – OpenZeppelin) - **Settlement contracts**: - “Main outlet” of OIF Settlement Contracts released (in the OIF contracts repo). - **Broadcaster audits**: - Core Broadcaster contracts have already been audited. - Audit not yet fully public, but expected to be shared relatively soon. - Next audit will cover **provers for different network types**. - **Callback / arbitrary-action support**: - Patagonia surfaced a limitation: solver couldn’t easily support arbitrary callbacks / actions beyond simple token moves. - There is now a **solution in the solver repo** that extends this capability – interested folks can dig in there. - **Current focus areas**: 1. **Broadcaster & provers** – maturing and securing these components across chains. 2. **Onboarding the “long tail” of edges / L2s**: - Biggest requirement: a solver or solver network that supports the new L2. - Many networks don’t want to run solver infrastructure themselves. - Team is exploring how to: - Help bootstrap solver infra. - Handle liquidity management for new chains. - Invitation: if an L2 wants OIF support and is struggling with existing intent providers, reach out to Pepe/OIF team. --- ### 2.3 Gas overhead & incentives discussion (Orest + Pepe) - **Concern:** On an OIF drivers call, they realized that even a seemingly small gas overhead (~10k) from an OIF wrapper **might be a dealbreaker** for some solvers and aggregators. - **Question to group:** What would it take for a slightly less gas-efficient standard to still be attractive? What benefits (e.g. compatibility, shared infra) would justify the overhead? - **Pepe’s response:** - Yes, a standardized wrapper adds gas cost. - But it also **greatly enlarges the compatibility surface** and simplifies integrations. - They’re discussing this with LI.FI & Across, who have their own approaches. - Feedback invited → especially from solver / aggregator operators. **Takeaway:** Gas cost vs. standardization is a live trade-off. The OIF team wants concrete input from integrators before locking in wrapper designs. --- ### 2.4 Composable batching & cross-chain vault rebalancing (Mislav – Biconomy) - **Goal / problem space:** - Cross-chain vault rebalancing (e.g. USDC vault on Arbitrum → USDT vault on Base) is currently messy: - Series of steps: withdraw from vault → swap → bridge → approve → deposit into new vault. - Slippage and “dust” accumulate at every step, often compounding to ~1–2% or more. - Today, solvers often hold inventory in vault tokens and quote from inventory → can result in massive slippage (esp. for smaller vaults). - **What they built:** - Combined: - **OIF / 7683** - **ERC-4337** - **ERC-7579 (MerkleTree validator module)** – Biconomy’s module, similar to the EIL MerkleTree validator. - Biconomy **supertransactions** - Vaults FYI **call data generation** - Achieved **single-signature, single-click execution across multiple chains**, including: - Withdraw from Vault A. - Swap. - Bridge. - Approve + deposit into Vault B on another chain. - **Key OIF feature exploited:** - With OIF, the executed value doesn’t need to match the quoted value **exactly**. - You can quote (say) 3,100 USDC → 1 WETH. - Execution can adjust within bounds, absorbing slippages without leaving residual dust in each step. - Result: Only the main OIF swap leg experiences slippage; the batched operations stay effectively **zero-slippage**. - **Status & next steps:** - Built and demoed in Patagonia in ~3 days (demo “janky” but worked). - Code is **audited and ready to go**. - Mislav would like to: - Propose **“composable batching” as an ERC**. - Ultimately see it as a standard part of the Ethereum stack. **Takeaway:** Composable batching + OIF can make complex cross-chain DeFi flows (like vault migrations) almost zero-slippage from the user’s perspective, and Biconomy wants to standardize these patterns. --- ### 2.5 Nethermind OIF StarkNet implementation (John & Matt – Nethermind) - **What they built:** - A **Cairo implementation** of OIF’s Solidity contracts for StarkNet. - A **Go-based solver** (instead of the reference Rust solver). - Full **test suite** + **template solver** so others can: - Fork, customize strategies. - Quickly get started with StarkNet OIF integrations. - **Hackathon demo:** - Their lead dev then used this stack for a hackathon project with a new PoC network (“ZarkNet” / “Darknet”). - Demo flow: - User connects EVM wallet + StarkNet wallet. - App bridges an ERC-20 (“$1 coin”) from EVM chain → StarkNet. - Solver picks up the order, fills it, and the tokens appear on StarkNet. - They showed the solver logs and described the final state; no protocol changes, but complete working implementation. - **Motivation:** - “Celebrate a win” and show that: - OIF is not Ethereum-only. - StarkNet has a path to plug into the OIF ecosystem. - There is ready-made infra for StarkNet builders to experiment with. **Overall OIF takeaway:** OIF is moving from design into *real implementations and audited infra*: - Settlement contracts + broadcaster are live and undergoing audits. - Multiple concrete demos (payments, cross-chain vaults, agents). - Multi-chain implementations like StarkNet are appearing. - Open questions remain on gas overhead and solver economics, but the ecosystem momentum is strong. --- ## 3. 7-Day Withdrawal Window Reduction (Optimistic Rollups) ### Context (Josh) - Optimistic rollups currently use a ~7-day challenge / withdrawal window. - Original rationale (per Donnoh’s post from L2Beat, which Josh shared in chat): - Give enough time for a **social response** (e.g. in the face of censorship or malicious rollup sequencers / builders). - Protect user funds from being stolen before an honest party can challenge. - Downsides: - UX bottleneck for users. - Capital friction and liquidity fragmentation. - Limitation on cross-chain composability and “seamless” user experience. - Renewed interest: - Many parties would like to see shorter windows (e.g. **1–2 days**). - Broad agreement that benefits are meaningful. - But everyone acknowledges: this is a **sensitive security parameter**, so changes must be principled, not “YOLO.” --- ### Ed Felten (Offchain Labs): what’s needed to justify reduction? **Core requirement:** To safely reduce the window, we need a **credible analysis** showing that a user can get a transaction *included on L1* within the new assumed inclusion time (e.g. 24 hours), *against a highly motivated and capable adversary*. Key points: 1. **Inclusion time assumption is the real knob.** - The 7-day window implicitly encodes assumptions about: - How quickly an honest actor can get a transaction onto L1. - How resilient the system is to censorship, network attacks, etc. - Reducing the window means tightening that inclusion-time assumption. 2. **We cannot rely on unrealistic assumptions.** - Example of *unrealistic* assumption: - “If I send a transaction at time 0, it instantly appears and stays in every builder’s mempool, even under adversarial conditions.” - Reality: - Adversaries can: - Disrupt mempool propagation. - Attack the P2P network. - Execute various denial-of-service strategies. 3. **Economic attacks are only one piece.** - Donnoh’s formula (based on an Offchain Labs paper) looks at one **economic censorship attack** scenario. - But: - Adversaries have *other* tactics beyond pure economic bribery. - Combining tactics means the paper’s guarantees do **not** translate directly into Ethereum-wide guarantees. - Conclusion: - Donnoh’s work is a useful *piece*, but **not sufficient** to justify reducing the window. 4. **Under-analyzed dimensions:** - **Old-school denial-of-service attacks**: - E.g., targeted network flooding attacks on the honest challenger or rollup user. - Question: What assumptions can we safely make about their ability to recover connectivity and submit transactions? - **P2P propagation & client mempool behaviors**: - Clients use idiosyncratic heuristics to: - Manage mempools. - Decide what to drop when full. - Hard to reason about: can we assume a transaction remains in the mempools of *all* builders against active manipulation? - **Delay vs. safety**: - Some attacks aim to **delay settlement**, not steal funds outright. - Delay can still be highly damaging for cross-chain interop, UX, and economic activity. **Ed’s bottom line:** - We currently lack a comprehensive threat model + analysis to say: - “Yes, under assumptions X, Y, Z, an honest party can get included within 24 hours.” - We may not even be able to guarantee inclusion within 24 hours “at any price,” given non-economic attacks. --- ### 2-of-3 / “Pragmatic Fast Finality” angle Josh asked about an alternate path: a 2-of-3 style system often described as “Pragmatic Fast Finality,” where: - You have three “tracks”: 1. ZK proving. 2. Optimistic proving/fraud proofs. 3. Security council (SC) veto / intervention. - You get “fast” settlement when **2 of 3** have been satisfied. Ed’s clarifications: - **Security council is also subject to censorship assumptions.** - SC intervention still requires L1 transaction inclusion. - So censorship resistance assumptions still matter. - **ZK proving can also be censored.** - Censoring a ZK proof doesn’t break safety but **delays settlement**. - A motivated adversary can realistically delay posting of ZK proofs to stall cross-chain flows. - **Offchain Labs’ work:** - Offchain Labs R&D is actively working on such a 2-of-3 scheme. - Ed gave a public talk ~1 year ago on this style of design. - No public timelines / dates have been announced (confirmed by Allan on the call). **Takeaway:** Even in a 2-of-3 world, censorship / inclusion-time assumptions remain central. A 2-of-3 design may **change** the trade-offs, but it does not magically remove the need to analyze censorship and delays. --- ### Next steps & coordination - **What’s missing today:** - Clear assumptions & models for: - DoS attacks on users / challengers. - P2P propagation & mempool resilience. - Combined economic + non-economic censorship strategies. - **Opportunities for collaboration:** - Ed invited contributions from others (rollup teams, researchers, infra providers) on: - Analyzing DoS resistance. - Reasoning about mempool behavior under adversarial conditions. - Josh noted that: - Many teams (Arbitrum, Optimism, Uniswap, others) have expressed interest. - But no one yet has clear bandwidth/ownership for a “full” analysis. - **Allan’s offer (Offchain Labs):** - Happy to work with Josh to: - Pull in the right people from other teams. - “Check boxes” around assumptions and risk analysis. - Help herd cats beyond this working group. - **Josh’s closing:** - Acknowledged that everyone is busy and no one owns the “analysis project” yet. - Hopes that with some deliberate coordination and herding, they can: - Make concrete progress over the coming weeks. - At least clarify assumptions and outline a research agenda, even if they don’t immediately change the window. **Overall takeaway:** There is strong desire to reduce the 7-day window, and broad agreement on the UX/economic benefits. But nobody wants to move without a **rigorous, adversary-aware inclusion-time analysis**. The next step is less about “deciding a number” and more about coordinating research across L2 teams, security experts, and client implementers to understand what Ethereum’s L1 can reliably guarantee for transaction inclusion under attack.