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.