Ethereum’s All Core Developers Consensus (ACDC) Call #166 centered on the Fusaka rollout, with updates on devnets, the Holesky fork, and the upcoming $2M audit contest. Attention is also beginning to shift toward Glamsterdam, where ePBS and BALs remain under active development and debate.
Alongside upgrade progress, the call covered procedural refinements like EIP lifecycle updates and readiness documentation. These discussions reflect Ethereum’s dual focus on near-term stability for Fusaka and long-term scalability through Glamsterdam.
Fusaka Updates
Fusaka Devnet-3 has been actively used to stress test the network under adverse conditions. Developers deliberately triggered around two days of non-finality, after which the network was successfully healed and has been finalizing smoothly since then.
This experiment confirmed that clients and infrastructure are capable of recovering from non-finality events, an important resilience check before testnet and mainnet deployments. It also surfaced differences across clients when dealing with missed updates, CPU spikes, and payload timing under spam load.
The Holesky fork was activated on October 1, and while some turbulence was expected, the transition overall was successful. Initially, there was a noticeable drop in validator participation immediately after the fork.
This was traced to missed client updates, and once nodes were updated, participation rates returned close to pre-fork levels. Later in the day, another unexplained dip below 66% occurred, which eventually resolved itself without clear attribution.
Another observation was a significant drop in bandwidth usage (over 50%) among validating nodes immediately after the fork, which teams are still analyzing. Many validators run around 10,000 keys per beacon node on Holešky, and this concentration can exacerbate performance under spam conditions.
To test Fusaka before mainnet release, the Ethereum Foundation launched a $2 million audit contest. The contest is designed to incentivize security researchers and developers to identify bugs or vulnerabilities while fixes are still cheap to implement during the testnet
The Fusaka rollout follows a phased testnet activation schedule. Holešky fork activation took place on October 1 and is already live. Sepolia is scheduled to activate on October 14, while Hoodi is planned for October 28.
These progressive rollouts allow client teams and operators to validate changes step by step before a mainnet deployment. The earliest mainnet deployment for Fusaka is expected in December 2025, provided that all testnet activations are stable, regressions are resolved, and readiness checks are passed.
Glamsterdam Updates
With Fusaka testnets rolling out through October, core teams are beginning to re-allocate attention to Glamsterdam, the next major network upgrade. The idea is that once Fusaka achieves stability on testnets, engineering energy can flow back into the design, devnet planning, and specification hardening of Glamsterdam.
On the client readiness front, ePBS remains in active development. Teams are preparing for an epbs-devnet-0 launch and refining their test coverage.
Teku has passing tests on a development branch, while other clients like Prysm are also working on stabilizing their code. For BALs, execution-layer clients have begun wiring block-level access lists into their execution pipelines, with state backend differences being a central concern.
Consensus-spec releases already include ePBS test items, reflecting ongoing spec-level validation. One of the liveliest discussions within ePBS concerns whether trustless payments should remain bundled with payload separation or be split into a separate proposal.
Some developers argue that bundling adds unnecessary complexity and risks repeating governance deadlocks seen in previous proposals like EOF. Others emphasize that trustless payments provide on-chain verifiability, censorship-resistance, and a fairer block-building market.
The counterargument is that latency benefits are marginal because most builders and relays already co-locate, and off-protocol solutions like MEV-Boost remain attractive. Governance-wise, many feel ecosystem stakeholders such as staking pools and builders need to be deeply involved in this decision, not just core developers.
The inclusion process for non-headliner EIPs has been tied to the Fusaka mainnet schedule. This ensures developers have clarity and one last week to finalize their proposals before the window closes.
Miscellaneous Updates
For Glamsterdam-bound “Proposed-for-Inclusion” EIPs (PFIs), developers agreed on a new requirement that each proposal must specify a primary point of contact (POC). This ensures that communication lines are clear and helps reduce delays or confusion during coordination.
Earlier drafts used the term “champion,” but this was simplified to avoid overlaps with other EIP language. The update is considered a small but important logistical improvement.
During the call, editors highlighted the need to advance EIP-7870 through its lifecycle status. This proposal, which outlines minimum hardware requirements for running Ethereum clients, did not undergo any technical change; rather, the discussion focused on its status in the EIP process.
There were no objections, so the group aligned to move it forward in the lifecycle. This step was largely procedural and ensures proper referencing in future discussions.
A central readiness checklist is being compiled in the project management repository to track Fusaka and Glamsterdam preparedness. The checklist outlines critical checkpoints, test milestones, and network readiness criteria.
This document initially began as a working Google Doc but is now being formalized and cleaned up to provide clarity. While most content will matter closer to mainnet activation, having the structure in place early helps align all client teams.
The inclusion of non-headliner EIPs for Glamsterdam will be tied to the call where Fusaka mainnet dates are decided. This effectively means that once the Fusaka mainnet decision is set, developers will have roughly one more week to finalize any additional EIPs for inclusion.
Looking beyond Glamsterdam, the next fork currently referred to as “H-star” requires a formal name. Developers discussed using a poll on the Fellowship of Ethereum Magicians forum as an informal signaling mechanism to guide the choice.
With Sepolia scheduled for eventual retirement, discussions have also begun around selecting a replacement testnet name. Contributors were directed to the Ethereum Magicians forum to propose and debate naming options.
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
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!
