Ethereum core developers used ACDE #229 to transition Glamsterdam from a scoping exercise into a testing & validation phase, with attention shifting toward Devnet readiness, client optimizations & execution repricing. With major Glamsterdam scope decisions largely finalized, discussion centered on Devnet-2 readiness, execution layer optimizations & a new wave of proposals targeting mempools, transaction formats & post-quantum preparedness.

Rather than introducing large new protocol changes, the focus narrowed toward ensuring Ethereum can safely scale without embedding inefficiencies into the system.

• Housekeeping Updates
• Glamsterdam Updates
• New EIPs Introduced
• Hegota Updates

Housekeeping Updates

Three new breakout calls were introduced, each targeting a long-term pressure point for Ethereum.

1. One breakout call will focus on post-quantum transaction signatures, following growing concern that Ethereum’s reliance on ECDSA cannot be left unaddressed indefinitely.
2. Another will center on L1-zkEVM, reflecting continued interest in aligning Ethereum’s base layer with zero-knowledge execution models.
3. A third call will focus exclusively on Glamsterdam repricings, underscoring that execution pricing is now treated as a core design concern rather than a parameter tweak.

Ethereum has entered a phase where work is becoming more parallel, more technical & more execution-driven.

Glamsterdam Updates

Much of the discussion centered on Devnet-2, which is now scheduled to launch in early February. Client teams reported steady progress, with clarifications added to the Devnet documentation to reflect changes made during implementation.

Rather than focusing solely on EIP inclusion, Devnet-2 is being positioned as a measurement environment. Clients are being asked not only to support required features but also to expose feature flags that allow benchmarking with specific optimizations enabled or disabled.

This approach reflects a broader shift in Ethereum development. Instead of relying on theoretical performance assumptions, developers want empirical data before committing to higher gas limits or repricing execution costs.

Block-Level Access Lists (BALs) emerged as one of the most important technical pillars in the current Glamsterdam cycle. While BALs are already part of the agreed scope, the discussion made it clear that basic spec compliance is no longer considered sufficient.

Developers repeatedly emphasized that the real value of BALs lies in the optimizations they enable. Four optimizations were discussed in detail:

1. Parallel execution
2. Batch reads
3. Parallel state root calculation
4. Sync-related optimizations

Among these, batch reads stood out as the most critical unknown. While parallel execution offers predictable performance gains, batch reads directly affect how efficiently clients can handle state access, which is expected to become the dominant bottleneck as throughput increases.

Several client teams reported having already implemented three of the four optimizations, with benchmarking expected to begin shortly. Sync optimizations were treated as more client-specific, but the broader message was consistent: clients that do not implement the core optimizations will struggle to keep up once execution limits increase.

Although no formal rule was adopted, developers broadly agreed that parallel execution, batch reads & parallel state root calculation should be treated as implicit fork readiness requirements.

The discussion on Glamsterdam repricings highlighted why execution pricing cannot be adjusted in isolation. Repricing compute, reads & writes requires a clear understanding of how execution behaves once optimizations are in place.

Without that baseline, repricing risks over-penalizing state access or underestimating achievable throughput. Developers stressed that repricing based on unoptimized clients would lock Ethereum into conservative assumptions that no longer reflect technical reality.

As a result, the repricing effort is explicitly tied to having a stable set of client optimizations available for benchmarking. Timeline pressure was also acknowledged. To allow sufficient testing ahead of interoperability events later in the year, core optimizations need to be in place by the end of February.

Wallet UX was briefly discussed as well. While users will continue to see a single gas field, state-heavy transactions may become more expensive under new pricing models.

Communicating these changes without confusing users remains an open challenge. As attention turns toward future Devnets, developers raised the question of how to prioritize additional work.

The emerging consensus favors deepening execution readiness before adding more EIPs. BAL optimizations were repeatedly cited as higher priority than introducing new protocol changes in the next Devnet iteration.

Some proposals, such as increasing the maximum contract size, were discussed not as feature upgrades but as stress tests to evaluate worst-case execution scenarios. Similarly, the possibility of temporarily raising gas limits in Devnet-2 was framed as an experiment rather than a commitment.

Several EIPs that do not directly change protocol rules sparked detailed discussion about scope & governance.

1. EIP-7610, which proposes reverting contract creation if storage is non-empty, proved particularly contentious. While some clients already enforce similar behavior, others raised concerns about performance overhead & long-term compatibility with future state models. Given the lack of unanimous client agreement, developers opted to keep the proposal under consideration rather than enshrining it as canonical behavior.
2. Two other proposals, EIP-7872 (max blob flag for local builders) & EIP-7949 (genesis file format), were broadly supported in principle but explicitly scoped out of fork-level commitments. Developers agreed that command-line flags & configuration formats should not be dictated by protocol governance, even if standardization remains desirable.