All Core Devs - Consensus (ACDC) #189, October 15, 2026

Protocol Calls & happenings
,
1

Agenda

Meeting Time: Thursday, October 15, 2026 at 14:00 UTC (90 minutes)

GitHub Issue

1 Like
2

Video, transcript & chatlog

News coverage

Resources

3

Meeting Summary:

The meeting focused on updates and discussions around the Sepolia and Hoodie forks, as well as the scoping of various EIPs for the upcoming Haggota hard fork. The Sepolia fork was reported to have gone well, and preparations for the Hoodie fork were underway, with client releases and a blog post in progress. Dima raised an issue regarding builder deposits and validator onboarding, proposing a spec change to prevent unintended outcomes, but the consensus was to not make changes at this late stage. Barnabas discussed EIP 8365, suggesting modifications to how 0x00 validators are handled post-fork. Ignacio presented EIP 8025, advocating for its inclusion to facilitate network testing of execution proofs, but the client teams did not support its CFI for Haggota. Several other EIPs were reviewed, with decisions to DFI EIPs 7716, 8359, and 8025, while EIP 8205 on withdrawal credentials pre-registration was deferred for further discussion. The meeting also touched on the need for process improvements for long-running experimental features.

Click to expand detailed summary

Stokes led the meeting ACDC 189, discussing the successful Sepolia fork and upcoming Hoodie testnet scheduled for October 26th. Client releases were reviewed, with Lodestar and Etherex confirmed, while Lighthouse and Teku planned releases for early next week. Barnabas highlighted the need to test builder availability during the fork transition, and the team agreed to conduct builder deposits and top-up transactions before the fork.

Dima raised concerns about a vulnerability in the validator deposit process where builder onboarding could interfere with regular validator deposits at the time of the Amsterdam hard fork. The proposed fix would ensure deposits with validator withdrawal credentials are credited to validators rather than builders, preventing deposit theft. However, client teams including Barnabas, Nico, and others argued that implementing changes at this late stage would require pushing back the Hoodi release and potentially cause consensus issues if only some clients adopt the change. The group decided to maintain the current protocol behavior due to timing constraints and the complexity of making changes after code has been deployed to Sepolia.

Barnabas proposed an alternative approach to the EIP that would allow 0x00 validators to join but have no validator duties, preventing potential attacks while still allowing BLS changes and exits. NC expressed concern about why burning ETH should be avoided for mistakes, particularly comparing it to existing cases of invalid signatures. The team agreed to review the proposed changes and discuss potential modifications to the EIP in future calls.

Ignacio presented a refresher on EIP-8025, explaining that it allows opt-in proofs to go off execution proofs into the network for metric collection and understanding networking implications. He highlighted that six EL clients have been integrated into the Hive dashboard and are passing over 95% of tests, with changes already upstreamed into main branches. Ignacio argued for including EIP-8025 in the Core Dev cycle due to operational experience needs and development efficiency, noting that the 16K-line PR primarily affects testing frameworks rather than core EIP code. He emphasized that the 65 lines touching the EIP code are crucial for avoiding conflicts with other upcoming changes like PVT.

The team discussed whether to CFI (Community Funded Initiative) a proposal for optional stateless block validation and proofs. Ignacio explained the technical approach and emphasized following protocol-level rules, while the discussion centered on process considerations and whether experimental changes should be upstreamed through CFI. The conversation revealed mixed opinions from different client teams, with some supporting the work but questioning the need for CFI, and others expressing concerns about scope and process. The conversation ended without a clear decision on whether to proceed with CFI, with suggestions to either proceed with CFI or develop a better process for long-running experimental initiatives.

The team discussed whether to CFI (Consensus Fallback Mechanism) EIP 8025, which relates to ZK-EVM implementation. Most client representatives, including Lodestar, Prysm, Lighthouse, Nethermind, and EthereX, expressed support for moving the EIP to CFI, noting that it has substantial support and testing across clients. However, lightclient and others raised concerns about forcing client implementation of an optional feature and managing multiple branches. The discussion highlighted tensions between efficiency and process constraints, with some arguing that the feature should be integrated directly rather than going through the full EIP process. The conversation ended without a clear decision to move forward with CFI, though there was general agreement to continue supporting the underlying work and potentially discuss integration directly in the next ACDT meeting.

The team discussed whether to CFI (Community Funded Initiative) an EIP related to execution proofs. Manu explained that while the EIP is optional, Lighthouse and Prism are actively working on it, and some client teams are interested. However, Enrico and Potuz expressed concerns about merging it into the main fork branch, arguing it should remain optional and not affect every fork. Despite some support for the EIP, including from Francesco who noted its isolated design, the consensus was against merging it into the main branch due to potential compatibility issues. Stokes concluded that the EIP should be marked as DFI (Declined for Implementation) for now, and the team agreed to review their branching process to make it easier for such features in the future.

The team discussed two EIPs. For EIP-8148 (Zodas), Csaba presented a proposal to fix design issues with BuildAS, including CPU load on large nodes and reliance on specific nodes, with an optional simpler “B variant” that addresses only CPU usage. The team decided to defer this EIP due to current lack of blob usage. For EIP-8359 (BeaconBlock reporting field), Luca explained the proposal to add new fields for better client diversity tracking, particularly for multi-node setups. Despite some support in the chat, the team decided to defer this EIP as well, noting that while the topic is important, there isn’t sufficient current support.

The meeting discussed two EIPs: 7716 (anti-correlation attestation penalties) and 8205 (withdrawal credentials pre-registration). For EIP 7716, Oisin presented a proposal to increase inactivity penalties for offline validators to discourage centralization, but the group decided to DFI (delay for implementation) due to mixed support and concerns about touching beacon state. For EIP 8205, Dima presented a solution to address withdrawal credential race attacks in delegated staking, but the group also decided to DFI this proposal, with some client teams expressing concerns about implementation complexity and the need to address it alongside post-quantum deposit contract changes. The discussion on EIP 8205 was deferred to the next meeting for further discussion.

Next Steps:

  • stokes: Monitor client releases for Hoodie and publish the EF blog post once a quorum of clients have released.
  • Barnabas: Test builder availability at the Hoodie fork transition by making deposits and top-up transactions before the fork.
  • Client teams: Review Barnabas’s proposed changes to EIP-8365 (disabling new 0x00 validators) and provide feedback.
  • Client teams: Review EIP-8025 (optional execution proofs) and consider alternative processes to integrate long-running experimental features.
  • Client teams: Review EIP-8205 (withdrawal credentials pre-registration) further, with the discussion to be continued in the next call.

Recording Access:

4

YouTube Stream Links: