Highlights from the All Core Developers Execution (ACDE) Call #224

In ACDE #224, Ethereum core developers reviewed key milestones across ongoing & upcoming upgrades Fusaka, Glamsterdam, and H Star (Hogota). The session centered on testnet stability, client release readiness, EIP prioritization, and long term fork coordination.

Teams discussed next steps for mainnet activation, naming conventions for future upgrades, and repricing proposal structures. Together, these updates mark another coordinated step toward Ethereum’s evolving scalability, performance, & governance roadmap.

• Fusaka Updates
• H-Star Naming (“Hogota”)
• Glamsterdam Updates
• Miscellaneous Updates

Fusaka Updates

In ACDE #224, the discussion focused on Fusaka’s mainnet preparation, client release status, and remaining testnet validation. The detailed rollout is documented in the Fusaka mainnet plan on GitHub, while the official Ethereum blog announcement marks the public confirmation that client releases and timelines have entered the final phase.

Barnabas Busa reported that BPO 1 has been activated on Hoodi, and that BPO 2 is coming soon. Hoodi’s role is to replicate mainnet conditions, allowing client teams to monitor performance and identify implementation issues in realistic environments.

By the time of ACDE #224, all execution-layer clients had issued Fusaka-ready mainnet releases. The uniform readiness means node operators can begin upgrading confidently once the final mainnet block height is announced, as detailed in the mainnet plan document.

Testing on Hoodi surfaced several cross-client issues.

1. Nethermind encountered a minor bug now under investigation. Although not critical, it emphasizes why diversified client participation is crucial.
2. Prysm experienced a Fusaka-related issue on Hoodi; Manu confirmed it was fixed roughly 24 hours before the call, with a patched Prysm release expected Monday.
3. Lodestar, as noted by Matthew Keil, exhibited a separate bug detectable only due to Hoodi’s larger validator set. This confirmed the benefit of large-scale testnets before mainnet activation.

Drawing from Hoodi’s experience, MatthewK eil suggested formalizing a structured soak period between testnet and mainnet forks. The plan introduces a 30-day monitoring window after the Hoodi fork, giving developers time to uncover subtle issues under live conditions.

Following that, a 1–2 week window for client releases would allow patched versions to stabilize, leading into a final 30-day mainnet upgrade window for node operators and ecosystem tools to prepare. This deliberate pacing aims to reduce coordination stress and ensure that by the time the fork hits mainnet, all participating clients have absorbed real-world feedback.

Facilitator ansgar.eth polled teams on confidence levels, and consensus indicated strong alignment toward a mainnet activation target of 3 December 2025. Despite minor testnet bugs, quick resolutions and synchronized mainnet releases reinforced optimism that no major blockers remain.

The group decision reads: “Fusaka will proceed as planned.” Process refinements, such as the soak-period model, will be evaluated for subsequent forks but not applied retroactively here. Overall, Fusaka stands on schedule, with the ecosystem transitioning from testing to final rollout readiness.

H-Star Naming (“Hogota”)

“H-Star” or “H*” is the placeholder label for the next upgrade after Fusaka. Ethereum’s naming tradition assigns sequential letters to upcoming forks, e.g., Fusaka (F), now followed by H-series.

Establishing a name early streamlines internal documentation, cross-client communication, and public awareness once technical scoping begins. During ACDE #224, Alex Stokes proposed the name “Hogota.”

The suggestion received general support in the chat, indicating positive sentiment among client teams. However, no formal declaration was made during this session.

Naming conventions carry practical significance because once confirmed, every discussion, EIP tracking sheet, and coordination document can refer consistently to the same upcoming upgrade. Historically, such decisions are jointly recognized across calls to maintain coherence between execution and consensus releases.

All Core Devs – Execution (ACDE) #224 is Live!
📅 Nov 6, 2025 | 14:00 UTC

Agenda highlights:
🔹 Fusaka: testnet updates & mainnet rollout
🔹 Glamsterdam: H* naming & process update
🔹 STEEL: testing complexity & client positions
🔹 Repricing breakouts
🔹 DFI / CFI selections
🔹…

— Pooja Ranjan | ranjan.eth (@poojaranjan19) November 6, 2025

Glamsterdam Updates

While Fusaka is preparing for its mainnet rollout, discussions around Glamsterdam focus on aligning which Ethereum Improvement Proposals (EIPs) will define the upgrade. Facilitator ansgar.eth clarifies that this call’s purpose is to “do a temperature check” and capture each client’s preferences rather than finalize any decisions.

The emphasis is on repricing proposals, BAL inclusion, and cross-layer coordination that will later extend into upcoming All Core Devs (ACD) calls. The Nethermind team, represented by Łukasz Rozmej, shared that they have published a list of prioritized EIPs for Glamsterdam.

Their list is open to review, meaning that if an EIP is not currently included but other client teams provide strong justification, Nethermind is willing to revisit its inclusion. The team’s prioritization post can be found here.

Geth, led by Felix, has published a detailed ranking of all EIPs under consideration for the Glamsterdam upgrade. Their general philosophy is to ship a meaningful number of proposals rather than a minimal set.

The complete ranking list is available in this Ethereum Notes document. At this stage, repricing proposals remain under discussion, as Geth is still waiting on clarification about their implementation scope.

The team is, however, open to including more EIPs in the final fork, showing their intent to maintain a well-rounded, impactful upgrade. The Erigon team, represented by Andrew Ashikhmin, has created a structured evaluation where most EIPs are labeled simply as “yes” or “no.”

Reth, represented by Jen Paff, has also released its evaluation notes in this HackMD document. The team is open to another iteration of evaluation, signaling a willingness to refine priorities as discussions progress.

Their focus is on EIPs that enhance node performance & developer experience, aiming for technical improvements that make Ethereum nodes faster and more maintainable. Reth’s emphasis reflects its goal of supporting developer-centric, long-term maintainability in Glamsterdam’s roadmap.

Hyperledger Besu, with input from RoboCopsGoneMad, reported that they are working on five to six repricing EIPs, with their finalized list expected shortly after this call. The team agrees with Geth that repricing EIPs are relatively low-effort to implement and therefore a strong candidate category for inclusion in Glamsterdam.

Miscellaneous Updates

One of the most debated topics in this session was whether repricing EIPs should be handled as individual changes or as grouped bundles. Andrew Ashikhmin (Erigon) expressed a clear preference for keeping repricing EIPs separate, arguing that individual EIPs allow for cleaner review, easier reasoning, and reduced risk of introducing unintended interactions.

In contrast, Maria Inês Silva & RoboCopsGoneMad supported bundling repricing EIPs to minimize coordination overhead. Dragan Rakita took a middle stance, supporting individual proposals in principle but agreeing that logical grouping based on type such as calldata cost, storage access, or opcode repricing could simplify inclusion.

The next steps emphasize parallel progress across both execution and consensus layers. Over the following two weeks, client teams will continue individual decisions on EIPs through successive ACDE & ACDC meetings.

Specific FOCIL discussions will appear on both tracks to ensure synchronized development. This reflects Ethereum’s dual-layer governance model where no single layer finalizes an upgrade in isolation.

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