All Core Devs - Consensus (ACDC) #172, Jan 8, 2026

[nixorokish]

UTC Date & Time

January 08, 2026, 14:00 UTC

Agenda

• Happy 2026, last ACDC: All Core Devs - Consensus (ACDC) #171, Dec 11, 2025 #1825
• Announcements
  • New breakout on FCR: All Core Devs - Consensus (ACDC) #172, Jan 8, 2026 #1844 (comment)
  • All Core Devs - Consensus (ACDC) #172, Jan 8, 2026 #1844 (comment)
• Fusaka
  • BPO2 status
• Glamsterdam
  • EL lean to CFI EIP-8070 (Sparse blobpool), final call
  • EIP-7688 update to tree shape: All Core Devs - Consensus (ACDC) #172, Jan 8, 2026 #1844 (comment)
  • local censoring signal proposal: All Core Devs - Consensus (ACDC) #172, Jan 8, 2026 #1844 (comment)
• Heze
  • Headliner process
    • NOTE: overview of process and timelines
    • Short discussion on fork focus/theme
    • Open headliner submission, proposals must be made BEFORE 5 Feb 2026.

Call Series

All Core Devs - Consensus

🔧 Meeting Configuration

Duration

90 minutes

Occurrence Rate

bi-weekly

Use Custom Meeting Link (Optional)

• I will provide my own meeting link

Facilitator Emails (Optional)

No response

Display Zoom Link in Calendar Invite (Optional)

• Display Zoom link in invite

YouTube Livestream Link (Optional)

• Create YouTube livestream link

[github-actions]

⚡ Protocol Call Resources:

✅ Zoom: Join Meeting
✅ Calendar: Add to Calendar
✅ Discourse: Discussion Topic
✅ YouTube Live: Watch Live

[will-corcoran]

Can we have a minute to draw attention to a new breakout room call that will be starting on Tues Jan 20th at 2pm UTC (and run on an every-other week basis) that focuses on shipping Fast Confirmation Rule. If either @saltiniroberto or @mkalinin could lead the update, that would be great.

[abcoathup]

Fork focus

As part of headliner proposals, we should explicitly define the focus for Hegotá.

• Scale L1
• Scale L2
• UX
• DX
• Decentralization
• Resilience

Examples from: https://ethereum-magicians.org/t/community-consensus-fork-headliners-acd-working-groups/24088#p-58740-defining-the-fork-focus-4

Scalability & Lower Fees: Meaningfully increase throughput, lower transaction costs, and unlock new use cases.

Developer & User Experience: Simplify protocol complexity, enhance smart contract security, and reduce development friction.

Security & Resilience: Strengthen the network’s security posture, enhance attack resistance, and mitigate emerging threats without compromising decentralization or censorship resistance.

[akashkshirsagar31]

X Stream: https://x.com/i/broadcasts/1YpKkkNXDlVKj

[potuz]

I'd like to take a few minutes to describe an engine API change that I would like to propose for Glamsterdam. On calls to notify_NewPayload the engine should return not only the usual information of VALID/INVALID/etc but also a boolean indicating if the payload was censoring according to their view.

Vanilla CLs then could ban the builder of that payload from any request they make. This entails changes in the CL and the EL.

• On the CL side nodes have to add configurations to deal with this boolean. They could for example temporarily ban said builder, could keep track on how many times the builder is censoring, how many not censoring, etc. This should all be operator configurable.
• On the EL side this should add heuristics to when to determine that a block was a censoring block. Most ELs already have some form of implementation of FOCIL and could reuse part of this feature. For example if they see a paying transaction in the mempool that has been there for 2 blocks and could have been appended in the end of the builder's block, they could declare that block as censoring. This should also be node operator configurable.

[etan-status]

Glamsterdam:

For SSZ progressive shape, there is slight preference from some people to shape the tree to the right. Affects the library work in EIP-7688 (but is a small change). If there's no strong preference for left, would like to swap to right and then lock it in that way.

• https://github.com/ethereum/EIPs/pull/11032/files
• https://github.com/ethereum/remerkleable/pull/16/files
• https://github.com/ethereum/consensus-specs/pull/4813/files

Also, EIP-7688 updated for v1.7.0-a.0 and ready for merge as well.

• EIP-7688: Use forward compatible SSZ types in Gloas consensus-specs#4630

Once merged, will update light client specs as those are still missing for Gloas.

[nixorokish]

comments welcome on adding a new "championing an EIP" doc to help EIP champions know what's involved in doing so & give some guidance around it: #1864