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

Ethereum’s All Core Developers Execution (ACDE) Call #222 focused on network readiness ahead of the Fusaka mainnet launch, highlighting smooth Sepolia shadow-fork performance & ongoing devnet progress. Scaling research led by Jochem Brouwer & Camille explored real-state benchmarking to pinpoint execution bottlenecks under realistic load.

Glamsterdam preparations also advanced, with BAL & ePBS nearing Devnet 0 integration and client interoperability improving across Besu, Geth, Nethermind & Erigon. The call further reviewed extensive repricing EIPs at harmonizing compute, memory & state costs.

• Fusaka Updates
• Scaling Updates
• Glamsterdam Updates
• Proposed EIPs for Glamsterdam (Non Headliners)
• Governance Updates

Fusaka Updates

ACDE #222 began with updates on the ongoing devnets and the recent Sepolia Shadow Fork launch. As mentioned during the call, the Sepolia shadow-fork was launched earlier on the same day and has been running smoothly without major issues so far.

A significant discussion point was raised around the BPO schedule and how it is represented in the network’s configuration files. Developers pointed out that adding named forks such as Amsterdam, Istanbul, or Bangkok into the genesis.json makes configuration generation unnecessarily complex.

The suggestion was to remove redundant fork fields (e.g., “Osaka” or “Amsterdam”) from the blob schedule, since they introduce unnecessary layers that provide no functional change to the consensus layer. However, others argued in favor of retaining explicit configuration definitions to prevent confusion for node operators and developers.

Removing named forks could make it difficult to identify which blob schedule applies to which upgrade if explicit naming conventions are lost. The opposing view emphasized the importance of clarity and expressiveness in client configurations, instead of forcing users to infer previous values.

The Holešky testnet is currently one of the most active environments for validating Fusaka configurations. The call confirmed that BPO1 went live two days prior to the meeting.

A peer-to-peer connection issue detected on the Lighthouse client during the BPO boundary is being triaged, with a patch expected in an upcoming release.

The same problem did not appear in earlier devnets that had higher resource allocations. Teams are now investigating the potential for optimizing computational performance during high-load blob reconstructions.

The official schedule for the testnet rollouts remains as follows:

• Holešky: October 1
• Sepolia: October 14
• Hoodi: October 28
• Mainnet: Targeted for December (earliest)

Scaling Updates

The initiative aims to understand state access patterns, client bottlenecks, and execution-layer scalability in preparation for major upgrades like Fusaka and Glamsterdam. Jochem and Camille are building a tool that runs execution specification tests against live mainnet state snapshots.

This method ensures that benchmarks consider real factors such as state size, storage expansion, and database layout. The broader vision is to detect a slow block on mainnet, isolate it, and replay the same block over the captured state to see if the slowdown can be reproduced.

A key data source for this effort is the PandaOps “slow blocks” dashboard, which aggregates real-world performance data from validators and client teams. The dashboard currently provides detailed consensus-layer client information but lacks visibility into execution-layer client usage.

Participants agreed that this line of research should continue as an ongoing scaling initiative. Jochem plans to refine the benchmarking harness, expand testing to include hardware-controlled comparisons, and integrate missing client-type telemetry.

He invited developers to join the project through Discord or Telegram and contribute to the test framework and data validation. These results will play a key role in shaping future discussions on EIP repricing, gas-limit increases, and execution-layer optimization strategies.

This research is significant because it uncovers non-deterministic performance factors that synthetic benchmarks often overlook. If slow blocks cannot be replicated using isolated replays, the underlying issues likely stem from network dynamics or node-level concurrency.

Glamsterdam Updates

After a recent breakout call, developers reported that most clients are now very close to achieving full compatibility. The BAL (Block-level Access Lists) test suite has also seen significant growth.

Initially comprising around 26 tests, it has now expanded to nearly 54 tests, which, when including variations, amount to 154 distinct scenarios. Most client teams are passing approximately 80% of these tests, with only a single common test failing across three major clients.

On the consensus layer side, the ePBS (EIP 7732) track continues to move quickly. Developers confirmed that an ePBS breakout session is scheduled for the day following this meeting, where topics such as unconditional payments and whether these features should be split into separate EIPs will be discussed.

This coordination ensures both consensus and execution layer teams are aligned before the Glamsterdam Devnet 0 launch. Notably, contributors commended the teams for having achieved substantial progress on Glamsterdam even before the Fusaka mainnet rollout.

The collaborative testing effort ensures that upcoming Devnet 0 and Devnet 1 launches will proceed with well validated feature sets, including ePBS integration and execution layer test coverage. No new blocking issues were reported beyond the existing authority tracking PR and the Hive integration fix for Besu.

Proposed EIPs for Glamsterdam (Non Headliners)

Maria began with a detailed overview of EVM repricing goals, highlighting the urgent need to harmonize opcode costs as Ethereum scales. Currently, operations consuming similar resources are priced differently, creating performance bottlenecks and limiting scaling potential.

When gas limits increase, persistent resources such as state and history expand faster than desired, threatening node efficiency. The repricing work aims to rebalance compute and storage costs to keep the network sustainable.

These initiatives are grouped under the informational EIP 8007, which serves as an index of repricing proposals for the Amsterdam and Glamsterdam upgrades. It is not a bundled proposal; each EIP is evaluated and adopted on its own merit.

Among compute and memory repricing proposals, EIP 7904 seeks to align compute opcode prices with real benchmark results, reducing most costs except for a few pre compiles. EIP 7667 updates hashing operation costs to support future ZK VM use cases and is synchronized with EIP 7904 to maintain consistency.

EIP 7923 replaces quadratic memory growth with a paged model that introduces modern memory management and improves compiler efficiency. These proposals collectively make compute and memory usage more predictable and scalable.

For state related repricing, EIP 8032 introduces depth based pricing for SSTORE to discourage oversized and deeply nested contracts. EIP 8037 raises state creation costs roughly tenfold and meters deposit components separately to slow uncontrolled state expansion.

EIP 8038 further revises state access costs by updating the constants in SLOAD and SSTORE operations while remaining compatible with 8032. Together these updates promote efficient storage usage and fair cost distribution.

For data and calldata management, EIP 7981 introduces a base floor for access list costs, while EIP 7976 increases calldata costs. Maria emphasized the importance of linking these values to a consistent gas limit baseline to avoid introducing new mispricing imbalances.

She also mentioned two accounting oriented EIPs. EIP 2780 reduces intrinsic gas per transaction but adds a fee when ETH transfers create new accounts.

EIP 7778 removes refunds from block limit accounting, preventing inflated block scenarios while retaining refunds for individual transactions. Maria concluded that the next steps involve identifying any missing mispriced areas, benchmarking opcodes to finalize values, and analyzing backward compatibility risks, particularly those affecting state growth and storage heavy contracts.

Client teams will implement these repricing models, benchmark performance, and verify that new costs do not harm existing deployments. She clarified that EIP 2926 on code growth complements 8037 rather than competing with it.

Guillaume Ballet presented EIP 8032, a model designed to curb both global and per contract state growth by introducing depth aware pricing for SSTORE. Each account records the deepest point of its storage tree, and writes beyond a defined activation depth cost increasingly more gas, using an exponential formula.

Guillaume confirmed compatibility with unified state tree efforts. His PR is tracked at ethereum/EIPs #10453.

Charles Cooper then summarized several execution layer proposals. EIP 7907 and EIP 7903 lift the 24 KB contract size limit. 7907 was rejected during Fusaka discussions because it altered state assumptions, while 7903 focuses only on expanding init code size, making it less invasive.

EIP 5920 introduces a PAY opcode that allows ETH transfers to contracts without changing execution context, simplifying how protocols receive payments. EIP 7923 upgrades the memory model to a paged architecture, eliminating quadratic gas growth and supporting independent heap and stack allocations.

The most debated proposal was EIP 7791, or GAS to ETH, which enables direct on chain payments using gas as the accounting unit. The opcode transfers a specified gas amount converted into ETH from the transaction origin to a recipient address.

This simplifies micro payments within contracts, removing the need to pass message value through call chains. Because this gas represents a payment rather than computation, it is separated from the basefee burn mechanism through a distinct GAS to ETH budget.

Governance Updates

The upcoming Glamsterdam upgrade discussions confirm that the repricing and non-headliner EIPs will not be treated as a single bundled proposal. Instead, each EIP will move through its own evaluation track.

Ethereum client teams and contributors agreed that a dedicated priorities discussion will take place during the next All Core Devs Execution (ACDE) call, expected around October 23, 2025.

This session will determine how much room the upgrade has for various categories such as repricing, execution-layer optimizations, and feature additions. Based on that scope, each client team will prepare and submit its own shortlist of preferred EIPs to advance.

Once the Fusaka mainnet activation date is officially set, a final one-week window will open for the submission of non-headliner EIPs for inclusion in the Glamsterdam upgrade. This ensures that late-breaking but stable proposals can still be considered without delaying the broader release schedule.

Two open community discussions are also highlighted for broader participation.

1. The first concerns selecting a “H star” name for the next upgrade after Glamsterdam, encouraging creative suggestions from Ethereum contributors and community members. The discussion thread is hosted on Ethereum Magicians: H-star name thread.
2. The second discussion revolves around identifying a new testnet name to replace Sepolia, reflecting Ethereum’s evolving multi-testnet structure and decentralization goals. Suggestions for the replacement are being gathered in this Ethereum Magicians thread: Sepolia replacement name thread.

Client teams must begin assembling their EIP shortlists, focusing on technical readiness and alignment with upgrade objectives. They should also continue testing interoperability for Block-level Access Lists (BALs) and ePBS (EIP 7732) to provide data-driven insights for governance decisions.

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