Highlights of Ethereum's All Core Devs Meeting (ACDC) #157

The All Core Devs (ACDC) Call 157 captured Ethereum’s post-Pectra momentum as contributors reflected on the fork’s successful deployment and turned attention toward shaping the roadmap ahead. Discussions spanned the stability of Fusaka Devnets, a proposal to restructure ACD calls for clearer fork planning, and ecosystem-wide efforts to improve stakeholder inclusion.

• Pectra Updates
• Fusaka Devnet Updates
• Reconfiguration Proposal for ACD Calls
• Community Participation & Stakeholder Involvement
• Challenges in the EIP Process

Pectra Updates

The discussion on Pectra began with a tone of celebration and appreciation. Their were no critical bugs surfaced during activation, the transition was smooth across all major clients such as Geth, Prysm, and Lighthouse, network stability remained intact, and community coordination ensured wide adoption.

Trent Van Epps shared that he had published the “Pectra Pages”—a collection of reflections from core contributors captured in the lead-up to the fork. These submissions are part of a broader Ethereum tradition to document and preserve developer sentiment, technical rationale, strategic decisions, and even anxieties experienced before major upgrades.

Trent emphasized the long-term value of these reflections.

• They not only offer insight into what people were thinking at the time but also serve as historical documents useful five years down the line to study how major forks were scoped and executed.
• This initiative helps promote institutional memory, transparency, and cross-generational learning within Ethereum’s development culture.

Contributors who missed the initial submission deadline still have the opportunity to add their thoughts, as the published post remains open for updates.

Paritosh Jayanthi mentioned that post-Pectra, they were conducting blob scaling analysis. Pectra introduced an increase in the number of data blobs—likely related to EIP-4844, also known as proto-danksharding.

• These blobs are used to store large data payloads more efficiently, especially benefiting Layer 2 rollups.
• The increase in blob count directly impacts network performance characteristics such as bandwidth consumption, disk space requirements, and synchronization times.

The ongoing analysis is intended to assess these impacts through concrete performance metrics and user/client feedback. The community is awaiting the outcomes of this review to guide future technical decisions, particularly those related to upcoming forks like Fusaka and Glamsterdam.

Fusaka Devnet Updates

The first part of the Fusaka discussion centered around PeerDAS Devnet 7, launched just a couple of days prior. According to updates shared during the call, devnet is mostly stable, and client teams are actively engaged. The primary technical focus of this Devnet is on enabling BPO support, which is crucial for efficient data handling in the consensus layer (CL).

Moving ahead, Fusaka Devnet 0 is the next major milestone in the fork’s development timeline. This Devnet is scheduled to launch around 26th May and represents the first environment where both the execution layer (EL) and consensus layer (CL) features will be tested together.

• On the CL side, Fusaka Devnet 0 will build directly upon the stability and features of PeerDAS Devnet 7.
• On the EL side, it will introduce the ModExp gas cost adjustment, which likely pertains to recalibrating the gas costs associated with specific EVM operations. This is part of Ethereum’s ongoing effort to make gas metering more fair and efficient.

The most significant part of this Devnet will be its unified BPO testing, meaning both layers will be assessed simultaneously with BPO functionality fully integrated.

Another crucial feature that came up was Validator Custody, which is expected to be part of Fusaka's consensus layer roadmap. However, there are growing concerns about timeline slippage. While the feature remains in the spec, it has unresolved issues and open threads that require further discussion.

At its core, Validator Custody refers to enhancing how Ethereum staking keys and validator credentials are managed. This can significantly improve security (e.g., reducing key leakage), enable modularity (such as external custody services), and streamline the user experience for stakers. However, due to the feature’s intricacy and dependency on other roadmap elements, delays here could affect Fusaka’s final scope or release date.

Reconfiguration Proposal for ACD Calls

Ethereum’s core development has traditionally used All Core Devs (ACD) calls, split between the Consensus Layer (CL) and Execution Layer (EL), to focus on the next imminent fork (e.g., Pectra, Fusaka). Tim Beiko proposed a major structural change to this setup:

• Dividing responsibilities so that ACDT (All Core Devs Testing) handles current fork implementation and urgent issues, while ACDE and ACDC focus on “fork+1” planning—such as Glamsterdam—allowing for earlier alignment and strategic foresight.
• The proposal also emphasizes using “idle” post-fork windows for scoping discussions, gathering community input earlier, comparing EIPs more thoroughly, and setting priorities well before engineering efforts begin.
• This reconfiguration aims to introduce a clearer planning cadence, improve transparency, and create space to evaluate long-running breakout streams and conduct early impact assessments.

However, several developers expressed concerns.

• Some, like Ansgar, felt that focusing on future forks too soon could distract from finalizing Fusaka.
• Others warned that dedicating weekly time to distant forks might lead to shallow or repetitive conversations.
• There were also disagreements on Tim’s 33% (current fork) and 66% (next fork) time allocation suggestion; some preferred a 50-50 split or heavier focus on the present.

Developers stressed the importance of flexibility, not rigid segmentation, to avoid diluting the execution rigor of active forks.

Tim clarified this shift is experimental, not dogmatic—it’s about replacing inefficiencies with intentional structure. If successful, this change could transform ACD into a forward-focused strategy hub while preserving ACDT as a high-efficiency execution channel, making Ethereum’s development process more deliberate, inclusive, and responsive to ecosystem needs.

Community Participation & Stakeholder Involvement

Marchhill proposed creating a more accessible platform—either a new forum or an upgrade to Ethereum Magicians—aimed at reducing friction for outside contributors. He highlighted the challenge many ecosystem participants face:

• Ethereum’s core dev calls are highly technical and time-consuming, while forums are dense and hard to navigate.

As a result, non-core stakeholders (like L2s, tooling teams, app developers) often miss the chance to contribute meaningful input until it’s too late in the process. The proposed platform would serve as a streamlined dashboard or portal where all current and upcoming hard fork proposals are displayed alongside team opinions, timelines, and discussion threads.

• It would provide structure, clarity, and guidance on how stakeholders can engage without requiring deep technical immersion.
• The portal could organize feedback by stakeholder type and allow public input on which EIPs should be prioritized.
• Such a platform could also provide summaries of client perspectives and progress status, functioning as a transparent window into Ethereum’s roadmap deliberations.

This idea complements broader goals of making Ethereum governance more participatory and inclusive.

While it wouldn’t replace ACD calls or forums, it would offer a more discoverable and friendly interface for ecosystem feedback. Developers largely agreed that Ethereum would benefit from improved coordination between core teams and peripheral builders.

Challenges in the EIP Process

A recurring issue is the so-called “last-mile” problem—EIPs often make it to implementation without thorough analysis of how they affect infrastructure providers, app developers, node operators, or end users. Small technical changes can have large unintended consequences when deployed across Ethereum’s vast and diverse ecosystem, which includes L2s, wallets, exchanges, and more.

Historically, the EIP process has relied on “champions” (typically the proposal authors) to not only write the spec and lead its development but also to judge its broader ecosystem impact. However, participants noted that this model is flawed—EIP authors may be too invested in shipping their proposal to objectively assess its potential downsides.

There was a strong suggestion to separate the role of the champion from that of an impact assessor, possibly creating new roles or working groups to conduct unbiased, ecosystem-wide reviews before an EIP is approved for inclusion.

Proposed by Tim Bieko

The successful rollout of Pectra has laid the foundation for deeper improvements through Fusaka, while the proposal to reconfigure ACD calls marks a shift toward more structured, forward-looking governance.

The push for a more accessible community feedback mechanism and a reassessment of how EIPs are evaluated shows Ethereum’s maturity in balancing innovation with operational accountability.

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