Highlights from the All Core Developers Consensus (ACDC) Call #162

At the All Core Developers Consensus (ACDC) Call #162, Ethereum client teams & researchers gathered to coordinate progress on the Fusaka upgrade and finalize near-term protocol goals. The call featured updates from Fusaka Devnet-3, launch plans for Devnet-4, and a detailed rollout strategy for blob capacity increases (BPO).

Developers reviewed client readiness for the September Holesky fork, debated testing completeness, and aligned on a phased path toward a November mainnet launch. The agenda also included proposals to enhance the Beacon API for blobs, a shift to slot timing via basis points, and Glamsterdam upgrade planning where ePBS was confirmed as SFI and FOCIL remained under active review.

• Fusaka Upgrade Updates
• BPO Planning
• Fusaka Timeline Review
• Non-Finality Testing
• Beacon API for Blobs
• Slot Timing Specification Changes
• Slot Propagation Metrics
• Glamsterdam Headliner Finalization
• Conclusion

Fusaka Devnet Progress

At the time of ACDC #162, Fusaka Devnet-3 was actively undergoing finality testing. The main goal of this devnet was to assess how different Ethereum clients behave under simulated failure conditions, such as node outages or supernode removal.

Testing was designed to include both scenarios with and without supernodes, and it successfully achieved 100% validator participation. We can track this activity via the Fusaka Devnet-3 Dashboard or observe a sample finality test slot.

Looking ahead, Devnet-4 was announced to go live the very next day (August 8, 2025). This devnet aims to replicate around 10% of Ethereum mainnet’s scale, with a focus on high-intensity, short-duration data gathering over a single day.

Its purpose is to test blob throughput, validator behavior, and client stability under elevated load. Such short-lived but scaled experiments will help optimize compression strategies and spot bugs early.

BPO Planning

To ensure Fusaka doesn’t overwhelm Ethereum’s infrastructure upon launch, developers have planned a phased BPO strategy. This gradual rollout of blob capacity allows the network to increase data availability while still giving clients and researchers room to observe, test, and adapt to performance or consensus issues.

According to Justin Traglia’s shared rollout schedule, each BPO stage increases the target number of blobs per block, with a mathematical formula ensuring a smooth transition, i.e., each new target equals the previous maximum, and the maximum is 1.5× the new target (rounded up). The BPO phases are structured as follows:

• Fusaka starts with a target of 6 blobs and a max of 9 at epoch 404480.
• BPO1 raises the target to 9 and the max to 14 at epoch 413952.
• Subsequent phases (BPO2 to BPO5) follow this exponential pattern, ultimately scaling to a max of 72 blobs.
• For example, BPO2 targets 14 blobs with a max of 21, and BPO3 targets 21 with a max of 32 at epoch 426752.

Fusaka Timeline Review

As Fusaka testing progresses, the Ethereum core developers are carefully analyzing whether the current timeline for mainnet release is feasible. Several concerns were raised around code readiness, client merge status, and the lack of a spec freeze, especially from Matthew Keil of Lodestar.

He emphasized that none of the current devnets include a version of the spec with all pending merges finalized. This complicates testing, since bugs related to integration may still emerge later.

He also noted that private mempool testing, which is critical for execution performance and MEV workflows, hasn’t been uniformly implemented across clients. To address these issues, Matthew proposed a 4-week delay in the Fusaka schedule to avoid premature deployments.

Responding to this, Parithosh Jayanthi clarified that private mempool testing is already taking place on Fusaka Devnet-3, referencing the same non-finality test slot shared earlier. He also floated the idea of forking the Holesky testnet using non-master branches, thereby enabling client teams to decouple their release cycles while continuing with real-world testnets.

This would prevent Holesky from becoming a “critical path” bottleneck in the Fusaka timeline. Client-specific feedback also revealed disparities in readiness. For example, Prysm acknowledged having significant volumes of unmerged code, whereas Teku confirmed it had already been running on master for some time.

Nimbus, however, expressed a preference against “testnet-only” releases built on non-trunk branches, due to internal policy and risk exposure. Despite these hurdles, there was agreement that scheduling Holesky for September was acceptable for most teams.

To mitigate testing risks, Barnabas Busa suggested launching Devnet-5 on September 2, running for one week to further validate final client code. As a backup plan, teams agreed that even after Holesky forks, a separate devnet could be spun up for post-fork testing.

Looking ahead, the tentative Fusaka timeline includes:

• September 1: Client releases for Holesky and Sepolia
• September 8: Start of bug bounty
• September 15 & 22: Holesky and Sepolia forks
• October 1 & 8: Mainnet client release and Hoodi fork
• November 5: Fusaka Mainnet Target

However, Justin Traglia cautioned that even a 1-month delay now could cascade into a 3-month delay due to the year-end holiday season. In response, Alex Stokes confirmed consensus among client teams like Prysm and Nimbus that the September timeline remains viable, especially if testing continues in parallel.

Non-Finality Testing

Non-finality testing is a critical part of Ethereum's pre-fork validation process, particularly for the upcoming Fusaka upgrade. These tests are designed to simulate scenarios where finality is not achieved, i.e., such as when a sufficient portion of validators go offline or participate erratically.

The purpose is to ensure that all consensus layer (CL) clients can handle such conditions gracefully, recover properly, and detect bugs that may only surface in unstable environments. The testing strategy, proposed by Nico Flaig, includes three key phases.

1. The first is simulating validator outages by taking down at least one instance of each CL client, pushing participation below the 66% threshold required for finality. This test has two variants, i.e., one that stops only full nodes and another that halts only supernodes. After holding this non-final state for one hour, the clients are restarted to assess their ability to rejoin and restore finality.
2. The second test throttles about 30% of the network by reducing their bandwidth to 1 Mbps. This creates a chaotic participation pattern, simulating degraded internet or partial network outages.
3. The third test is the most aggressive as it involves splitting the network into two independent chains and then merging them back, observing how the clients reconcile divergent state histories. To support this, developers are using Tyler’s Chaos Tool.

These tests are being run on Fusaka Devnet-3, with Lodestar syncing in preparation. A concrete example of such testing can be seen in Slot 106243, where non-finality behavior and recovery metrics were tracked.

All Core Devs – Consensus (ACDC) #162 is Live!
🗓 Aug 07, 2025 | 🕑 14:00 UTC

🎥 https://t.co/3ZW8VUWaS9
📺 https://t.co/tHZ2ISDokb

Agenda:
🔹 Fusaka devnet updates & mainnet schedule
🔹 BPO fork planning
🔹 Perfect PeerDAS, backfill, blob API
🔹 Glamsterdam prep & spec changes…

— Pooja Ranjan | ranjan.eth (@poojaranjan19) August 7, 2025

Beacon API for Blobs

As Ethereum prepares to scale data availability through proto-danksharding, devs are enhancing the Beacon API to accommodate blob-specific access. A new proposal, PR #546, introduces the getBlobs endpoint.

The motivation behind this endpoint is to decouple blob data access from other beacon node responsibilities, reducing the processing load and allowing blob consumers to fetch only what they need. The getBlobs endpoint would return blob content and possibly include metadata like KZG commitments or versioned hashes.

However, the exact response format and query filters remain open design questions. Developers are debating whether to query blobs by indices or versioned hashes, and whether the response should include full cryptographic commitments alongside the blob data.

Slot Timing Specification Changes

In the ongoing effort to improve flexibility in Ethereum's consensus specs, developers proposed PR #4476, which replaces hardcoded constants like SECONDS_PER_SLOT and INTERVALS_PER_SLOT with slot timing components defined in basis points. This change enables developers to simulate different slot durations and fine-tune time-sensitive operations like attestations or aggregations without recalculating low-level constants.

The proposal suggests deprecating SECONDS_PER_SLOT in favor of SLOT_DURATION_MS, which represents slot duration in milliseconds. Instead of defining component events (like attestation due time) using absolute values, the system would use percentage-based definitions via basis points.

For instance, if SLOT_DURATION_MS is set to 12,000 milliseconds (12 seconds), then a component defined as 7500 BPS would trigger at 9 seconds. This makes testing different slot times, i.e., like the proposed six-second slots in EIP-7782 much easier.

One of the key benefits of this proposal is that it decouples logic from timing, enabling flexible experimentation without major code rewrites. This is especially important as Ethereum explores upgrades like FOCIL and ePBS, which may introduce changes in how fast blocks propagate or how quickly attestations must be confirmed.

Slot Propagation Metrics

Ethereum’s network performance is deeply influenced by how quickly blocks and attestations propagate across the chain. During ACDC #162, Maria Inês Silva presented recent data that showcased notable improvements in propagation metrics, affirming that Ethereum is becoming faster and more reliable at the protocol layer.

One of the key highlights was that block propagation is now consistently occurring in under 1 second. This improvement is especially significant for minimizing missed attestations and improving validator responsiveness.

In tandem with this, the 95th percentile delay for attestations has improved from 2.52 seconds to 1.85 seconds, reflecting enhanced consistency in timely participation. This data was validated using reference tables provided by Sam Calder-Mason of EthPandaOps, whose contributions were acknowledged during the call.

These optimizations are important groundwork for upcoming upgrades such as Glamsterdam, especially as the network looks to support features like FOCIL and Six-Second Slots (EIP-7782), where tighter timing requirements will stress the system. Alex Stokes noted that these new figures "look better than last time," signaling developer confidence in the network’s readiness for upcoming forks.

Glamsterdam Headliner Finalization

Following weeks of stakeholder engagement and devnet testing, the ACDC #162 call served as a decision point for which features will headline the Glamsterdam upgrade and which will be postponed. These headliners were evaluated based on implementation readiness, test coverage, developer alignment, and ecosystem impact.

The concept of SFI was applied to EIP-7732 (ePBS), which was officially selected as the lead feature for Glamsterdam. ePBS is widely regarded as a critical step toward decentralizing block building and reducing proposer censorship.

Developers including Alex Stokes, Mark (ethDreamer.eth), and Terence supported its selection, citing maturity and independent implementability. Mark (ethDreamer.eth) also pointed out that ePBS and FOCIL share strong synergy, but agreed that ePBS is better suited as a standalone inclusion at this time.

In contrast, EIP-7805 (FOCIL) though praised for its long-term benefits was marked as CFI. As explored in the FOCIL slide deck and accompanying HackMD notes, FOCIL carries technical complexity across both the consensus and execution layers.

While the concept is highly attractive, developers felt it needed further testing and refinement. As a result, it remains a serious contender for the post-Glamsterdam roadmap, and future devnets will be crucial to elevating its status.

During the conversation, Tim Beiko proposed an intermediate strategy: proceed with SFI for ePBS and BALs, keep FOCIL as a CFI, and revisit its SFI candidacy once comparative benchmarks are clearer. This staged approach was generally agreed upon, allowing Ethereum to make progress without compromising stability or developer bandwidth.

Community input played a critical role in shaping Glamsterdam’s direction. Feedback was gathered from Ethereum Magicians and synthesized by Nixo into a detailed Notion report. This synthesis helped core developers gauge sentiment across the ecosystem regarding the technical and strategic merits of each proposed feature.

Execution layer features such as BALs and gas repricing mechanisms received broad support with relatively few objections. Some stakeholders, like ansgar.eth, voiced that EL improvements were simpler and more urgent to implement, while others, including Sophia Gold, emphasized that ePBS would improve execution throughput and thus CL upgrades were even more important for Glamsterdam.

Conclusion

At ACDC #162, several critical milestones for both the Fusaka and Glamsterdam upgrades were laid out, ensuring clients and testers have aligned targets. For Fusaka, the roadmap begins on September 1, 2025, when client releases for Holesky and Sepolia are expected.

This will be followed by the launch of a bug bounty program on September 8, aimed at catching late-stage issues. Two testnet forks, i.e., Holesky (September 15) and Sepolia (September 22), i.e., will provide live testbed conditions, leading to the mainnet client release on October 1.

The Hoodi fork, an intermediate staging fork, will occur on October 8, and finally, Fusaka will activate on mainnet on November 5, ahead of Devconnect. The Glamsterdam timeline, by contrast, is still in development.

With ePBS confirmed as SFI and FOCIL as CFI, the current focus is on writing finalized specs, validating implementation strategies, and synthesizing feedback. Much of the design discussion has been informed by the Notion summary of stakeholder feedback, which outlined clear community support for ePBS while recognizing FOCIL’s transformative potential.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

Related Articles

1. Highlights of Ethereum's All Core Devs Meeting (ACDC) #153
2. Highlights of Ethereum's All Core Devs Meeting (ACDE) #207
3. Highlights of Ethereum's All Core Devs Meeting (ACDC) #152
4. Highlights of Ethereum's All Core Devs Meeting (ACDE) #206
5. Highlights of Ethereum's All Core Devs Meeting (ACDE) #205