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

Ethereum core developers met on January 5 for an off-cycle All Core Devs Execution (ACDE #227) call, kicking off the year with a familiar but increasingly urgent task of narrowing down what actually makes it into the Glamsterdam upgrade. While much of the discussion stayed focused on execution-layer scoping, the call also exposed a broader undercurrent of growing frustration around governance complexity, slow decision loops & process ambiguities that have built up across multiple upgrade cycles.

• Governance Updates
• Glamsterdam Updates

Governance Updates

Early in the call, members of the Ethereum Foundation’s protocol support team walked through a set of proposed changes aimed at making governance discussions easier to follow & better structured. A key part of that effort was the introduction of ACDG (All Core Devs – Governance), which would formalize & rebrand the long-running EIPIP meetings that have historically seen limited visibility & attendance.

The reasoning behind the proposal was straightforward. Governance conversations around editor discretion, EIP readiness, sequencing & coordination have become increasingly fragmented.

While execution, consensus & testing topics have well-defined All Core Devs forums, discussions about how decisions are actually made often lack a clear, widely followed home. With more than 350 open pull requests sitting in the EIP repository, participants acknowledged that process ambiguity is no longer a minor issue.

The intent behind ACDG is to provide a single, recognizable venue for governance-level discussions, improving visibility & alignment without adding another layer of bureaucracy to the upgrade process. Editors also pointed to smaller but practical process tweaks.

Glamsterdam Updates

Core developers repeatedly came back to the same goal throughout the call, which was to lock in the Glamsterdam’s Considered for Inclusion scope by the next ACDE. The emphasis was on timeboxing discussions that have already spilled across multiple meetings, with a growing recognition that unresolved debates can themselves become a delivery risk.

As a result, several proposals were reviewed with a clear bias toward deferral unless there was strong consensus and confidence in implementation. Developers noted that as forks continue to grow in size, prolonged indecision adds pressure to clients, testers, and coordination timelines in ways that are increasingly hard to absorb.

One of the first major technical topics was state growth and gas repricing, focused on better aligning state creation costs with present-day network realities. Although an updated draft proposal existed, participants agreed that the holiday period had slowed review across teams.

Rather than push through a decision with incomplete alignment, the group chose to revisit the issue at the next ACDE, where more time could be dedicated to the discussion. The decision reflected a broader pattern on the call, prioritizing confidence over speed when changes touch core economic assumptions.

Contract size limits quickly emerged as one of the most heavily debated issues. Ethereum’s current 24KB cap has long been a pain point for smart contract developers, forcing aggressive optimization and limiting composability.

Developers discussed two main paths forward.

1. One option would introduce a simple static increase, such as raising the limit to 32KB.
2. The other would involve deeper structural changes that explicitly account for code length and adjust gas costs accordingly.

While the more structural approach was seen as conceptually cleaner, it raised concerns around implementation complexity, data structure changes, and testing overhead. Some client teams warned against shipping partial fixes that could lock in suboptimal incentives, while others argued that leaving the limit unchanged was no longer defensible given years of developer feedback.

With no clear convergence, the group deferred the decision one final time, making it clear that unless meaningful progress is shown before the next call, the outcome would narrow to either a minimal increase or no change at all. The discussion then shifted to smaller EIPs that still raised important questions about scope discipline.

One such proposal focused on deterministic factory pre-deployment, which would ensure the existence of a known contract at a canonical address. Supporters described it as a low-risk usability improvement with clear benefits for tooling and Layer 2 ecosystems.

Skeptics, however, cautioned against incremental scope creep. After further debate, the proposal was moved into CFI status, keeping it under active consideration without fully committing it to the fork.

A separate proposal aimed at reducing gas costs through contract code deduplication received a more muted response. Although the idea offered potential UX gains, developers noted the absence of strong demand from contract authors and pointed to broader uncertainty around repricing efforts.

The proposal’s author ultimately requested its withdrawal, and the group agreed to defer it for a future upgrade where it could be evaluated alongside more comprehensive pricing changes. A similar outcome followed for a proposal to remove legacy bloom filters from receipts, which was deferred due to compatibility concerns and limited immediate benefit.

One of the more forward-looking discussions of the call centered on trustless log indexing, a proposal closely aligned with Ethereum’s longer-term direction toward statelessness and verifiable execution. Proponents argued that it could unlock new use cases, including trustless receipt queries and improved cross-domain communication.

Critics countered that the proposal carried non-trivial consensus risk and would require deeper testing and coordination than the Glamsterdam timeline realistically allows. Despite broad interest in the concept, developers agreed that the timing was not right.

While Glamsterdam’s final feature set remains in flux, the call highlighted a broader shift toward clearer process, stricter timeboxing & more explicit coordination norms. As Ethereum continues to scale socially alongside its technology, the success of future upgrades may depend as much on governance clarity as on protocol innovation.

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