Highlights from the All Core Developers Consensus (ACDC) Call #173
ACDC #173 covered Fusaka cleanup, steady progress on Glamsterdam’s ePBS work, & early steps toward selecting headliner proposals for the Hegota upgrade.
ACDC #173 was framed around three parallel threads, each at a very different stage of Ethereum’s upgrade cycle. The call moved from Fusaka, where the focus is on housekeeping and closing out long running EIPs, into Glamsterdam, which is grappling with the real complexity of ePBS and cautious Devnet planning, and finally to Hegota, where attention has shifted to early signaling and headliner proposal selection.
Together, these discussions reflected a broader effort to bring clarity, discipline, and realism to how upgrades progress from cleanup, to construction, to early exploration.
Fusaka Updates
Fusaka updates focused on housekeeping rather than new execution or consensus features. The primary objective was to finalize EIP statuses and close out proposals that have already completed their technical review cycle.
As highlighted by Pooja Ranjan, this is a friendly reminder to authors of blocked Fusaka EIPs. Team would appreciate support in reviewing and addressing the remaining open PRs for the following EIPs:
If any PRs should be closed instead of merged, kindly leave a comment so the process can move forward accordingly. Once these items are resolved, the corresponding EIPs can be progressed to Final status.
Completing this cleanup is important to avoid governance ambiguity and to ensure a clear transition into upcoming forks.
Glamsterdam Updates
At the heart of Glamsterdam is enshrined Proposer Builder Separation (ePBS), which is shaping up to be one of the more demanding consensus changes Ethereum has worked on since the Merge. The goal is straightforward in principle, i.e., separate who proposes a block from who builds it.
In practice, that separation is meant to ease centralization pressure, make MEV handling more robust, and preserve validator neutrality at the protocol level. Client teams are already deep into implementation, and one thing is obvious from the updates so far, i.e., this is not a small change.
ePBS cuts across several critical parts of the consensus stack, including fork choice, block validation, execution payload handling, and even some underlying networking assumptions. That breadth is exactly why progress has been steady rather than fast.
To keep things manageable, the specs for Devnet 0 have now been frozen. This gives clients a stable target to work against before introducing further changes.
Later Devnets will build on this cautiously, with time set aside for testing infrastructure, Kurtosis runs, and cross client compatibility checks before anything moves closer to mainnet. In parallel, Block Access Lists (BALs) are moving along well.
BALs aim to make execution more predictable by explicitly declaring which parts of state a block will touch, improving efficiency and reducing surprises during execution. That said, while BALs are further along than ePBS, developers have been clear that execution layer only forks should be treated as a fallback, not a default plan.
Shipping pieces in isolation risks creating coordination problems and technical debt that are hard to unwind later. A broader theme coming out of these discussions is a move away from rigid expectations like two forks per year.
Instead, attention has shifted toward milestone driven progress, with a strong internal focus on getting ePBS DevNet 0 out by late February and reassessing scope based on how things look then. Overall, the emphasis is less on hitting calendar dates and more on doing the work safely, with realistic timelines that match the complexity of what is being built.
Author
Yash Kamal Chaturvedi is a Blockchain Content & Ops Specialist at Avarch LLC, writing on Ethereum & governance since 2021. Covers ACD/ACDE calls, EIPs, upgrades, staking, security & ecosystem trends.
