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

Ethereum core developers gathered for ACDC #164 to focus on the Fusaka upgrade’s progress and its critical next steps. The discussion centered around Devnet-3 bug fixes and syncing issues, alongside preparations for the upcoming Devnet-5. Developers also revisited the protocol upgrade process and testnet timelines, balancing safety with faster cadence. Finally, updates on the Glamsterdam upgrade highlighted its dependency on Fusaka’s mainnet release.

• Fusaka Devnet-3 Updates
• Fusaka Devnet-5 Launch Plans
• Protocol Upgrade Process & Testnet Timelines
• Glamsterdam Updates

Fusaka Devnet-3 Updates

Devnet-3 has been the active proving ground for the Fusaka upgrade, where developers intentionally run rounds of finality and induced non-finality to test consensus stability, sync reliability, and bug recovery across multiple Ethereum clients. This network has surfaced a range of issues, with Barnabás Busa compiling a consolidated bug tracker that aggregates reports from different client teams.

Client teams have been steadily progressing with fixes. Lighthouse reported that a major bug was resolved in its Unstable branch, while Teku continues to address RPC-related issues.

Other clients such as Prysm, Lodestar, and Nimbus were part of the bug reports summarized in Barnabás’s document, with some of those issues now resolved. Marcin highlighted a contract failure linked to the Modex gas-cost increase under Fusaka testing.

In the immediate next steps, client teams are expected to work through the shared bug list, and re-run Devnet-3 at high participation levels. Success in this stage will determine readiness for scaling up to the next phase, Devnet-5.

Fusaka Devnet-5 Launch Plans

The shift from Devnet-3 to Devnet-5 depends on two clear readiness gates.

• First, all client teams must have their branches updated with Fusaka features and fixes. This milestone ensures that coordinated testing is being done on stable, up-to-date codebases.
• Second, Devnet-3 itself must demonstrate health by achieving close to 100% validator participation and successfully handling a finality → non-finality test without new critical failures.

Only after these conditions are met will it be appropriate to move forward. Devnet-5 is expected to significantly scale testing, targeting around 1,500 nodes.

This expansion is critical because it exposes performance issues, synchronization bottlenecks, and block propagation behaviors that are not visible in smaller networks. It is being positioned as a larger devnet that can provide the confidence and data required before launching public testnets such as Holesky or Sepolia, and eventually preparing for mainnet deployment.

Teams have been encouraged to review Hive dashboards and failure reports to ensure all known issues are cleared before scaling up. Developers were also reminded that not all client teams will be able to cut stable releases simultaneously; readiness will vary, and staggered releases should be expected.

Despite optimism, the meeting chair emphasized that it is still premature to set hard calendar dates for Fusaka’s progression. Until Devnet-3 achieves stability and Devnet-5 is successfully launched, schedule discussions would lack practical meaning.

Protocol Upgrade Process & Testnet Timelines

With the Fusaka upgrade, this process is under scrutiny because the traditional scheduling model may not fit the accelerated cadence developers are aiming for. The original process document, outlined in protocol-upgrade.md, set expectations that there would be - a minimum of thirty days between a client release and the first testnet fork

• another thirty days between the last testnet fork and the mainnet fork,
• at least two weeks between individual testnets such as Holesky, Sepolia, and Hoodi.

It also assumed that all clients would merge their fixes to master before the first testnet launch. Lightclient added that while speed is important, the Ethereum ecosystem cannot simply compress the schedule too aggressively, because L2s, infrastructure providers, and staking services rely on predictable timelines to prepare for forks.

In response, Tim Beiko submitted PR #1715, which proposed a series of refinements. His adjustments included:

• decoupling testnet and mainnet forks so that multiple testnets can occur under one client release,
• reducing the buffer between client release and first testnet from thirty days to a minimum of fourteen, and
• compressing the gap between testnets from the traditional two weeks or more to a minimum of ten days (while still recommending closer to fourteen).

The thirty-day buffer before mainnet would remain unchanged. These proposals were tested with L2s, liquid staking token providers, and infrastructure operators, and the general sentiment was supportive.

The debate ultimately centers on the trade-off between safety and speed. More time between stages allows client teams and external providers to test thoroughly, while shorter gaps keep Ethereum agile and prevent delays in achieving the six-month cadence.

For Fusaka specifically, adopting Beiko’s refinements would allow Holesky deprecation and the Sepolia/Hoodi cycles to proceed more quickly, while still maintaining a full month buffer before mainnet. This balance provides flexibility to handle bugs without fully derailing the schedule.

Glamsterdam Updates

The Glamsterdam upgrade is closely tied to the successful rollout of Fusaka. Developers made it clear that the next steps for Glamsterdam, particularly the selection and testing of EIPs, depend on Fusaka reaching mainnet.

This sequencing avoids the risk of handling two major forks simultaneously. In effect, Fusaka acts as the gatekeeper milestone, and only once it is stabilized on mainnet can Glamsterdam candidates formally progress into testing phases.

While Glamsterdam’s adoption depends on Fusaka, preparation is still moving in parallel. Teams continue discussions, specifications, and prototyping of Glamsterdam EIPs so that they are ready to advance when Fusaka is finalized.

However, no testnet or devnet cycles for Glamsterdam will start until Fusaka has been released, which ensures development capacity is not split across two upgrades. If Fusaka experiences delays, Glamsterdam will also be delayed.

The longer Fusaka’s cycle takes, the greater the backlog of EIPs waiting for inclusion in Glamsterdam, which may complicate testing and integration. Developers may then face a choice between compressing Glamsterdam’s schedule or breaking Ethereum’s intended six-month fork cadence.

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