# L2 Interop Working Group - Call #16 **Nov 5, 2025** - [Recording](https://youtu.be/Pw5qq1fpsio) - [Calendar invite for future calls](https://docs.google.com/forms/d/e/1FAIpQLSfMFEJmyVgjLuiipgxprEkiQXwwK3F_PfGbWvU8ZmV6e_ka0A/viewform) ### [Agenda](https://github.com/ethereum/pm/issues/1753) - Reducing the 7-day withdrawal window - see [eth-magicians threads ](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* ### TLDR - Question: - Should we reduce withdrawal windows for stage 1 optimistic rollups from 7 days → ~1 day to improve UX/liquidity? - Why 7 days exists: It protects against strong censorship attacks, giving time to detect/coordinate a response. - Pro-shortening: - Users already rely on trusted bridges → shorter native exits may improve actual security. - Better UX, fees, and liquidity, especially for smaller L2s. - Vitalik: If we want actually-decentralized defi to thrive, we need faster withdrawals. In the medium term, this is why I support fast withdrawals through ZK proofs, or a hybrid 2-of-3 scheme... In the short term, before such technologies are ready, allowing faster withdrawals from optimistic rollups could cut liquidity providers’ costs by 3-7x, which is still a helpful win. - Risks: - Without inclusion guarantees (FOCIL), defender costs under censorship may be high - Fork-based recovery fragile, should have measurable guarantees - Potential next steps: - Defender-cost modeling - Quantify censorship-resistance budgets for 1d vs 2d vs 7d under multi-challenge attacks (Who pays? How much?) - FOCIL / inclusion-guarantee roadmap - ensure the first tx lands - Censorship-detection trigger - Automatic extension or pause when censorship is observed on L1. - Real-world liquidity + fee impact evidence - Data from MMs/bridges/CEXs **Background reading** - Vitalik’s Magicians thread arguing 1–2 days may be OK for Stage-1 but be conservative for Stage-2: 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 - Donnoh (L2BEAT) ethresear.ch post on why 7 days exists and the role of strong-censorship response timelines: https://ethresear.ch/t/optimistic-rollups-the-challenge-period-and-strong-censorship-attacks/21721 --- **Main question:** Is it acceptable (and wise) for Stage-1 optimistic rollups to shorten the L1 withdrawal/challenge period from 7 days to ~1 day? ## 1) Framing & why “7 days” existed in the first place **Summary** - The historical 7d window was not about the number of steps in interactive games; it was meant to allow social response to a **strong censorship (51%) attack** at L1 (detect → coordinate → fork → restore inclusion). - Stage-1 is explicitly “in-between” Stage-0 and Stage-2; the question is whether relaxing to ~1 day is an acceptable temporary stance while many systems still rely on Security Councils. **Key points (Donnoh, L2BEAT)** - Misconception: shorter games ≠ shorter window; 7d defends against strong censorship, not just game length. - Tentative timeline in his post: detect ~24h, coordinate/activate fork ~5d, ~1d left to play the game → total ~7d. **Quotes** - “The reason we have 7 days is because we want to protect rollups from strong censorship attacks.” (Donnoh) --- ## 2) Security analysis: strong vs soft censorship; attacker/defender budgets **Summary** - **Strong censorship** (malicious majority attesters) motivates long windows to allow forks. - **Soft censorship** (builder/proposer market dynamics) can be modeled as bidding wars over inclusion; shortening windows changes the economics of how much the defender must spend in tips across multiple moves/challenges. - Papers like BoLD (Arbitrum) bound censorship “budgets,” historically assuming ~1 week - Donnoh warns about compounding costs if attackers open many bogus challenges (“whale attacks”), and that tips burned during censorship aren’t recovered (unlike stakes). **Quotes** - “It might not be enough to play one challenge… an attacker can just post 1,000 invalid state roots.” (Donnoh) **Takeaway** - With current inclusion dynamics, a 1-day window may demand large, *non-recoverable* tip budgets for defenders—especially under parallel/batch attacks. Strengthening L1 inclusion guarantees (inclusion lists/etc.) materially changes this calculus. --- ## 3) Protocol levers that change the answer **What helps shorten safely?** - **FOCIL / inclusion lists / PBS changes**: Increase inclusion guarantees; reduce the cost to land the *first* fraud-proof tx. Donnoh & Potuz note FOCIL dramatically improves economics; Potuz adds on-chain censorship detection/oracles and parameterized responses to measured censorship. - **Model the problem as “one critical tx”**: Potuz stresses the window mainly protects inclusion of the **first** challenge transaction; interactive vs non-interactive is secondary for the withdrawal window itself. - **Non-interactive / optimistic-ZK hybrids**: Rami (Boundless) & Paul (OP Labs) argue that non-interactive/optimistic-ZK designs reduce multi-round griefing and let you resolve quickly once you can compute a proof; they also alter attacker/defender economics. **Quotes** - “Non-interactive… whale attacks [of many disputes] are not possible in the same way.” (Rami) - “Optimistic-ZK… you need one transaction to challenge it, and that’s relevant now.” (Paul) **Takeaway** - If the L1 can reliably include at least *one* well-funded challenge tx promptly (via FOCIL or similar), and/or if the proof protocol is non-interactive/optimistic-ZK, the case for shorter windows strengthens substantially. --- ## 4) Practical security vs theoretical purity (Stage-1 reality) **Summary** - Several participants emphasized *practical user security today*. Many users aren’t using the native 7d bridge; they use fast bridges/CEX routes, which shift risk profiles. - Ellie: enforcing 7d purity may push users to trusted bridges and synthetic assets, paradoxically **reducing** the security users actually experience. - Harry: Optimize for Stage-1’s practical security/UX now; don’t “sacrifice Stage-1 for Stage-2.” Optics matter—decisions should be principle-based, not perceived as YOLO. **Quotes** - “Users do not actually get the security… because they are using trusted bridges and synthetic assets.” (Ellie) - “We should be optimizing for the practical security of Stage-1 rollups today.” (Harry) **Takeaway** - There’s a credible *harm-reduction* argument: a shorter window may give **better net security** to users who in practice depend on fast-exit interop, provided the change is explained and paired with mitigations. --- ## 5) Liquidity, market-maker, and UX impacts **Summary** - **Greg (Sprinter):** 1 day still won’t make MMs use the native bridge for intra-day rebalancing; they need *hours*, not a day. Big gains kick in closer to ~1 hour. - **Matt (Across):** Even so, 7d→1d *is* a big deal for **user costs during directional flows** off an L2: capital turns 7× faster, LP utilization eases, fees to users should drop materially in those periods. - **Karl:** Lowering to 1 day expands viable chains for price discovery and cross-chain routing (especially smaller/newer L2s); improves “network health.” - **Lumi:** Disproportionate benefit for *small chains*; asks for data to avoid a race-to-the-bottom on window length without evidence. **Quotes** - “It won’t dramatically improve the market-maker solver landscape… we still won’t use [native bridge].” (Greg) - “Users should see a roughly 7× lower cost [in directional outflows].” (Matt) - “Small chains do not get efficient price discovery nor Across integrations with long windows.” (Karl) - “Instinctively makes sense… but we need better data.” (Lumi) **Takeaway** - **User-costs** in outflow spikes likely improve meaningfully with 1 day; **pro-MM rebalancing** still wants **hours-level** windows. Benefits may be biggest for small/long-tail L2s. --- ## 6) Governance/operations, assumptions, and optics **Summary** - **Fork-in-5-days** is an *assumption*, not a guarantee; several are skeptical that “we can just fork” is a robust security story. - Some suggested **incident drills** for Ethereum (simulate censorship, see if we can coordinate). - **Assumptions we wish to make**: Potuz would prefer we aim for guarantees like “≥5% honest validators running vanilla software” post-Glamsterdam to underpin inclusion guarantees. - **Optics**: Any change should be accompanied by a clearly reasoned security model and measurement plan **Quotes** - “A fork is going to be catastrophic… 7 days as a reason doesn’t make a lot of sense [if it relies on forking].” (Rami) - “Let’s not miss Glamsterdam if changes there would enable a safer reduction.” (Harry) **Takeaway** - Tie any reduction to *explicit* preconditions (e.g., inclusion-guarantee upgrades, censorship-detection oracles, drills) and publish a transparent threat model. --- ## 7) Positions — At a glance **Pro-shortening to ~1 day (for Stage-1), with guardrails** - **Karl**: Improves user experience, price discovery, and interop—especially for small chains. - **Ellie**: Today’s reality pushes users to trusted bridges; shorter native windows can be net-safer in practice. - **Matt**: Significant fee relief for users during directional outflows; capital turns faster. - **Paul** & **Rami**: Non-interactive/optimistic-ZK paths change the calculation toward shorter windows; focus on first-tx inclusion. **Caution / keep 7d until conditions met** - **Donnoh**: Defender budgets under soft/strong censorship are unclear/possibly prohibitive without FOCIL; risk we quietly rely on Security Councils. - **Potuz**: Define the security guarantees first, instrument onchain censorship detection, and don’t hand-wave 51% threats. - **Lumi**: Avoid a race-to-the-bottom absent solid data; show the capital-efficiency win quantitatively. --- ## 8) Concrete next steps proposed on the call 1) **Quantify defender budgets** under soft-censorship with multi-challenge adversaries across TVS levels; publish ranges for 1d vs 2d vs 7d 2) **FOCIL / inclusion-guarantee plan** aligned with **Glamsterdam**: what goes in, and what confidence it provides for first-tx inclusion. (Client teams + protocol researchers.) 3) **Censorship detection oracle** design/thresholds (Potuz direction) to *automatically* extend clocks/pause bridges upon detected censorship. 4) **Data pack** from MMs/CEX/bridges: directional flow case studies; fee curves vs lock time; expected utilization and user-fee reduction from 7d→1d. (Across, market makers, CEXs.) 5) **Run “red-team drills”** for strong-censorship response (coordination timing, public comms, rollback playbooks). 6) **Comms/optics**: publish a clear threat model and staged plan (Stage-1 only; Stage-2 conservative), so the change is framed as *principled*. --- ## 9) Potential recommendations / questions - **Security**: 1d windows create open questions around defender tip budgets under adversarial multi-challenge spam. FOCIL/inclusion lists and/or non-interactive/optimistic-ZK proofs make 1d **much** safer. - **UX/Liquidity**: 7d→1d won’t make professional MMs switch to native bridges for intra-day ops, but it *likely* reduces user costs during outflow surges and helps **smaller L2s** reach functional liquidity/price discovery. - **Governance**: Tie any reduction to explicit preconditions and metrics. - Could potentially proceed toward 1–2 days conditional on: a published defender-budget analysis showing feasibility at current TVS; and a data brief from bridges/MMs quantifying expected user-fee impact. --- ## Appendix — Additional speaker snippets - **Greg (MM view):** “It won’t dramatically improve [our] landscape… one rebalance vs 8–12 per day on CEX routes.” - **Matt (Across):** “Users should see roughly **7× lower cost** during directional outflows.” - **Karl (closing):** “Let’s lower exit times—*and* keep users safe—using practical, implementable solutions.” --- ## Highlights from the Zoom chat Greg Markou  (Nov 5, 2025, 9:09 AM) It personally seems a bit reckless as is, if we don’t have people ready with nodes to be performing fraud proofs.. no? Or constantly checking validity of blocks? terence  (Nov 5, 2025, 9:10 AM) more ppl use min-bid now days.. than using the boost Lumi | Offchain Labs  (Nov 5, 2025, 9:10 AM) Also if nothing changes other than the challenge period being shorter, then failures could happen due to client bugs, not only due to attacks. Josh Curious for thoughts on V’s idea + conclusion here To solve both of these problems, I would highly recommend a mechanism where any security council member can flip a switch to extend the delay to 7 days or even longer. This ensures 1-2 day withdrawals in the normal case, but gives enough time to resolve issues when they do arise. For the same reasons as above, 1-2 days is enough time for the fastest member of a security council to be able to flip that switch, even if an exceptional situation happens. Because of the above, I would argue 1-2 days is enough to deal with any problem other than a 51% censorship attack on Ethereum. - Potuz: this is subject to censorship just like the challenge itself - Ellie: But you only need 1 tx to flip the switch instead of many for an interactive proof (and you don’t need to be staked like you do in the fraud games). - Potuz: yes, in the challenge case you also need just 1 tx: as soon as 1 tx comes in, you can increase the window automatically to 7days Potuz  (Nov 5, 2025, 9:22 AM) I think it's less about outcome but rather about what are the security assumptions that rollups give their users. This is not about UX but rather about what we guarantee and not guarantee to Ethereum users karl  (Nov 5, 2025, 9:23 AM) >So the question we should be asking is how confident are we that this change results in a meaningful outcome? From conversations with MMs and CEXs this would be very meaningful, especially for small chains. If it costs ~ $30mm of capital reserves to subsidize fast withdrawals for chains with 7 day withdrawal times, that # goes down to ~$4mm. That's huge for smaller chains and would absolutely encourage usage of canonical bridges Lumi | Offchain Labs  (Nov 5, 2025, 9:25 AM) Also this has an outsized benefit for small chains with low liquidity and centralized chains. This is indeed good, but arguably any chain with real traction would have enough capital incentives for MMs to add liquidity. For larger chains (where most TVS is), this is not that big of a benefit as sophisticated solvers don’t need to rebalance frequently. E.g. If 1 ETH sent from Chain A → B && 1 ETH sent from Chain B → A, nothing needs to be rebalanced. karl  (Nov 5, 2025, 9:25 AM) To be clear, at least in OP's case lowering the withdrawal times for fault proofs is a near term improvement as ZK tech improves Greg Markou  (Nov 5, 2025, 9:25 AM) 1 day brings down the cost of subsidizing intent bridge systems Noah’s iPhone  (Nov 5, 2025, 9:23 AM) Even with this people will still use solvers to get to 1s bridging until we get single slot finality and ZK rollups can be verified in 1 block Ellie Davidson  (Nov 5, 2025, 9:23 AM) Solvers are okay, though, because they use native assets. It’s trusted multis bridges with synthetics that are the problem. Ellie Davidson  (Nov 5, 2025, 9:24 AM) Solvers do not expose users to risk. Noah’s iPhone  (Nov 5, 2025, 9:30 AM) If you want to drop it to an hour you can use ZK proofs though. We have already seen some optimistic rollups switch and that lowers the cost of capital rather than these small rollups needing another council so would the cost of paying that additional council be greater than the cost to just switch to ZK proofs? Potuz this group is proposing is to add a new trust assumption to rollups: "51% of validators are honest". Which rollups currently do not have. FOCIL would not change this, FOCIL anyway relies on 51% honest validators. The difference that FOCIL makes is in the economic attack assumption karl  (Nov 5, 2025, 9:39 AM) Certainly anyone using a non-intent bridge would love this Noah’s iPhone  (Nov 5, 2025, 9:39 AM) Yeah my main concern is around the smaller chains and this basically makes them PoA. Also why now if it was possible in the past? Tadeo  (Nov 5, 2025, 9:38 AM) MM don't want to provide liquidity because of the 7 day period. Currently asset issuers are paying MM to provide it, with a 1 day period it might be possible for non subsidised MM in L2s donnoh | L2BEAT  (Nov 5, 2025, 9:40 AM) interactive makes a difference for the economic attack because the defender needs to split its budget across many tips Greg Markou  (Nov 5, 2025, 9:32 AM) Theoretically but - this race to the bottom on intents will probably not change much matt  (Nov 5, 2025, 9:40 AM) Not sure I agree. I think these 7 day wait times impose a hard limit on how efficient directional flow can get (once subsidies are gone).Fundamentally, if there are net outflows from a chain, somebody must have funds locked in the canonical bridge and that capital costs something. Paul Dowman  (Nov 5, 2025, 9:41 AM) If it is a 51% attack that we want to protect against then it probably should be a lot more than 7 days. Ellie Davidson  (Nov 5, 2025, 9:42 AM) But it’s about the effect of the 7 days. The argument is not about what security properties L2s should ideally have—it is about that the current security properties are actually decreasing the security for users because they use trusted bridges instead. Lumi | Offchain Labs  (Nov 5, 2025, 9:43 AM) @Ellie Davidson lowering settlement for stage 1, may dissuade stage 2 because the regression on the product side Ellie Davidson  (Nov 5, 2025, 9:45 AM) This was mentioned in the OG post, but the idea is that optimistic rollups should move towards 2/3 or ZK rollups to move to stage 2. But I worry that that is a bigger burden than we are giving it credit for. ZK proving is expensive. Jacob l Boundless  (Nov 5, 2025, 9:48 AM) Today it is already the case, maybe it is more beneficial to make Stage 1 better while the tech for Stage 2 becomes more accessible to all Ellie Davidson  (Nov 5, 2025, 9:49 AM) My personal view is that we should go all in on 2/3 proving. That is the best end goal. If some stage 0 L2s want to trial this, I’d be open to that, but we shouldn’t lose focus on 2/3 proving. And I think we’re close to that from a technical standpoint! matt  (Nov 5, 2025, 9:39 AM) Yes, exactly. You can basically think of the canonical bridge being forced to handle the net transfer of funds, not each transfer. The more directional flows are, the more your costs converge to the cost of the canonical bridge. Orest Tarasiuk (t1)  (Nov 5, 2025, 9:41 AM) Yeah - so if you’re big (binance) then you stand a higher chance of NOT having to rebalance—and would thus benefit from a delay reduction less than smaller players matt  (Nov 5, 2025, 9:44 AM) It’s an interesting question. It might be the opposite. Smaller players offload their net flows to larger players (i.e. solvers offload their net flows to binance or Across LPs). So it may end up being Binance that gets hurt the most, since they are left holding the bag with large net directional flow to rebalance. Now Binance may have a large enough balance sheet on each chain s.t. they don’t care, but in theory their capital also costs something. matt  (Nov 5, 2025, 9:50 AM) Agree, I don’t think you can say it’s 7x cheaper to the user. I think it mostly depends on what percentage of the flow is netted vs directional. 100% netted, this makes no difference. 0% netted, it’s 7x cheaper. Binance only supports very large chains. This is a much larger problem on chains where there isn’t an entity like Binance that has a balance sheet so large that capital costs don’t matter to them. Ellie Davidson  (Nov 5, 2025, 9:50 AM) There are economic incentives to work out for rollups upgrading to 2/3 from optimistic proofs, but I still think that is the best outcome. brendanfarmer  (Nov 5, 2025, 9:28 AM) Does it matter if end users change behavior to use the canonical bridge? Isn’t the advantage for solvers sufficient? Ellie Davidson  (Nov 5, 2025, 9:30 AM) The goal is to get more users to not use trusted bridges. If solvers can now serve more users because of this, that is great, because solvers are not trusted. But if it doesn’t change the number of users using trusted bridges, then what are we gaining? Yes capital efficiency is good, but I don’t think that is the goal we have here. brendanfarmer  (Nov 5, 2025, 9:46 AM) Hmm, I had understood that the claim was that reducing the withdrawal delay was primarily for capital efficiency / reducing inventory risk. I think that there is an appreciable improvement for liquidity providers in moving from 7 days to 1 day - I think it’s easy to model this. But for the end user, I think the calculation is different - there’s a max delay that a user will accept, otherwise skipping the delay justifies increased bridge risk, so 7d -> 1d doesn’t matter as much as it does for LPs. Ellie Davidson  (Nov 5, 2025, 9:48 AM) The idea is that if it is better for LPs, then they will lower fees, which will make more users use them, which is great because liquidity bridges are not trusted for end users. So capital efficiency plays a role, but only if we are confident it will change user behaviors. 🙂 brendanfarmer  (Nov 5, 2025, 9:50 AM) Oh sorry I misread, that makes sense; I thought the claim was that we want users to use the canonical brigde. karl  (Nov 5, 2025, 9:55 AM) Btw I say "small chains" but this would have a major impact even for OP Mainnet Nam (Hyperlane)  (Nov 5, 2025, 9:54 AM) it's clear that it doesn't make sense to have the same standard apply to big vs. small chains Anika  (Nov 5, 2025, 9:56 AM) @Ellie Davidson on the Base side, we'd like to get to a 2/3 asap, just need to gain enough confidence on the technology and migration path Potuz  (Nov 5, 2025, 9:57 AM) the security council also needs the budget for the attacks you're describing Potuz  (Nov 5, 2025, 9:58 AM) if FOCIL doesn't get in we have some mitigations, not as good as FOCIL but still allow us to make the assumption on minority vanilla