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

The recent All Core Developers Execution (ACDE) Call #216, held on July 17, 2025, focused on assessing Devnet-2’s stability & client-specific bug resolutions, locking in key protocol parameters for Devnet-3 under the Fusaka upgrade, & launching the initial framework for blob-throughput scaling discussions ahead of the Glamsterdam hard fork.

Alongside detailed client reports on Lighthouse, Lodestar, Nimbus & Prysm, participants agreed on a July 23 Devnet-3 target, defined PeerDAS testing workflows, & kicked off headliner selection timelines for both Execution & Consensus layers in Glamsterdam.

• Fusaka Updates
• Glamsterdam Updates

Fusaka Updates

Devnet-2 has been running stably for over two weeks, giving client teams confidence to proceed toward Devnet-3. However, several client-specific issues remain under investigation.

• Lighthouse nodes have experienced incorrect CGC-value suggestions & payload-flag failures, while Lodestar nodes have been banned by peers due to excessive polling.
• Nimbus clients have intermittently overloaded & crashed under heavy request volumes, & Prysm nodes have reported missing metadata fields along with an inverted blob-schedule ordering (with a PR fix pending).

These bugs are being tracked actively, & minor fixes such as the blob-schedule correction for Prysm are already in review.

Work on Devnet-3 is well underway, with a target launch date of July 23, 2025. Coordination notes & detailed spec updates are available in the the Fusaka Devnet-3 spec repo. Key protocol changes include the reduction of max-tx-size. An alternative to EIP-7907, namely EIP-7903 (init-code size bump), was discussed but deferred to Glamsterdam.

Participants emphasized the absence of a dedicated testing framework & benchmarks for PeerDAS. Before moving to Devnet-3, the community agreed to define clear performance benchmarks, stress-test parameters, & a standardized workflow for PeerDAS validation, ensuring interoperability across clients & avoiding last-minute surprises.

The proposal to meter contract-code size via EIP-7907 sparked a heated debate.

• Hyperledger Besu called for a spec freeze with no last-minute changes, Arbitrum suggested a +50% bump as a less intrusive path, & Giulio’s minimal bump (24 KB → 32 KB) received vocal support from ansgar.eth & Reth, who labeled it a “2-line change”.
• Marius VanDerWijden from Geth expressed low urgency given familiarity with the 24 KB limit, while Prysm, Teku, & Lodestar teams urged caution on last-minute complexity.

Ultimately, the group decided to remove EIP-7907 from Fusaka & revisit contract-size changes for Glamsterdam instead.

Fredrik laid out a standardized 30-day window process for Fusaka.

• 30 days between the client release & the first testnet;
• 30 days from the last testnet to mainnet;
• early opening of the bug bounty; &
• at least two successful testnets before mainnet deployment.

The canonical upgrade timeline per the Ethereum PM process is documented here. This cadence aims to balance rapid iteration with sufficient time for audit competitions & community feedback.

As an early stress-test path, several speakers proposed upgrading the existing Holesky testnet to Fusaka rather than waiting for Devnet-3. Given Holesky’s large consensus state, this would surface scalability & interoperability issues sooner, without affecting public mainnet users.

The primary recommendation for Fusaka is to remove EIP-7907 from the upgrade due to significant unresolved complexity and unacceptable timeline risk; while simpler alternatives such as EIP-7903 (a lightweight init-code size bump) were discussed, they were ultimately rejected to avoid further delays.

The team has also committed to launch Devnet-3 by July 23, 2025, with client teams expressing confidence in proceeding once the spec freeze is in place. Finally, the proposed timeline is tight for delivery before Devconnect (Nov 5–12), necessitating at least two successful testnets, early bug-bounty/audit competitions, and exploring a Holesky Testnet to provide high-stress testing without impacting public networks.

Glamsterdam Updates

The planning for the Glamsterdam upgrade revolves around selecting one primary headliner per layer {Execution Layer (EL) & Consensus Layer (CL)} and establishing timelines for additional EIPs. Core developers are targeting a clear roadmap to ensure focused implementation and avoid scope creep.

Core developers have narrowed down EL headliner candidates to three main proposals.

1. Block-Level Access Lists (BAL) are favored for their lightweight design and ability to provide fine-grained control over blob inclusion, making them an attractive, spec-lite option.
2. Gas Repricing is discussed alongside BAL, as adjusting gas costs between data and execution could unlock significant scaling headroom.
3. Meanwhile, FOCIL remains under consideration; although its broader scope touches both EL and CL, its complexity could challenge its viability as a standalone headliner.

On the CL side, the primary contenders are ePBS and FOCIL. ePBS has strong support for defining how CL clients build and validate EL payloads, though not unanimously. FOCIL garners interest for improving fork-choice logic, but some teams worry about overlapping responsibilities with ePBS.

Community and client perspectives can be found at the ForkCast write-up and in the Ethereum Magicians threads on Block-Level Access Lists and the case for EIP-7732 inclusion. Once headliners are finalized, a deadline for all other (non-headliner) EIPs will be set (tentatively after August 21) to prevent scope overload and maintain focus on execution.

Headliner picks from all client teams:

Execution Layer:
- Geth: EIP-7928 (Block-level Access Lists)
- Reth: EIP-7928 + EIP-7732 (ePBS) + EIP-7805 (FOCIL) stretch
- Erigon (both EL + CL): EIP-7928 + EIP-7805 + EIP-7782 (Reduce Block Latency)
- Nethermind: EIP-7928 + EIP-7732… https://t.co/7Ad0balzaD

— terence (@terencechain) July 17, 2025

The next steps involve continuing these headliner discussions on the upcoming ACDE calls scheduled for July 31 & August 14, with the goal of formally finalizing both the EL and CL headliners by August 21, 2025. This will allow client teams to begin focused implementation, benchmarking, and integration work without distraction.

Once EL and CL headliners are locked in by August 21, 2025, a deadline for all remaining “regular” Glamsterdam EIPs will be set, ensuring proper time for review and integration without overloading the upgrade scope. During this period, a “meta-EIP” process will track incoming proposals via GitHub PRs, allowing for continuous visibility until the final headliner decisions are cemented.

Strategically, teams are prioritizing the completion of Fusaka before allocating broader resources to additional Glamsterdam EIPs, thereby safeguarding the timely delivery of both upgrades.

The Next Steps include three priority tasks:

• first, to clearly define whether the Consensus Layer proposal FOCIL or ePBS will ship first in Glamsterdam;
• second, to identify and onboard key community contributors such as MEV builders, Layer 2 teams, and tooling developers to provide informed feedback on the selected headliners; and
• third, to flesh out detailed testnet requirements, benchmarking metrics, and audit and bug bounty timelines necessary to ensure Fusaka’s safe and timely rollout.

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