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

The All Core Developers Consensus (ACDC) Call #163, held on August 21, 2025, brought together Ethereum’s core protocol contributors to review recent devnet progress, evaluate upcoming upgrade plans, and align on key specifications. The discussion covered Fusaka devnet reflections and Devnet-5 preparations, protocol parameter debates such as MAX_BLOB_COMMITMENTS_PER_BLOCK and ForkVersion in the BPO design, and early coordination for the Glamsterdam upgrade through breakout calls, draft EIPs, and proposal deadlines.

• Fusaka Updates
• Glamsterdam Updates
• Additional Updates

Fusaka Updates

Fusaka Devnet-3 is currently live and running with a non-finality test in progress. Participation levels are at approximately 80%, with the network able to achieve finality when all validators are online.

However, some issues have been reported, including a client syncing bug that is under investigation. Additionally, a few nodes are still catching up, and the ethPandaOps team is actively monitoring and addressing these gaps.

Devnet-4 was successfully launched but encountered several bugs that ultimately led to it being taken offline. Although its deployment demonstrated progress, the instability underscored the need for further refinement and highlighted specific areas where improvements are necessary.

These learnings will directly inform the design and execution of Devnet-5. The next phase, Devnet-5, is planned to be similar in scope to Devnet-4 but larger in scale to test more robust scenarios.

Its tentative launch was set for the week following the meeting on August 21, 2025. Developers emphasized that specifications for Devnet-5 should be as close as possible to mainnet configurations, enabling realistic testing of validator behavior and client performance under production-like conditions.

The parameter MAX_BLOB_COMMITMENTS_PER_BLOCK defines the upper limit on the number of blob commitments that can be included in a single block. This plays an essential role in controlling data availability throughput, validator workloads, and the resource requirements for clients.

During ACDC #163, developers confirmed that the minimal preset for this parameter has been set to 4096, referencing consensus-specs PR #4508. Although the topic had already been covered in the previous call, it was flagged again to ensure that it remains visible on the development radar.

Setting this ceiling is critical to maintaining block processing stability and ensuring that future expansions of blob capacity can be tested safely while preserving validator performance and network health. Another key discussion point concerned the role of ForkVersion in the Blob-Parameter-Only (BPO) design.

A theoretical attack vector was raised regarding this implementation, but after review it was determined not to be a concern. The next step agreed upon was to update the relevant EIP to clarify and incorporate this conclusion.

The broader intent of BPO hardforks, as described in EIP-7892, is to enable parameter-only network upgrades, particularly for blob-related configurations, without necessitating wide-ranging consensus changes. This approach gives the protocol more flexibility by allowing developers to refine blob parameters safely and modularly in response to evolving real-world usage.

Glamsterdam Updates

The Glamsterdam upgrade is Ethereum’s next major hard fork after Fusaka, and ACDC #163 dedicated substantial time to preparatory steps. Breakout calls were announced for two important proposals.

• The first, EIP-7928: Block-Level Access Lists, will have its initial breakout call the Thursday following the meeting. The discussion is being tracked through Ethereum PM issue #1691.
• The second, EIP-7732: Enshrined PBS (ePBS), will have its breakout call on the Friday after the meeting. The ongoing discussion is captured in Ethereum PM issue #1696.

Beyond these individual proposals, the meeting also highlighted the introduction of a Meta EIP on Repricing, drafted by ansgar.eth and Maria Inês Silva. This draft seeks to consolidate various repricing proposals into a unified framework, ensuring that gas cost and opcode repricing changes in Glamsterdam are handled consistently and transparently.

While largely an execution-layer topic, it was shared here to keep consensus developers aligned. The draft is available on GitHub. Finally, developers were reminded that all Glamsterdam EIP proposals must be submitted before the Fusaka mainnet release, expected around October 2025, to allow sufficient review and testing.

Additional Updates

Another major focus of the call was client development and transparency in tracking progress. A community member, abcoathup.eth, raised the question of whether a public tracker existed for client merges into main trunks, especially to monitor Fusaka devnet progress.

In response, Barnabas Busa shared the Fusaka devnets image tracker, which provides clear visibility into which client versions are being used in each devnet. The tracker can be accessed on GitHub.

The significance of this tracker lies in its role in fostering transparency and coordination. It allows developers, infrastructure providers, and the broader Ethereum community to see exactly which client builds are participating in the devnets.

This makes it easier to correlate observed issues with specific client versions, supports debugging and triage, and helps ensure that all teams are aligned on the current state of testing. By providing a shared source of truth, the tracker strengthens communication across stakeholders during the Fusaka development cycle.

All Core Devs – Consensus (ACDC) #163
🗓️ Aug 21, 2025 • 14:00 UTC

🔴 Live Stream:
👉 https://t.co/M9ReroyRuQ
👉 https://t.co/qwMz273NAj

Agenda:
- Fusaka: devnet-3/4 reflections, devnet-5 plans
- MAX_BLOB_COMMITMENTS_PER_BLOCK
- ForkVersion in BPO design
- Glamsterdam:…

— Pooja Ranjan | ranjan.eth (@poojaranjan19) August 21, 2025

The meeting also covered a series of additional updates and reminders related to ongoing protocol development. Potuz suggested that short, recurring updates on Glamsterdam should be shared more frequently, ensuring that stakeholders remain aligned between major All Core Dev calls.

This would provide greater visibility into ongoing work without waiting for the larger discussions. Further, important updates were mentioned regarding proposer head and proposer boost, two mechanisms in fork choice that affect block production.

The proposer head determines which block head a proposer should build on, balancing consistency and network latency, while proposer boost gives preference to the proposer’s selected block, reducing the risk of orphaned blocks and improving chain liveness. These specifications are currently under review by peers, including contributors from Lido, who have already uncovered interesting edge cases.

Core developers were encouraged to examine the finer details of payload handling as part of Glamsterdam’s specification work. Finally, Alex Stokes confirmed that updates on proposer head, proposer boost, and Glamsterdam in general will continue to be provided in future All Core Dev calls, signaling an ongoing iterative refinement process.

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