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

Ethereum core developers continued refining the scope of the upcoming Glamsterdam network upgrade during ACDE #228, focusing on execution layer proposals that are technically mature enough for near-term inclusion while pushing higher-risk or less-understood changes into future forks.

Rather than expanding Glamsterdam’s ambition, the discussion reflected a clear shift toward containment, safety, & process discipline. Multiple proposals were deferred, several were marked as unlikely candidates, & only a small subset remains actively under consideration for final inclusion decisions.

• Glamsterdam Devnet-2 Scope Discussions
• Remaining Glamsterdam PFI Decisions

Glamsterdam Devnet-2 Scope Discussions

A major portion of the call centered on Glamsterdam Devnet-2 scope, where developers reviewed execution layer EIPs already under active testing or implementation.

• EIP- 7778: Block Gas Accounting without Refunds: One of the more technically dense discussions revolved around EIP-7778, which proposes changes to block gas accounting by removing refund mechanics. While conceptually straightforward, the proposal touches deeply embedded assumptions across client codebases.

Developers highlighted the difficulty of changing values such as cumulativeGasUsed & the distinctions between gas used for block limits versus gas used for payment accounting. As a result, no immediate decision was taken.

• EIP- 8024: Backward compatible SWAPN, DUPN, EXCHANGE: Opcode-level changes continue to be some of the hardest proposals to finalize, a reality reflected in the discussion of EIP-8024, which introduces backward-compatible versions of SWAPN, DUPN, & EXCHANGE.

While the proposal aims to improve EVM ergonomics, developers flagged underspecified behavior when bytecode ends before an immediate operand is fully consumed. Two competing approaches emerged:

1. A simplified semantics model, which would constrain edge cases more aggressively.
2. A no-change approach, relying on deeper jump destination analysis to preserve existing behavior.

Rather than forcing alignment, the group agreed to revisit the decision in ACDT, where execution-layer technical trade-offs can be evaluated with more depth & fewer time constraints.

• EIP- 7708: ETH transfers emit a log: By contrast, EIP-7708, which proposes emitting logs for ETH transfers, received relatively broad support in the room. Developers generally agreed the change is conceptually sound & improves observability without altering core execution semantics.

That said, open questions remain in the associated pull request, & the proposal remains formally pending. The group opted to revisit it again in ACDT before any final inclusion decision is made.

While EIP-7708 appears to be one of the stronger Glamsterdam candidates, it is still subject to final review rather than being fast-tracked.

• EIP- 7843: SLOTNUM opcode: EIP-7843, introducing a SLOTNUM opcode, was acknowledged as a small & well-defined change. However, concerns were raised about the cross-layer coordination overhead required to support it, especially given its relatively low urgency.

Instead, the discussion was moved asynchronously to a pull request review, allowing client teams to reason through edge cases without forcing a rushed consensus during the call.

ACDE #228 - Quick recap 🧵@adietrichs facilitated the meeting

🔷Glamsterdam Devnet-2 Scope

🔹EIP-7778 : Block Gas Accounting without Refunds
- https://t.co/p4X9bwRUF8
- Clarifications on CumulativeGasUsed, - gasUsedForPaying, gasUsedForBlockLimit
- Andrew acknowledged this as… https://t.co/9ClVgpZbyu

— Pooja Ranjan | ranjan.eth (@poojaranjan19) January 15, 2026

Remaining Glamsterdam PFI Decisions

As Glamsterdam moves closer to finalization, the remaining PFI (Proposed for Inclusion) decisions represent the last major filter between exploratory discussion & hard fork commitment.

• EIP-8037: State Creation Gas Cost Increase: This remains the most consequential unresolved decision for Glamsterdam. Proponents argue it is necessary to curb long-term state growth, with estimates suggesting unchecked expansion could approach ~1TB per year.

Critics counter that the proposal may be too aggressive or inelegant for a production fork, especially without extensive mainnet validation. Parameter adjustments were suggested as a compromise, but no consensus was reached. The final decision has been deferred to ACDT.

Several proposals were formally marked DFI (Deferred for Inclusion), signaling that Glamsterdam’s scope is now effectively constrained:

• EIP-7793: Conditional Transactions: EIP-7793 introduces conditional execution logic for transactions, allowing them to execute only if certain conditions are met. Conceptually, this opens the door to more expressive transaction flows & advanced use cases, especially for account abstraction.

Despite its potential, the proposal ran into a hard reality check. Client implementations were not sufficiently mature, & there was little confidence that all execution clients could safely ship it within the Glamsterdam timeline. During the discussion, sentiment in the room was clearly negative, with 7 explicit votes in chat favoring removal.

This was not about rejecting the idea itself, but about timing. Conditional transactions touch critical execution paths, & shipping them without broad client readiness was viewed as an unnecessary risk. Marked DFI, with a note to reconsider it for a future fork (H-Star), where more design & implementation work can happen without time pressure.

• EIP-5920: PAY Opcode: EIP-5920 proposes a new PAY opcode to simplify ETH transfers directly at the opcode level, potentially improving clarity & reducing boilerplate in contracts. The main issue here was not strong opposition, but rather lack of alignment.

Clients did not converge on a shared understanding of its value, semantics, or urgency. Without a clear champion or compelling use case that justified inclusion in Glamsterdam, momentum faded quickly.

In an upgrade cycle where scope discipline matters, proposals without clear consensus or pressing need are unlikely to survive. Marked DFI, effectively removing it from Glamsterdam without a defined path forward.

• EIP-8051: Precompile for ML-DSA Signature Verification: This EIP proposes adding a precompile for post-quantum signature verification, focusing primarily on ML-DSA (Dilithium). The motivation is future-proofing Ethereum against quantum threats, particularly for account abstraction & hardware wallets.

Technical context discussed

1. ML-DSA (Dilithium): NIST-standardized, ZK-friendly, ~2.4KB signatures, ~13M gas
2. FALCON: Smaller signatures (~666 bytes), cheaper (~6M gas), but far more complex & harder to support in hardware
3. SPHINCS+: Very large signatures (8–49KB), potentially better suited to the Consensus Layer

The takeaway was that ML-DSA is pragmatic today, but not without tradeoffs. Multiple red flags came up:

1. Risk of prematurely locking Ethereum into one cryptographic standard.
2. Long-term EVM maintenance burden.
3. The need for cryptographic agility, especially as post-quantum standards evolve.
4. Mixed client sentiment & lack of urgency for Glamsterdam.

This is a big, long-term decision that deserves focused discussion, not a rushed inclusion in a production fork. Marked DFI, with plans for a dedicated breakout discussion & possible reconsideration in H-Star.

• EIP-7971: Hard Limits for Transient Storage: EIP-7971 proposes explicit limits on transient storage usage to prevent abuse & ensure predictable resource consumption. Simply put, there was no new progress.

No updated benchmarks, no fresh client insights, & no urgency pushing it forward in the context of Glamsterdam. Without momentum or new data, there was little reason to keep it in scope. As a result, it was marked DFI.

• EIP-8032: Size-Based Storage Gas Pricing: This EIP introduces gas pricing that scales based on storage size, attempting to better reflect the long-term cost of state usage. Performance implications are still being evaluated, & there was no consensus that the model was ready for production.

Importantly, the proposal originated from reth-specific considerations, & maintainers were comfortable deferring it until analysis matures. As a result, it was marked DFI.

• EIP-7907: Meter Contract Code Size and Increase Limit: EIP-7907 introduces a more complex metering mechanism for contract code size, allowing the limit to increase while charging proportionally for the cost. Three options were considered:

1. Do nothing.
2. Apply a simple limit bump (EIP-7954)
3. Adopt full metering (7907)

Benchmarks were presented, but concerns remained about complexity. The simpler bump was seen as safer for Glamsterdam, with less implementation risk & fewer unknowns. As a result, EIP-7954 was marked CFI and EIP-7907 was marked DFI.

• EIP-7903: Remove Initcode Size Limit: This EIP removes limits on initcode size, potentially enabling more complex deployments. There was no strong push to include it, & concerns around abuse & downstream effects were not fully resolved.

With no urgency & unresolved risks, it did not fit Glamsterdam’s conservative scope. Explicitly marked DFI, with no near-term reconsideration planned.

Glamsterdam is shaping up to be less about how much Ethereum can squeeze into a single upgrade & more about how carefully it chooses what not to include. ACDE #228 reflected a clear preference for stability, client readiness, & long-term maintenance over ambitious but uncertain changes. While a few PFI decisions are still unresolved, the broader direction is already visible.

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