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

In ACDC 169, Ethereum core developers examined major milestones shaping the next phases of the network, focusing on Fusaka readiness, Glamsterdam planning, and the early direction of the H Star upgrade. The discussion centered on the health of testnets, progress on ePBS development, client alignment, and the evolving structure of BPO changes.

Teams also explored how to maintain a steady fork cadence, address complexity risks, and balance decentralization priorities with ecosystem scale needs. Together, these discussions form a coordinated step forward in Ethereum’s broader roadmap of scalability, performance, and governance improvement.

• Fusaka Updates
• Glamsterdam Updates
• Glamsterdam Updates
• Miscellaneous Updates

Fusaka Updates

The call confirmed that BPO2 had successfully activated on the Holesky/Hoodi testnet roughly 24 hours prior. Developers observed no meaningful participation drops or irregularities on the peer-to-peer layer, which suggested a healthy network response to the increased blob parameters.

Blob activity was described as “going crazy,” meaning blob feeds were extremely active. The smoother-than-expected activation reinforced the view that Fusaka’s core data-availability improvements, particularly around PeerDAS & blob fee dynamics, were behaving correctly under stress.

The team planned further monitoring of blob utilization, attestation behavior, & P2P stability as the testnet absorbed these higher load levels. Beyond BPO2, developers noted that all Fusaka testnets were functioning smoothly.

No significant declines in validator participation or persistent attestation anomalies had been detected. Minor attestation issues mentioned during the call were scheduled for offline debugging.

Overall, testnet health appeared highly stable, giving confidence that the upgrade was nearing mainnet readiness. A key infrastructure issue surfaced around how BPOs should be documented & tracked.

Two approaches were discussed: continue tying BPOs to each fork’s meta-EIP or establish a dedicated “inter-fork meta-EIP” that sequences all BPOs across time. The group leaned toward the latter, as it simplifies ordering & historical replay, though the conversation will continue across ETH R&D Discord & future ACD calls.

With BPO2 stable & no major concerns emerging from testnets, core developers reiterated that Fusaka’s mainnet activation was roughly three weeks away. Teams would continue high-intensity monitoring on Holesky & Hoodie while validating blob scaling behavior under higher throughput.

Glamsterdam Updates

ePBS (EIP-7732) introduces a protocol-level redesign of block construction by separating the roles of block proposer (consensus layer) & block builder (execution layer). Today’s MEV-Boost ecosystem relies on external, trusted relays to coordinate builder submissions, creating centralization & censorship-risk concerns.

Core developers reiterated that ePBS is the primary headliner for the Glamsterdam fork. Because of its scope, ePBS alone consumes a large portion of Glamsterdam’s testing & risk budget.

This is why most client teams oppose pairing ePBS with other extremely large features. Core contributors emphasized that ePBS development must not wait until January or later for interop testing.

A mid-December DevNet 0, even if imperfect, allows client teams to identify mismatches, validate the Engine API, & uncover unexpected behaviors early. Kurtosis-based setups will be used to quickly spin up multi-client networks capable of simulating builder-proposer flows under ePBS rules.

FOCIL (EIP-7805) introduces fork-choice enforced inclusion lists, requiring blocks to include certain mempool transactions published by an inclusion-list committee. It is designed to counteract builder- or relay-level censorship & ensure timely inclusion for censored transactions.

Proponents argued that the L1-plus-L2 ecosystem is entering a phase where censorship-resistance is increasingly critical, particularly as MEV structures centralize. Many staker groups & researchers emphasized that continuous deferral of censorship-resistance features sends the wrong social signal.

They contended that if Ethereum continues prioritizing efficiency improvements over decentralization safeguards, the community may perceive that the protocol is drifting away from its ethos. For these advocates, pairing ePBS with FOCIL in Glamsterdam would send a powerful statement about Ethereum’s commitment to neutrality.

Opponents stressed the substantial engineering complexity FOCIL adds, especially when paired with ePBS. Both features introduce network sidecars affecting fork choice, gossip validation, & block structure.

Testing these components simultaneously could add three to six months of delay, undermining the new goal of predictable fork cadence. The emerging solution is to keep FOCIL out of Glamsterdam, while explicitly designating them as top-priority candidates for the H-fork.

• EIP-7688 addresses the issue of Ethereum's consensus data structures using SSZ Container, which lacks forward compatibility in merkleization schemes. This leads to verifier implementations needing updates with each fork, causing maintenance overhead.
• EIP-8045 addresses the issue of slashed validators being selected as beacon chain proposers, which currently leads to missed slots and degraded network performance, especially during mass slashing events.
• EIP-8061 addresses long exit queues and slow validator set consolidation in Ethereum, improving staking liquidity and network responsiveness.
• EIP-8071 addresses the unintended use of the consolidation queue for speeding up withdrawals, which exploits an imbalance between exit and consolidation queues. This fix prevents validators from bypassing the intended withdrawal process.
• EIP-8062 introduces a fee on partial withdrawals for 0x01 validators to incentivize stake consolidation and reduce unaccounted protocol resource usage, aligning with Ethereum's fast finality roadmap.
• EIP-8068 addresses yield disparities between skimming (0x01) and compounding (0x02) validators, ensuring equal capital efficiency. It also prevents gaming of hysteresis rules, promoting stake consolidation critical for Ethereum's fast finality roadmap.

Across the ecosystem, client teams are aligned on keeping Glamsterdam focused on ePBS while deferring heavier changes to future forks. Smaller and targeted improvements like EIP-8071 fit well within the fork’s risk budget, while more complex proposals require deeper analysis and dedicated cycles.

This balanced approach ensures both protocol safety and roadmap reliability. The result is a cleaner and more predictable path toward Ethereum’s long term decentralization and scalability goals.

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