Highlights from the All Core Developers Consensus (ACDC) Call #158

The All Core Devs Consensus (ACDC) Call 158 focused on finalizing key decisions for the Fusaka upgrade, aligning timelines for Devnet 1, and opening early planning for the upcoming Glamsterdam fork.

With Fusaka Devnet 0 live and BPO rollout underway, discussions centered around SFI for EIP-7917, validator custody complexity, and optimal signaling mechanisms for network coordination. The call also introduced headliner proposals like ePBS and FOCIL for Glamsterdam.

• Fusaka Devnet 0 Updates
• EIP-7917 Status
• Fusaka Devnet 1 Planning
• Glamsterdam Fork – Initial Planning
• Headliners for Glamsterdam Fork

Fusaka Devnet 0 Updates

The Fusaka Devnet 0 was activated at epoch 256, with a phased rollout of BPO scheduled to follow. Each BPO was set to go live 256 epochs after initial activation, allowing a one-day observation window to monitor for any client-specific issues.

This cautious approach ensured that any instability—such as missed blocks or peer connectivity failures—could be addressed promptly without compromising the integrity of the network. While some clients did experience occasional block misses and peer connection issues, the core functionality of BPO worked as intended.

These incidents were isolated and are being actively investigated. Importantly, a miscommunication around the block count removal in the full flow was corrected.

It was clarified that blocks 6 and 9 would still be used within the consensus fork (CF) flow, and an additional block schedule was added accordingly to maintain compatibility. All relevant updates, including the revised block scheduling, were implemented and deployed before the full launch of Devnet 0.

EIP-7917 Status

Core developers also discussed whether to include EIP-7917 in the upcoming Fusaka upgrade. EIP-7917 aims to enhance the Ethereum blockchain's security and performance by introducing a deterministic proposer_lookahead field in the Beacon State.

This field will store the proposer schedule for the upcoming epochs, calculated at the start of each epoch, addressing the issue of non-determinism in the current proposer schedule. This improvement simplifies the implementation of preconfirmation protocols and enhances the network's overall security and efficiency.

Client teams including Lighthouse, Lodestar, Teku, and Prysm confirmed that implementing the change would be simple and would not delay the fork. With no objections, the group agreed to move forward with EIP-7917, targeting DevNet 1 on June 9th.

Fusaka Devnet 1 Planning

The discussion around the upcoming PeerDAS focused on finalizing specs before Devnet 1. A key debate was whether changes related to BPO should be treated as full protocol forks with a new fork version or handled through lighter updates like modifying the fork digest and adding signals to the ENR.

Most teams preferred the simpler fork digest approach, as it avoids heavy coordination and testing overhead. Another topic was the validator custody mechanism.

The current design dynamically adjusts custody responsibilities based on stake levels, but this has proven difficult to implement. Some contributors suggested simplifying it—possibly by making custody updates less frequent or tied to fixed thresholds (like every 32 ETH)—to reduce complexity without sacrificing functionality.

Since key contributors on this topic weren’t present, the team decided to continue this discussion asynchronously. With Fusaka Devnet 0 successfully deployed, the core devs turned their attention to preparing for Devnet 1. The team confirmed that EIP-7917 would be included, and efforts are now focused on refining specs and ensuring stability.

The consensus was that Devnet 1 should build incrementally on Devnet 0, without introducing disruptive changes, to maintain development momentum.

ACDC #158 is Live!

Join the stream to follow the latest discussions on:
🔹 Fusaka & devnet updates
🔹 EIP-7917 (SFI) decision
🔹 PeerDAS, BPO, Validator Custody
🔹 ePBS (EIP-7732), FOCIL (EIP-7805)
🔹 Fork focus & community input

📺 YouTube: https://t.co/34EuZXGQxc
🔴 Live on…

— Pooja Ranjan | ranjan.eth (@poojaranjan19) May 29, 2025

Glamsterdam Fork – Initial Planning

Core devs debated what the core focus of Glamsterdam should be—whether scaling, user experience (UX), or censorship resistance (CR). While no decisions were made, there was general support for prioritizing scaling due to its strategic importance for Ethereum's roadmap.

A new meeting structure was introduced where current forks (like PeerDAS) are discussed in testing calls, while Fork+1 topics (such as Glamsterdam) are handled in ACDC calls.

This allows deeper, forward-looking discussions without affecting ongoing deployments. The framing suggested that the Ethereum community should adopt a more deliberate approach to defining each fork's mission and use it to guide EIP selection and scope decisions.

Headliners for Glamsterdam Fork

Core devs reviewed two major Consensus Layer (CL) proposals that are being considered as headliners for the Glamsterdam fork:

• EIP-7732 (ePBS): EIP 7732 proposes a significant change to Ethereum block validation by separating execution and consensus validation.

It introduces a "builder" role, who constructs execution payloads, and a "Payload Timeliness Committee" to attest to the timeliness of payload reveals. This decoupling improves block propagation and validation, reduces reorg likelihood, and removes the need for trusted middleware.

The proposal includes changes to consensus and fork choice logic, with security considerations and backwards compatibility discussed.

• EIP-7805 (FOCIL): Ethereum's censorship resistance is preserved by FOCIL, a mechanism that ensures timely transaction inclusion.

It assigns validators to build and gossip inclusion lists (ILs) based on their mempool views. Proposers and attesters monitor, store, and forward ILs, with attesters voting only for blocks including transactions from all stored ILs.

FOCIL resists bribing/extortion and improves transaction inclusion guarantees, addressing centralization in block production.

Previous forks sometimes lacked strong engagement from affected stakeholders, especially from app developers, L2 teams, stakers, and solo validators. To avoid that, the call introduced a more intentional scoping process, where input from specific ecosystem segments would inform whether an EIP is included and how it impacts real users.

A post-fork naming poll for the next upgrade (H-star) was shared, and participants were encouraged to vote.

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
6. Highlights of Ethereum's All Core Devs Meeting (ACDC) #150