This meeting was ACDT number 97 on September 21st, 2026, focusing on DevNet updates and technical discussions regarding block serving windows. PK provided updates on DevNet 8 stabilization and testing, while Spencer discussed plans for organizing future DevNets for the fossil and frame EIPs, suggesting separate initial testing before combining them. The main technical discussion centered on whether to reduce the CL block retention period from 33,024 epochs to match changes in EIP-8061, with participants debating the storage optimization benefits and implementation considerations across different clients. The meeting also covered upcoming testnet timelines, with Sepolia scheduled for October 6th and Gothenburg (Glamstam) tentatively planned for October 27th, and included discussions about benchmarking approaches for EIP-7870 testing.
Click to expand detailed summary
The meeting began with participants joining and greetings being exchanged. The host, danceratopz, welcomed everyone and introduced the agenda for ACDT #97, which included a DevNet update, discussions on Windows block serving, and a testnet quick check. No specific decisions or action items were mentioned in the provided transcript segment.
PK provided updates on DevNet, reporting that Stepford 8 has been stabilized with all clients back to head, though two open scenarios affecting Bezu remain, including a jump test and an attack that occurred on Thursday morning. The team plans to rerun these tests today or tomorrow to verify network stability. Regarding DevNet 11, testing has been finalized with Optimism and Lido approving the shutdown, while primary testing should continue on Stepford 8. The discussion then shifted to the CL serving window, where Jihoon raised questions about whether to adjust the current 33,024 epoch value following changes in EIP-8061, with options to either keep the current number, reduce it to around 14K, or further reduce it to 8K as proposed in EIP-8383.
The team discussed reducing the block retention period for CL from 33,024 epochs to around 14,000 epochs, which could save approximately 144 gigabytes of storage space. Potuz questioned why this change was being considered for CL, noting it hadn’t been a user complaint, and suggested it should be discussed in ACD rather than ACDT. The discussion highlighted the need to align retention periods across both CL and EL systems, with Toni mentioning this plays into a larger effort to unify retention windows across different components.
The team discussed aligning the BAL retention period with the CL serving period to enable deduplication and improve storage efficiency. Toni explained that the current BAL retention window of 3,533 epochs was set to match the weak subjectivity period, allowing EL clients to catch up after going offline. Nico raised concerns about data duplication between EL and CL clients due to different retention strategies, suggesting a need to harmonize these approaches. Potuz highlighted the distinction between retaining data for state regeneration (when not finalizing) and making history available for archive nodes, indicating that these purposes may require different retention policies.
The team discussed data deduplication and pruning policies for non-finalized data across different systems. Nico raised concerns about Prism’s current pruning based on wall clock time, arguing it should only prune data older than the last finalized checkpoint. Potuz clarified that Prism doesn’t normally prune non-finalized data and only blinds everything when writing to storage. The group agreed to bring the topic of bowl retention period to the ACDE meeting for client input, as Toni suggested this might not be a significant issue for EL clients.
The team discussed the necessity of storing Beacon Blocks (BALs) during non-finalizing periods, with Marius and Toni confirming they are not needed for SnapSync. The group debated whether checkpoint sync is required for catching up after extended offline periods, with Nico arguing that checkpoint sync should not be forced if the last state is safe to sync from. Kevaundray proposed continuing the discussion asynchronously due to time constraints, and the conversation ended with updates about the upcoming Sepolia testnet launch on October 6th and the Hoodi event scheduled for October 27th with a go/no-go decision on October 8th.
The team discussed the scheduling of network parameters and testnet implementation, with confirmation that resolving these parameters would not block testnet development. They reviewed the status of the Sepolia repository pull request from Alex and announced plans to release a new stable test fixture for Amsterdam on Wednesday, which will bump the major version and transition from DevNet to testnet releases. The conversation ended with a preliminary discussion about organizing the DevNet schedule for EIP implementation, though specific details were not fully fleshed out.
The team discussed strategies to speed up the DevNet process and development cycle, focusing on aligning a plan once EIPs for Hagatar are CFI’d. They debated whether to maintain separate DevNets for CL and EL components or combine them earlier, particularly for fossil and frames. The group agreed that while CL-side testing could proceed with fossil alone, the EL side would require more complex interactions, including mempool considerations. The proposed plan involves starting with a frames-only DevNet in September, followed by a fossil and frames DevNet in October, targeting completion before DevCon.
The team discussed plans for devnet implementation, agreeing to start with separate Fossil and Frame devnets before moving to a combined devnet. They also addressed the withdrawal of EIP-8142 and the introduction of EIP-8411, with CL team ratings needed ahead of the next ACDC. In the EL breakout, they discussed updating BPO test schedules to be Amsterdam-based rather than Osaka-based, with the team agreeing to keep existing Osaka-based tests until after the Amsterdam fork. Ben raised a question about whether to test full nodes or attester nodes for EIP-7870 benchmarking, which will be further discussed in tomorrow’s dedicated call.