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

The All Core Devs Execution (ACDE) Call #223, held on October 23, 2025, focused on testing progress, proposal management, and repricing strategies across Ethereum’s upcoming upgrades. The session opened with key updates on the Fusaka testnet series, covering Sepolia, Hoodi, and Holesky transitions, followed by timeline discussions around mainnet activation.

Core developers also explored the newly introduced non-headliner EIP process for the Glamsterdam fork, aimed at improving coordination for non-major proposals. Additional agenda points included client-review deliverables, repricing and gas-precision plans, a presentation on EIP-8058 (Bytecode Duplication Optimization), and the removal of EIPs from the Proposed-for-Inclusion (PFI) list.

• Fusaka Updates
• Non-Headliner EIP Process Proposal (Glamsterdam)
• Client Review Deliverables & Coordination
• Repricing Topics & Gas-Precision Breakout Plan
• EIP-8058: Bytecode Duplication Optimization
• EIPs Removed from the Glamsterdam PFI List

Fusaka Updates

The call began with Barnabás Busa outlining the state of the Fusaka Devnet 3, which continues to perform smoothly with roughly 99 percent client participation after the latest Lighthouse image rollout resolved outstanding bugs. On the execution testing front, Sepolia BPO1 had activated two days prior with a configuration of 15 maximum blobs, marking a critical step in validating data availability under heavier blob throughput.

BPO2 was scheduled to follow about four days and nine hours later. The next stage moves to the Hoodi network, slated to receive the Fusaka upgrade in roughly five days, with BPO1 expected in two weeks and BPO2 in nineteen days.

Developers were reminded that all Hoodi validators must update their nodes ahead of activation to avoid missed attestations. Parallel to these rollouts, Barnabás confirmed that the long running Holesky testnet is being decommissioned, as participation has fallen to the low seventies and finalization instability has begun.

The network will be permanently shut down next Friday, and operators were urged to migrate their infrastructure to Sepolia or Hoodi without delay.

Following the testnet summary, Alex Stokes led a session on mainnet timeline confirmation, proposing to activate Fusaka mainnet on December 3 2025, with BPO1 and BPO2 targeted for December 9 2025 and January 7 2026. This schedule adjusts the earlier December 17 plan after client feedback that it conflicted with the holiday period.

Stokes noted that although the governance process normally finalizes dates only after a testnet, specifically Hoodi, has reached finality, early pre commitment improves predictability for client releases and community testing. He tentatively set November 3 2025 as the target for aligned client releases, roughly one month before the proposed mainnet epoch, and several consensus layer and execution layer teams confirmed the timeline looked feasible from their end.

The standing rule requires that all testnets upgrade before a mainnet date is declared, but a proposed update filed as GitHub PR 1780 would allow scheduling after just one successful testnet, expediting coordination. Still, most agreed that announcing dates early, while keeping them adjustable, enhances network predictability.

Non-Headliner EIP Process Proposal (Glamsterdam)

This part of the meeting introduced the non-headliner EIP process, a framework designed to manage proposals that are not central “headliners” of the upgrade but still contribute important technical or economic improvements. As highlighted by ansgar.eth & ralexstokes, this was the first time the mechanism was being applied in practice, making it an experimental step in Ethereum’s coordination evolution.

The timeline outlined in the call proposed a quick two-phase cadence. Within one week, authors must make their PFI intent explicit, signalling that their EIP is under consideration. Within two weeks, they should have both the EIP text & PFI metadata properly merged into the repository, including references in the Meta-EIP .

With about 31 EIPs already under review, ansgar.eth committed to reaching out to authors & researchers for comments & planned to circulate an aggregated feedback summary after this two-week window. In response, the coordinators clarified that once a pull request (PR) is submitted, editors can immediately assign an EIP number, & authors may reference that number in the Meta-EIP even before merging.

Moreover, if the PR is still pending, simply posting a clear intent comment in the ACDC issue would suffice to meet the symbolic “intent deadline.” In essence, this new governance model provides a flexible yet transparent pathway for less-prominent proposals to progress.

Client Review Deliverables & Coordination

For the Glamsterdam cycle, Execution Layer client teams carry the heavier load, so they must produce short yet insightful review deliverables. Each team will publish an opinion document capturing its stance on thematic clusters of EIPs such as repricing, gas model changes, or data structure updates without needing to vote on every single proposal.

These opinion docs are expected by the November 6 ACDE, ensuring there is enough time in November to reconcile positions and freeze the scope before final inclusion. On the Consensus Layer side, where only a handful of EIPs exist, teams are encouraged to submit views as well so that governance remains holistic.

All EIP champions are asked to remain readily available for follow ups during this period. Developers and reviewers will likely reach out with clarifications, and responsiveness is critical for maintaining momentum. The goal is to make the process workable for busy client teams and EIP authors while maintaining transparency.

Intent signals, fast feedback loops, and concise opinion summaries matter more than formality. Ultimately, the coordinated effort between EIP champions, editors, and client teams is designed to deliver a well scoped, community reviewed Glamsterdam fork that balances technical innovation with process discipline.

🧵ACDE #223 (Quick notes)
1/
Facilitated by @adietrichs
🔹Fusaka Testnet Updates by @barnabasbusa
- Fusaka Devnet 3 is still ongoing.
- Participation rate: ~99%, with every client team involved.
- The latest Lighthouse image has been rolled out, and all known bugs are addressed…

— Pooja Ranjan | ranjan.eth (@poojaranjan19) October 23, 2025

Repricing Topics & Gas-Precision Breakout Plan

Maria introduced a dedicated discussion on repricing & gas precision, noting that nearly a third of all Glamsterdam Proposed-for-Inclusion (PFI) EIPs involve cost-model adjustments. To manage this workload efficiently, she proposed organizing two breakout calls devoted entirely to repricing topics rather than mixing them into the regular All Core Devs Execution (ACDE) agenda.

The aim is to allow client & research developers to conduct deep technical dives, examine dependencies among proposals, and explore possible standardization paths for opcode repricing while leaving governance matters for the main ACDE meetings. Because so many of the 31 PFI EIPs relate to repricing compute, storage, or state-access costs, Maria emphasized that a single ACDE meeting would not provide sufficient time for comprehensive review.

The breakouts are intended to produce a holistic perspective across the entire repricing cluster, highlighting technical inter-relations and performance data before those findings are summarized back to the main call. This helps prevent fragmented decision-making and ensures that interdependent EIPs remain consistent in methodology and benchmarking.

Maria continued with a presentation addressing rounding errors in Ethereum’s current integer based gas accounting. When opcode costs are benchmarked, many yield fractional values for example, an operation might ideally cost 0.8 gas but since only whole numbers are permitted, it must be rounded up to 1.

Such rounding introduces systematic over charging that compounds across transactions. Her analysis estimated an average ≈ 4 % rounding error per block under standard anchors, suggesting that even small inaccuracies could distort pricing once fine grained repricing begins.

To mitigate this, she outlined two main solution families.

1. The first is a gas unit rebase, scaling all gas costs upward by a constant (for instance × 1 000). This simple numeric expansion would turn previously fractional numbers into integers and reduce the average rounding error, at the cost of adjusting block limit values, validator defaults, and tooling that assume current magnitudes.
2. The second is introducing a fractional internal counter “milligas” within the EVM. Here, all internal accounting would operate in milligas, then round back to whole gas at the end of execution. This method preserves user facing semantics (transaction gas limits, fees, and UX) while offering higher internal precision, though it adds implementation complexity inside clients and may affect refund calculations.

Client engineers shared differing perspectives. Erigon team argued that this represents a micro optimization, i.e., real costs vary greatly depending on hardware, architecture, and libraries, so sub gas precision may be less impactful than ensuring first order pricing accuracy.

Potuz added that benchmark anchors often assume two second block execution, but Glamsterdam’s longer 8 second slots (and future forks’ timing changes) could shift those assumptions, so any fixed anchor metrics should be revisited. The meeting acknowledged that all current benchmark data are preliminary; as clients mature and hardware testing widens, figures will evolve.

The priority now is surfacing open design questions and gathering comparative data rather than locking constants. In conclusion, there was no consensus on a single path.

EIP-8058: Bytecode Duplication Optimization

EIP-8058, presented by CPerezz19, introduces a way to make contract deployment more efficient by detecting when identical bytecode already exists onchain and skipping unnecessary storage charges. Under the current rules, every new deployment pays the full code-deposit gas even if the bytecode already lives elsewhere.

With the upcoming Glamsterdam fork expected to include several repricing EIPs that make deployments costlier, this optimization could substantially reduce redundant gas usage. The proposal relies on access lists.

A deployer may include in the access list an account that already holds the code hash of the bytecode being deployed. When the transaction executes, the client runs the init code, hashes the result, and compares it with the referenced hash.

If they match, the node skips charging the storage cost for writing the code again because the state does not actually grow. Within the same block, the first deployment always pays the full cost, while any later transaction deploying the same bytecode may receive the duplication discount.

Questions were raised about forward compatibility with future changes such as code chunking and Verkle trees. After discussion, the core developers agreed to add EIP-8058 to the Glamsterdam PFI (Proposed for Inclusion) list, and the pull request is now active in the EIPs repository.

EIPs Removed from the Glamsterdam PFI List

Two proposals were unanimously removed from the Glamsterdam PFI set to streamline the review workload.

1. The first, EIP-7667, lost its active champion, and the Zero-Knowledge team confirmed that Glamsterdam is not the right fork to carry it forward at this stage.
2. The second, EIP-6873, depends directly on Verkle tree changes that are planned for a later fork, so including it now would serve no immediate purpose.

Following these remarks, coordinators agreed that both EIPs would be formally deleted from the PFI list after the meeting, narrowing the active scope to proposals that are championed, implementable, and not blocked by upstream dependencies.

Each Execution-layer client team is expected to publish a short opinion document by the November 6 ACDE, summarizing which themes or proposals they support or question, so that November’s meetings can converge on final scope. Coordinators also signaled that they may repurpose an ACDC or ACDE call specifically for Execution-layer EIP review if the backlog demands it, while Consensus-layer participation remains lighter.

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