Ethereum’s All Core Developers Consensus (ACDC) Call #168 brought together client teams to lock in Fusaka’s mainnet timeline and shift attention toward Glamsterdam’s EIP planning. Key takeaways included smooth progress on Sepolia BPO2, more realistic validator data from Hoodi, and a small bug that was quickly patched and added to the regression test suite.

Teams also agreed to submit writften inputs within two weeks to help finalize Glamsterdam’s consensus-layer scope.

Fusaka Updates

Sepolia BPO2 ran smoothly with no major issues. Hoodi provided a more realistic validator distribution, offering better insights into mainnet readiness.

There was a small drop in participation on Hoodi, attributed mainly to operator side issues rather than the protocol itself. A minor bug surfaced during the process, but the teams quickly patched it and coordinated with testing to add an explicit regression test.

Following Barnabé’s process document, proposed mainnet dates were structured as follows: public release on November 3, mainnet fork on December 3, BPO1 on December 9, and BPO2 on January 7 of the next year. These dates had broad support across ACDC and ACDE discussions. This ensures that future network runs will include coverage for that scenario, which was previously missed due to test design limits.

Glamsterdam Updates

With Fusaka finalized, the group transitioned to planning the Glamsterdam upgrade. The Meta-EIP list revealed a large number of PFI-eligible proposals, most affecting the Execution Layer (EL).

Several proposals were still pending in pull requests at the submission deadline; however, these can still be included if merged promptly. The chair emphasized that this call was not for decisions but for alignment.

  1. EIP 7688 SSZ EAP (Stable Containers): This proposal 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, causing maintenance overhead.
  2. EIP 8045 Exclude slashed validators from proposer shuffling: This proposal 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.
  3. EIP 8061 Increase churn limits (entries, exits & consolidations): This proposal addresses addresses congestion in Ethereum's deposit and exit queues by tripling the global churn limit, enabling faster validator set consolidation and improving staking liquidity.
  4. EIP 8062 introduces a small fee on “sweep” withdrawals, making compounding validators economically more appealing. It corrects the imbalance where skimming validators could benefit slightly more due to free partial withdrawals.

Fork-choice enforced Inclusion Lists (FOCIL) is a cross layer upgrade intended to preserve Ethereum’s scalability trajectory while maintaining censorship resistance and decentralization. It has wide community support but raises a timing question, whether to include it in Glamsterdam or defer it to the next fork.

Including it now capitalizes on current alignment and favorable governance conditions, while deferring protects Glamsterdam timelines and avoids additional complexity. Technically it is nearing interop readiness, but the decision hinges more on scope management and release discipline than raw engineering effort.

In Ethereum’s fork governance pipeline, “CFI” (Considered for Inclusion) means an item is approved for the fork’s scope but not yet being actively tested, while “SFI” (Scheduled for Inclusion) means it is now part of live devnet testing. Keeping this separation ensures discipline and prevents overload.

The movement from CFI to SFI happens incrementally as Devnet capacity allows, avoiding chaos from multiple half tested changes. For Glamsterdam, the next ACDC call will finalize the CL side CFI set while maintaining ePBS as SFI.

H-Star Successor Naming

The next fork after H Star has been officially named HEKA, paired with Bogotá on the execution layer side. This naming follows community discussions on Ethereum Magicians, where other variants such as Heka + Bogotá = Hektá and Helvetios + Bogotá = Heltá were also considered.

Finalizing names early helps streamline documentation, client pipelines and communication. Teams can now tag codebases, CI scripts and dashboards consistently under the HEKA/Bogotá identifiers. The community also discussed mascot ideas for Glamsterdam, highlighting how shared branding enhances engagement and clarity in a global ecosystem.

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

Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, & analysis related to blockchain technology & cryptocurrencies, is not intended as financial or investment advice. The website & its content should not be relied upon for making financial decisions. Read full disclaimer & privacy policy.

For Press Releases, project updates & guest posts publishing with us, email contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Share if you like the content. Donate at avarch.eth.

You've something to share with the blockchain community, join us on Discord!

Follow us on Twitter, Facebook, LinkedIn & Instagram.