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

ACDC #170 came at a moment when the Ethereum community had a lot happening at the same time. Fusaka is almost ready to go live on mainnet, Glamsterdam is moving closer to being wrapped up, and conversations for Heka Bogotá have quietly started in the background.

For the developers on the call, it felt like working on three different timelines at once: finishing one upgrade, settling the next, and already thinking about what follows. The challenge now is to keep everything moving without compromising safety, validator comfort or the clarity of the upgrade process.

• Fusaka Updates
• Glamsterdam Updates
• FOCIL Debate
• EIPs Discussed
• Miscellaneous Updates

Fusaka Updates

Fusaka mainnet readiness was the first topic of the call. Client teams reported that Mainnet Shadow Fork 1 successfully ran both BPO stages, with BPO1 using fifteen max blobs and BPO2 using twenty one max blobs, and the network maintained almost one hundred percent participation for a full day.

Nimbus confirmed that version 25.11.0 performed well, and a corrective release for version 25.11.1 is being prepared to address a supernode bug found during testing. With no blockers and strong confidence from client teams, Fusaka is set for mainnet activation on December 3.

Nethermind is also planning a livestream for the launch. Developers revisited the structured incident response framework introduced during Pectra.

Each client team must submit designated responders, escalation paths, and communication channels to the Fusaka incident plan. Several teams have already submitted entries, while others were reminded to finalize them before launch.

Glamsterdam Updates

As the conversation moved past Fusaka, the focus naturally shifted to Glamsterdam and its main feature, ePBS. Prysm shared that most of its ePBS work is already passing tests and is almost ready to merge.

Teku has been steadily pushing major pieces into master, Lighthouse is making quiet but consistent progress, and Lodestar mentioned that it should be fully ready to participate in Devnet testing by January. With the pressure of Fusaka testing coming to an end, teams expect ePBS work to pick up speed.

The overall sentiment was that Glamsterdam’s Devnet phase is within reach. One area that still needs deeper discussion is trustless payments inside ePBS.

After Devconnect, it became clear that developers were not all viewing this mechanism the same way. Some had concerns about how it behaves in edge cases, others questioned the economic assumptions behind it, and a few simply felt the current design needed more clarity.

Because of this, a dedicated breakout session is now scheduled for December 5. Until that conversation happens and the group reaches shared understanding, Glamsterdam cannot fully lock in its ePBS scope.

FOCIL Debate

FOCIL was one of the topics that drew the most attention during the call. Since it helps reduce upload bandwidth for validators under ePBS, many in the community see it as especially important for home stakers.

A few people argued that pairing FOCIL with ePBS in Glamsterdam would be ideal, but others felt the fork is already carrying enough complexity and adding one more major feature might stretch risk too far. In the end, the group took a balanced route.

FOCIL is marked as DFI for Glamsterdam and CFI for Heka, and the final question of whether it deserves an SFI signal will be taken to the next ACDE meeting. This way, both the Execution Layer and Consensus Layer can weigh in before any strong commitment is made.

The back and forth around FOCIL also highlighted that the headliner process still needs refinement. It became clear that the current system leaves too much room for interpretation and pushes developers to compare unrelated proposals against each other.

Several contributors suggested a simpler approach for Heka. First, decide whether FOCIL should be a headliner. Then, once that is settled, choose any other major feature that should sit beside it, such as six second slots.

This two step method keeps discussions focused, reduces unnecessary friction, and supports better planning. An updated version of the process will be written up before the next ACDC.

EIPs Discussed

• EIP-7805 (FOCIL): It enhances Ethereum's censorship resistance by ensuring timely transaction inclusion, addressing centralization risks from builder dominance in block production.
• EIP-8071 (Consolidation Withdrawal Prevention): It addresses an unintended use of the consolidation queue to expedite withdrawals, which is being exploited to bypass the slower exit queue. This fix ensures the consolidation mechanism is used as intended, preventing abuse.
• EIP-8080 (Let exits use the consolidation queue): It addresses the unfair advantage in Ethereum's exit queue, where validators with ≥2048 ETH can exploit a loophole to expedite withdrawals via the consolidation queue. It democratizes this feature, allowing all validators to use the consolidation queue when it’s shorter than the exit queue, reducing congestion and improving fairness.
• EIP-8061 (Increase exit and consolidation churn): It addresses Ethereum's validator set management by doubling consolidation churn, quadrupling exit churn, and restoring exit churn's proportionality to total stake. It also routes exits through the consolidation queue when shorter, increasing exit throughput by 75%. This aims to accelerate validator set consolidation, reduce exit queue congestion, and improve staking liquidity.
• EIP-8062 (0x01 Sweep Fee): It introduces a fee on partial withdrawals for 0x01 validators to incentivize stake consolidation and reduce unaccounted protocol resource usage, supporting Ethereum's fast finality roadmap.
• EIP-8045 (Exclude slashed validators from proposing): It addresses the issue of slashed validators being selected as beacon chain proposers, which currently leads to missed slots and degraded network performance, especially during mass slashing events.
• EIP-7688 (Stable Containers): It addresses the issue of Ethereum's consensus data structures using SSZ Container, which lacks forward compatibility in merkleization schemes. This leads to verifier implementations needing updates with each fork, increasing maintenance overhead.

Glamsterdam’s overall shape is now much easier to see. FOCIL, 8071, and 8062 have all been removed from the fork. EIP 8045 is still on the table but only if its safety checks hold up.

The queue related proposals, 8061 and 8080, need one more round of review before the group can choose between them. And EIP 7688 will be decided in the next call once the champion walks everyone through its full complexity.

Miscellaneous Updates

The final boundaries of Glamsterdam will become clear after the December 5 ePBS breakout and once the ACDE meeting gives its signal on FOCIL. Over the coming days, developers will collect Execution Layer feedback on FOCIL, refine the headliner process for Heka, and take part in the dedicated ePBS breakout meeting.

Client teams will also double check proposer lookahead logic for EIP 8045 to ensure there are no hidden risks, and they will review EIP 7688 more closely ahead of the champion’s presentation. With all this information in hand, the next ACDC call should be able to lock down the complete Glamsterdam scope.

The final part of the call stepped back from immediate decisions and focused on long range improvement. Developers noted that if Ethereum wants to successfully maintain a two fork per year rhythm, the ecosystem needs stronger pipelining and earlier planning for follow up upgrades.

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