All Core Devs - Execution (ACDE) #238, June 4, 2026

Protocol Calls & happenings
,
1

Agenda

Meeting Time: Thursday, June 04, 2026 at 14:00 UTC (90 minutes)

GitHub Issue

1 Like
2

Video, transcript & chatlog

News coverage

Resources

3

Meeting Summary:

This was Orko Dev’s execution meeting number 238, where Ansgar returned as co-lead with Nixon. The main topics discussed were Glumsden DevNets and EIP proposals for He Got Her (Hegota). For Glumsden DevNet 5, Barnabas reported that it had just launched with genesis occurring an hour before the meeting and a fork planned for two hours later, with 2 ELs and 4 CLs currently running. The team decided to integrate DevNets starting with Gamzadam DevNet 6, making it the unified branch rather than creating separate BAL DevNet 8. Regarding EIPs for DevNet 6, the group agreed to include four new EIPs: two repricing EIPs (8038 and 2780), and two feature EIPs (8246 and 7997), with the intention to include preliminary versions even if final benchmarking numbers aren’t ready in time. Tony presented two repricing EIPs aimed at reducing worst-case block size by 32%, while Greg discussed changes to EIP 7979 regarding on-chain validation algorithms and potential issues with subroutine code sections. Mohammad and Pierre presented EIP 8222 on linear staking for privacy, though the discussion revealed significant concerns about compelling stakers to use privacy pools and technical implementation challenges. Matt presented EIPs 7851 and 8151 regarding permanent EOA delegation and ECRecover deactivation, with Ben Adams suggesting a more general “set code from” approach. The conversation ended with Barnabas noting that Marius’s Engine SSE changes were adopted instead of his original proposal, and reminding attendees that next week’s ACDC call would be at 11 o’clock UTC.

Click to expand detailed summary

Ansgar returned as co-lead with Nixon to coordinate the meeting, discussing two main topics: Glumsden DevNets and EAP proposals. Barnabas reported that Glumsden DevNet 5 had just launched with genesis occurring an hour before the meeting, featuring 2 ELs and 4 CLs, with plans to onboard Teku after the fork. Barnabas requested that other ER clients review the engine API changes and suggested that DevNet 6 would be the point at which to integrate the DevNets.

The team decided to merge all development networks into a single unified track starting with Glamsterdam DevNet 7, eliminating separate Bal DevNet 8. Barnabas suggested this approach to avoid conflicting branches and potential issues for ER teams. The group agreed to review pending EIPs for inclusion in DevNet 6, with Barnabas referencing GitHub issue 2915 and a list compiled by Spencer. Ben Adams noted that benchmarking numbers are needed for some EIPs, though finalized numbers aren’t required for the next subnet launch, which is expected within two weeks.

The team discussed the inclusion of various EIPs in DevNet 6, focusing on repricing, features, and out-of-protocol changes. They decided to include the self-destruct and deterministic factory pre-deploy features in DevNet 6, as no one opposed their inclusion. The sparse block pool EIP was deemed optional and not ready for inclusion yet, pending CL support. The team agreed to wait for finalized numbers on the repricing EIPs before making a decision on their inclusion in DevNet 6.

The team discussed including several EIPs in DevNet 6, with Barnabas suggesting they implement preliminary values to test the changes and identify any tooling issues. Ansgar confirmed that EIPs 8038, 2780, 8246, and 7997 would be included in DevNet 6, while EIP 7610 was postponed for further discussion with Gary. The team also noted that all changes to existing EIPs would be included in DevNet 6.

Toni presented two EIPs (8131 and 8279) targeting block size reduction by 32% through improved data pricing mechanisms. The first EIP addresses intrinsic gas pricing for call data, blob version hashes, and authorizations, while the second EIP extends this to block-level access lists. The proposed changes would establish a simplified formula of block gas limit divided by 64 and address pricing inconsistencies that contribute to block size issues. Ben Adams inquired about the relationship to the existing block size cap, and Toni clarified that while the current 8MB cap remains as a security mechanism, the proposed changes aim to prevent hitting the cap by making block size more efficient rather than distorting market economics.

Greg proposed moving the validation algorithm on-chain instead of requiring clients to implement it, which would simplify client implementation and give compiler teams more flexibility without involving core developers. He identified two potential issues that need discussion: the magic number for validation (suggested 0xef02 instead of 0xef01) and concerns about access logic, pricing, and warming of the on-chain contract. Ansgar suggested scheduling a follow-up breakout call to discuss the nuanced implications, particularly given the timing around Amsterdam work.

The team discussed scheduling a breakout call for Greg’s proposal, with Josh helping Greg coordinate timing. Ansgar advised considering the timing relative to the ERP proposal window and decision-making period. Greg reported that his specification is nearly complete but faces delays in getting it merged by editors, and mentioned losing a co-author on the validation algorithm and ZK implementation work. Mohammad briefly introduced EIP 8222, a lean staking proposal, and requested feedback while noting it’s still far from ready for merge.

Mo presented an AIP called “linear staking” co-authored with Pierre, which aims to introduce base layer privacy for Ethereum staking by modifying the beacon deposit process to provide one-sided plausible deniability. The proposal introduces a two-phase deposit system using commitments and frame transactions, with plans to extend similar privacy features to withdrawals. When questioned about implementing privacy at the beacon contract level versus application level, mo explained that the beacon contract approach offers better plausible deniability by mixing legitimate protocol flows with privacy-seeking transactions.

Mo presented an EIP proposal to introduce a privacy pool and force staking flows through it, aiming to provide plausible deniability for users. The discussion revealed skepticism about the proposal, with concerns raised about compelling validators to use the pool without breaking existing staking infrastructure. Participants questioned the feasibility and necessity of the approach, suggesting simpler alternatives like using existing privacy protocols. The group agreed to continue discussions but decided not to pursue this as part of the Hekota proposal due to technical and timing constraints.

Lightclient presented two EIPs (7851 and 8151) that allow users to permanently delegate and disable their EOA keys as part of account abstraction migration. Ben Adams suggested using a more general SETCODEFROM opcode approach instead of creating specific EIPs, which could provide broader functionality including cheaper deployments for duplicated code. The discussion included concerns about potential phishing and security risks, with Ahmad suggesting restrictions on SETCODEFROM usage for delegated accounts to mitigate abuse.

The team discussed proposals for IP changes, with Ben Adams suggesting a new unified state code approach for efficient code deployment, particularly for projects like Uniswap. Lightclient proposed keeping the existing EIP as is while introducing a separate EIP for the new idea, and agreed to review existing EIPs for similar proposals. The group also addressed concerns about deposit limits in blocks, with Barnabas and others discussing potential solutions including increasing maximum deposits or using progressive containers, while noting that current clients can handle thousands of deposits per slot. Barnabas reminded the team that next week’s ACDC call would be shifted to 11:00 UTC.

Next Steps:

  • Barnabas: Monitor Glamsterdam DevNet 5 stability after the fork and onboard Teku client right after the fork or the next day.
  • Barnabas: Reach out to other EL clients to review the engine API changes so they can be onboarded to DevNet 5.
  • Barnabas: Coordinate planning for Glamsterdam DevNet 6 to be launched within two weeks, targeting inclusion of EIPs 8246, 7997, 8038, and 2780 (with preliminary benchmarking numbers).
  • Ben Adams: Follow up on benchmarking numbers for EIPs 8038 and 2780 so preliminary values can be used in DevNet 6.
  • Client teams: Confirm that Baal DevNet 7 is the last Baal-specific DevNet and that no Baal DevNet 8 will be created; all future EL work will be on top of Glamsterdam DevNets.
  • Ansgar: Check in with the benchmarking effort on EIPs 8038 and 2780 at next week’s ACDT call to confirm preliminary numbers are ready for DevNet 6.
  • Greg: Work on getting the updated 7979 draft merged and published by EIP editors to facilitate community review.
  • Greg: Coordinate with Josh to schedule a breakout call for EIP 7979 at an appropriate time (not too early to conflict with Amsterdam work, not too late to miss the Hegota proposal window).
  • lightclient: Review existing EIPs related to generic set-code-from opcode (including EIP 8058) and determine whether a new EIP or modification is needed for a more generalized solution alongside 7851 and 8151.
  • Barnabas: Ensure EL clients who implemented the previous execution API proposal switch to Marius’s Engine SSE changes instead.
  • Barnabas: Follow up on the maximum deposits per block issue (either increasing the limit to 2x or including the stable container EIP) to handle increased gas limits safely.
  • Potuz: Coordinate with Nico (Fleg) to potentially showcase their new EIP proposing a new contract model for builder deposits on a future call.
  • Barnabas: Remind attendees that next week’s ACDC call is shifted to 11:00 UTC.

Recording Access:

4

YouTube Stream Links: