Highlights from the All Core Developers Execution (ACDC) Call #172

The first All Core Devs – Consensus (ACDC) call of 2026 was largely procedural. There were no new features pushed into scope, no late additions to active forks, and no attempt to reset direction for the year.

Instead, the discussion moved through status checks, confirmations, and process updates that have become increasingly central to how Ethereum evolves. Fusaka’s recent blob increase was reviewed without concern.

Glamsterdam’s remaining decisions were narrowed to final calls rather than open debate. Planning for the next hard fork, Hegotá, formally began, with developers spending more time on timelines and proposal mechanics than on technical ambition.

• Fusaka Updates
• Glamsterdam Updates
• Hegotá Updates

Fusaka Updates

The Fusaka fork continues to perform as expected following the activation of BPO2. This upgrade increased the number of blobs per block, expanding Ethereum’s data availability capacity & strengthening the foundation for rollup-centric scaling.

In the days immediately following activation, developers observed that full 21-blob blocks were rare. However, this was quickly contextualised as a demand-side issue rather than a protocol limitation.

The upgrade went live during the holiday period, when blob-heavy rollup submissions were unusually low. A small number of orphaned blocks were also detected.

Investigation suggested these resulted from late slot publication, not instability introduced by higher blob counts. No statistically abnormal reorg patterns were identified.

Glamsterdam Updates

With Fusaka validating recent scaling assumptions, focus shifted to Glamsterdam, where fork scoping is now effectively closed. The fork includes a defined set of Candidate for Inclusion (CFI) EIPs, alongside enshrined Proposer-Builder Separation (ePBS).

One of the clearest decisions of the call was the confirmation of EIP-8070. It introduces a sparse blobpool mechanism to reduce bandwidth consumption in Ethereum's Execution Layer (EL) by sampling blob data instead of fully replicating it.

Although primarily an Execution Layer (EL) change, the EL explicitly surfaced the proposal to the Consensus Layer (CL) for a final temperature check. The intent was governance-oriented which ensured that no fundamental CL concerns existed before advancing.

A detailed technical discussion focused on a refinement to EIP-7688, specifically the Merkle tree shape used for stable containers. Core Devs noted a slight preference for shaping the SSZ tree to the right rather than the left.

While the change is small, it affects foundational library logic & therefore warranted careful consideration.

The motivation is forward-looking:

• Right-shaped trees improve incremental construction
• New entries naturally extend to the right
• Streamability improves for future use cases

The trade-off is marginally increased complexity when reasoning about generalized indices & multi-proofs, though the hash count remains unchanged.

A more conceptual debate emerged around a proposal to introduce a local censoring signal into the Engine API. The idea would allow execution clients to flag blocks they believe have censored transactions, enabling consensus clients to track builder behaviour over time.

While aligned with Ethereum’s neutrality goals, the proposal raised concerns:

1. Mempool behaviour is not standardised across clients
2. Configuration differences could lead to false positives
3. Builders could be penalised without clear visibility

Rather than forcing a decision, developers agreed the idea requires further discussion in ACDE & PBS-focused forums, reflecting Ethereum’s cautious approach to validator-impacting signals.

Hegotá Updates

With Glamsterdam on a stable trajectory, core developers formally initiated planning for the next hard fork: Hegotá.

The headliner process has now opened. Contributors must:

1. Publish a proposal on Ethereum Magicians (tagged for Hegotá)
2. Present the proposal on a relevant ACD call

This ensures both written scrutiny & live technical discussion early in the process. The proposal window is open for approximately one month.

All Hegotá headliner proposals must be submitted & presented before 5 February 2026. Afterward, proposals will move into discussion, refinement, & eventual selection.

Developers briefly discussed whether Hegotá should have a predefined theme. The consensus was flexible:

• If a theme emerges naturally, embrace it
• If not, avoid forcing alignment

ACDC #172 closed without major announcements, but it did provide a clear snapshot of where Ethereum stands as 2026 begins. Fusaka’s recent blob increase has settled in without incident.

Glamsterdam is moving toward finalisation with scope largely locked. Planning for Hegotá has started early, with an emphasis on process rather than urgency.

Together, the discussion suggested a network less focused on acceleration and more concerned with making sure the ground it has already covered remains stable.

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