Agenda
- Glamsterdam
- devnet updates?
- Sepolia upgrade
- incident response
- Hegotá
- continue scoping
- mascot
- Other
Meeting Time: Thursday, October 01, 2026 at 14:00 UTC (90 minutes)
Meeting Time: Thursday, October 01, 2026 at 14:00 UTC (90 minutes)
This was ACDC meeting #188 focused on discussing the Sepolia fork to Amsterdam and scoping EIPs for the Hagotah upgrade. The team confirmed that Sepolia will fork to Amsterdam on October 6 at 1:53 PM UTC, with Barnabas reporting they are preparing a Sepolia Shadow Fork to test everything before the actual fork. The meeting covered incident response planning, with Will introduced as communication coordinator and discussions about naming coordinators for DevOps, testing, and security roles. For Hagotah scoping, the team reviewed several EIPs including withdrawals of EIPs 8333 and 8363, discussed quick slots (EIP 18198) with Barnabé presenting the case for reducing slot times from 12 to 10 seconds, and heard concerns from Matt and Frederick about potential delays to post-quantum transition work. The team also discussed top-up sync (EIP 8379) with Dustin presenting the proposal but facing concerns from EL teams about losing control over sync processes, and briefly touched on optional execution proofs (EIP 8025) before running out of time. The conversation ended with decisions to CFI quick slots and DFI the top-up sync EIP, while deferring further discussion on execution proofs and the CL block retention window EIP to the next meeting.
The meeting focused on the upcoming Sepolia fork to Amsterdam scheduled for October 6 at 1:53 PM UTC. Barnabas reported that a Sepolia Shadow Fork was being prepared and would likely be launched within the next hour to ensure everything works as expected before the main fork. The team discussed the Incident Response Plan document in the PM repo, which outlines procedures in case issues arise during protocol upgrades. There was also a discussion about potentially scheduling the Hoodie fork around October 26-27, just before DEF CON, though this was not yet finalized.
The team discussed coordinator assignments for the Sepolia testnet, with Parithosh and Barnabas nominated as DevOps coordinators, Justin Traglia and Mario Vega as Testing coordinators, and Nikos as Security coordinator. Will introduced himself as the new communication coordinator and noted that coordinator assignments should be documented in the PM repository. The team also reviewed updates on EIP withdrawals, including EIP-8333 being withdrawn due to concerns about decoupled consensus, and discussed EIP-7716 which has been updated and merged. Ryan provided feedback supporting quick slots inclusion in the upcoming fork to reduce future slot times.
The meeting focused on reviewing and updating several EIPs for the Hagota upgrade. The team decided to withdraw EIPs 8333 and 8363, and moved forward with EIP 8365, which NC presented with a modified structure keeping the deposit guard part while making the forced exit part a standalone EIP for a future fork. The group also discussed EIP 8411 but decided to hold it for later consideration due to late submission and pending client feedback. Barnabé then began presenting on QuickSlots, highlighting its potential benefits including faster confirmation times, better markets, and increased censorship resistance, though the presentation was cut off at the end of the transcript.
Barnabé presented the progress on the QuickSlots proposal, targeting a 10-second slot time for Regota, with specs merged and a prototype implementation ongoing. The team conducted outreach after analyzing the source code base and found positive impressions from key ecosystem teams like Lido and Offchain EFI regarding the potential changes. Justin expressed opposition to implementing QuickSlots in Hegota, arguing it should wait until after the post-quantum transition, while Matthew agreed that focusing on PQ safety and decoupled consensus should be prioritized, though he noted the technical feasibility of adding slot time adjustment machinery.
The team discussed implementing quick slots with a potential reduction from 12 seconds to 10 seconds, weighing the benefits against potential delays to the PQ (post-quantum) transition timeline. Barnabé expressed confidence that the work would not significantly impact the PQ timeline, while Fredrik raised concerns about prioritizing post-quantum security improvements over quick slots implementation. The group considered whether to bundle this work with decoupled consensus and explored the possibility of time-boxing the quick slots work to minimize impact on other priorities.
The team discussed transitioning from 12 to 10 slot times in the protocol, with Barnabé and others confirming that while the technical implementation isn’t complex, significant work is required to audit approximately 100 smart contracts affected by this change. Barnabé argued against delaying the work out of fear of post-quantum requirements, suggesting they should proceed with improving the protocol and potentially revert if needed later. Matthew expressed concern about the pressure to continuously reduce slot times once implemented, particularly due to economic benefits and cross-chain arbitrage opportunities.
The team discussed reducing slot times from 12 to 10 seconds, with Matthew expressing concerns about the arbitrary nature of the 10-second target and the need for proper testing, particularly given upcoming changes to the consensus protocol. Barnabé noted that concerns around proving time and zkVM performance were key factors in the decision-making process, while Terence from the Prism team supported the proposal, citing its importance for faster execution and broadcast capabilities. The discussion highlighted the need for further testing and consideration of the broader implications before implementing the change.
The team discussed implementing quick slots (EIP 8379) and reached consensus to proceed with CFI (Community Funding Interest) rather than SFI (Standard Funding Interest) today. While some concerns were raised about CPU performance and implementation complexity, the majority of participants agreed to move forward with the CFI decision, with implementation being considered straightforward across different clients. The team acknowledged the need for additional validation of performance metrics before proceeding to SFI, particularly regarding the change from 12 to 10 slots.
Dustin presented on top-up sync, explaining how it would allow consensus layers (CLs) to drive synchronization on execution layers (ELs) by distinguishing between different types of blocks and enabling backfill capabilities. He outlined four main benefits including improved resilience, reduced duplicate gossip traffic, enhanced flexibility, and better storage deduplication between CLs and ELs. The discussion revealed concerns from Łukasz about losing control over the sync process, though Dustin clarified that the proposal only adds an informational endpoint for ELs and doesn’t remove any control from them. The conversation also touched on efficiency concerns, with Francesco questioning whether the approach would leverage ELs’ parallelized syncing capabilities effectively.
The team discussed an EIP proposal for implementing an alternative sync mechanism between CL and EL, with Dustin explaining it would be optional and not replace existing snap sync methods. Łukasz raised concerns about efficiency and loss of control, while Enrico emphasized the need to clearly define responsibilities between CL and EL rather than maintaining multiple possible approaches. The group debated whether to proceed with the optional approach or wait for clearer direction on long-term responsibilities between the components.
The team discussed several EIPs during their meeting, with the main focus on an optional proposal for engine API tweaks to reduce duplication between gos-sip and storage systems. While some support existed for the proposal, particularly from Cayman who viewed it as a minor API tweak, the group ultimately decided to defer this EIP and others requiring more detailed discussion to the next meeting due to time constraints. The team also briefly touched on EIP 383 regarding CL block retention window and EIP 8025 about optional execution proofs, but these were deferred for further discussion in future sessions.
KD?Wyt9+)KD?Wyt9+)KD?Wyt9+)YouTube Stream Links: