ACDE #216: Call Minutes

The call where developers removed EIP 7907 from Fusaka

Jul 18, 2025

Good evening,

After tuning in to today’s All Core Developers call, I was inspired to take action and help accelerate and aggregate Ethereum stakeholder views on what they think should be included in the Glamsterdam upgrade.

So, I’m hosting my first Ethereum community call next Wednesday at 10am (ET). If you’re a major stakeholder in Ethereum with views on what you think should be prioritized in the next Ethereum upgrade, please join the call and share your views.

I plan to summarize views from the community call and share them with developers at next week’s All Core Developers Consensus (ACDC) call.

At a high level, today, developers decided to remove EIP 7907 from the Fusaka upgrade, meaning there will be no changes to the smart contract code size limit on Ethereum for the foreseeable future. A version of the EIP may be re-proposed for the Glamsterdam hard fork, but it is not guaranteed to be included in the next fork.

On Glamsterdam, developers seem largely aligned about what they want to implement. However, there are a few major questions they are still discussing on the specifics of what a fork that includes enshrined proposer builder separation and block-level access lists would look like.

Below is the full summary of All Core Developers Execution Call (ACDE) #216.

Yours truly,

Christine D. Kim

🛎️ Programming note: I am seeking a sponsor for this weekly free edition of the ACD After Hours newsletter. If you're advancing Ethereum’s technical roadmap, client development, or protocol research, and would like to promote your work with a diverse and engaged audience of Ethereum stakeholders, please reply to this email. Thank you!

Key Decisions & Announcements

(For background on the ACD process and terminology used on these calls, refer to the Ethereum Governance 101 document in the ACD Toolkit.)

Fusaka

Fusaka Devnet-2 is stable. Ethereum Foundation (EF) Developer Operations Engineer (EF) Barnabas Busa reported new bugs are being patched for Teku, Lodestar, and Prysm clients.
EF Protocol Team Co-Lead and ACDE Call Chair Tim Beiko shared a potential timeline for shipping Fusaka on mainnet. The proposed timeline was as follows:
- Client public testnet releases ~> Week of Aug 25
- First public testnet upgrade ~> Sep 22 - Oct 3
- Second testnet upgrade ~> Oct 6-10
- Mainnet upgrade ~> Nov 5-12
Developers agreed to remove EIP 7907 (Meter Contract Code Size and Increase Limit) from the upgrade, so that client teams can accelerate testing for Fusaka.
Pull Request (PR) #9986, updating EIP 7825 (Lower Tx Gas Limit Cap), has been finalized and merged. It will be included in the specifications for Fusaka Devnet-3.
Developers agreed to reconsider changes to the “engine_getblob” API method for Fusaka Devnet-3 and reach a final decision about it on next Monday’s testing call.
Developers are aiming to launch Fusaka Devnet-3 next Wednesday, July 23.

Glamsterdam

The preferences of client teams for what code changes should be prioritized in the Glamsterdam upgrade were shared in advance of today’s call:
Based on the discussion, client teams are leaning in favor of prioritizing enshrined proposer builder separation (ePBS) and block level access lists (BALs) in Glamsterdam.
Pending more input from the broader Ethereum community, developers aim to reach a decision on the Glamsterdam headliner code changes over the next two to four weeks.

Notable Discussion

(Quotes featured in this section may be edited slightly for grammar and clarity. For more information on the people quoted in this section, refer to the ACD Call Directory in the ACD Toolkit.)

Removing EIP 7907 from Fusaka

Beiko asked whether the timeline for shipping Fusaka before the Devconnect conference in November was “realistic” to developers.

EF EthPandaOps Team Lead Parithosh Jayanthi reiterated, as he has on prior calls, that the timeline is dependent on when developers freeze Fusaka code specifications.

Jayanthi said:

“I think the very least, we're gonna need at least a stable Devnet-3 and no spec changes after that, other than clarifications. We're going to need a large [test] network, collaborated probably with Sunnyside Labs, a non-finality [test] network, mainnet, and [public] testnet shadow forks, [and] a test without “engine_getblobv2” [enabled], as Dustin mentioned. We have to run the analysis for what [blob parameter only hard fork] values we actually want to set on the devnets, as well as on the public testnets, as well as on mainnet. This is apart from [security] audits and having all the client changes pushed into branches that are mostly stable.”

Busa wrote in the Zoom chat that the timeline to ship Fusaka by November looks “tight, but doable.”

EF Protocol Team Co-Lead and ACDC Call Chair Alex Stokes wrote in the Zoom chat:

“Think Fusaka this year is our #1 priority [at the moment].”

To accelerate testing for Fusaka, developers discussed removing EIP 7907 from the upgrade. Geth developer Marius van der Wijden said:

“The biggest argument that I see [against it] right now is that this mechanism is not future compatible, so we will need to change the mechanism anyway. I don't know if we should enshrine this mechanism for potentially one or two hard folks, when we can get the benefit with something very simple for the proposal that will be future proof.”

Derek Lee, a product manager at Offchain Labs argued strongly in favor of including a simpler version of EIP 7907 in Fusaka that increases the limit to smart contract code size but does not introduce a new pricing mechanism for loading large contracts.

Reth developer Roman Krasiuk was in favor of this approach.

The co-author of EIP 7907, Charles Cooper, noted that increases to smart contract code size without a pricing mechanism for loading large contracts could have dangerous side effects and introduce bottlenecks to scaling at higher block gas limit levels.

Cooper recommended the inclusion of an alternative version of EIP 7907, EIP 7903 (Remove Initcode Size Limit).

EF Researcher Ansgar Dietrichs asked developers in the Zoom chat to vote on the next steps for EIP 7907. Fourteen call participants voted in favor of removing the EIP entirely, without any modifications. Only six voted in favor of including some modified version of it in the upgrade.

Beiko recommended excluding EIP 7907 from Fusaka.

The public testnet upgrade timeline

Then, Beiko raised concerns about the proposed timeline for public testnet upgrades that was proposed by EF Researcher Fredrik Svantes earlier this year in the aftermath of the Holesky testnet failure.

He noted that the timeline recommends a buffer period of 30 days after the first client releases for public testnet upgrades, and then 30 days after the last client releases for public testnet upgrades. These two periods are intended to allow for sufficient testing of client releases and provide developers with enough time to respond in the event of critical bugs in client releases.

Svantes added that another reason for these buffers is to allow Ethereum stakeholders, such as Layer-2 protocols, adequate time to prepare their code for network-wide upgrades.

Dietrichs pushed back on these buffer periods, saying that developers are losing time that could otherwise be used to prepare for the next hard fork.

Beiko asked if the timeline could be shortened based on the state of client releases:

“What's the level of finality that we want on the testnet [client] releases? Because obviously, if we assume that we want the testnet releases to be as close as possible to the mainnet release, then we should almost have a much higher bar for that and then assume that the path between the last testnet [upgrade] and mainnet is a bit shorter.”

Svantes responded to Beiko’s question by saying that it depends on how willing developers are to potentially break public testnets and repeat incidents like the one that happened on Holesky earlier this year.

Jayanthi stressed that developers should try to avoid repeatedly breaking public testnets:

“I can speak up for the community that we are not supposed to break [public] testnets.”

In the Zoom chat, other call participants said breaking public testnets posed an “optics risk” and a practical risk for Ethereum companies that depend on the infrastructure for testing.

However, Grandine developer Saulius Grigaitis noted that since the Holesky testnet is soon to be deprecated anyway and not many stakeholders depend on it, developers should try to upgrade Holesky as quickly as possible.

Beiko and Prysm developer “Potuz” agreed with Grigaitis.

Potuz asked in the Zoom chat:

“Am I the only one that thinks the Devconnect deadline is a little bit ridiculous? It's fine to aim for it, but if we can't, just simply schedule [it] a month later. It's not a big deal. Safely testing would make us all sleep better.”

Outstanding questions about Glamsterdam

Most client teams shared their views on the headliner feature for the Glamsterdam fork in advance of the call. These views expressed broad support for implementing ePBS on the consensus layer (CL) and BALs on the execution layer (EL).

There was also broad support for EIP 7805, Fork-Choice enforced Inclusion Lists (FOCIL).

As stressed by Prysm developers Potuz and Terence Tsao, implementation work for EIP 7805 largely falls to CL developers, as opposed to EL developers; however, work is needed from both groups. For ePBS and BALs, work to implement these respective code changes is orthogonal and contained to one layer of the Ethereum protocol, not both.

Based on client team sentiment, Busa recommended starting work on ePBS and BALs for the upgrade and revisiting the inclusion of FOCIL in Glamsterdam later. Potuz agreed.

Regarding BALs, Krasiuk stated that the code changes are “underwhelming” and do not require sufficient work to be considered an EL-focused headliner. Thus, he supported coupling BALs with other changes on the EL, such as gas repricing, that would enable greater scaling on Ethereum.

Beiko recommended drafting a new headliner proposal for the bundled changes.

Representatives from the Nethermind, Lodestar, and Nimbus teams recommended bundling BALs with elements of the Pureth headliner proposal, which focuses on updating data serialization on the EL to StableContainer (SSZ).

EF Protocol Prototyping Team Lead Toni Wahrstatter warned that developers may be underestimating the implementation work for BALs.

“DataAlways” from the Flashbots team and “Dapplion” from the Sigma Prime team said they will have views to share on ePBS in the coming weeks.

Van Der Wijden, Potuz, Busa, Jayanthi, and Krasiuk pushed for developers to start working on BALs and ePBS as headliners for Glamsterdam imminently.

Beiko and Stokes expressed hesitation and suggested waiting a few more weeks for more community input.

Krasiuk asked Stokes what input from the community he would like to see before making the call.

Stokes mentioned views from Flashbots as an example.

Beiko said that if developers are still confident about ePBS and BALs as the headliners for Glamsterdam on the next ACDE call in two week’s time then they can finalize the decision then.

🌻That’s all for my summary on ACDE #216. You are officially caught up on the state of Ethereum protocol development and governance. Stay tuned for my insights on the call coming out tomorrow.

🌻New to the ACD calls and want to learn how to engage in them yourself? Check out the ACD Toolkit. It contains evergreen resources and materials that teach you the fundamentals of contributing to the evolution of Ethereum like a pro:

ACD Toolkit

🌻I also offer professional consultations on Ethereum protocol development and governance. If you’d like to book a meeting with me to get tailored insights into the evolution of Ethereum for your business or portfolio, please use my Calendly scheduling page:

Book a meeting

Below are links for further reading on the topics discussed on ACDE #216:

Revamped code specifications for FOCIL (GitHub, Ethereum Consensus Specs)
Early stress-testing efforts for ePBS (X post, Kamil Chodola)
Glamsterdam headliner EIPs comparison matrix (X post, “Storm”)
ePBS and FOCIL compatibility breakdown (X post, Everstake)

Here’s what’s coming up next week on the Ethereum Protocol Call Calendar:

Monday July 21

12:00 UTC/8:00 ET, Eth Simulate Implementors Meeting #56 (Meeting link shared on Telegram)
14:00 UTC/10:00 ET, All Core Developers Testing Call #45 (Meeting link shared on Discord)
15:00 UTC/11:00 ET, RPC Standards Call (Meeting may be skipped this week as per the latest message shared here on Discord)

Tuesday July 22

16:00 UTC/12:00 ET, EIP Editing Office Hour #66 (Meeting link shared on Discord)

Wednesday July 23

14:00 UTC/10:00 ET, Glamsterdam Community Call #00 (Organized and hosted by yours truly)
15:00 UTC/11:00 ET, MEV-Boost Community Call #13
16:00 UTC/12:00 ET, L2 Interop Working Group #12 (Meeting link shared on Telegram)

Thursday July 24

14:00 UTC/10:00 ET, All Core Developers Consensus Call #161 (Meeting link shared on Discord)

Friday July 25

No meetings scheduled on this day.

📅 Call days and times may be subject to change so please utilize the links shared above to reconfirm meeting details day of. For a comprehensive overview of all recurring calls and meetings on the Ethereum Protocol Call calendar, refer to this post in the ACD Toolkit.📅

🙂 Thank you for reading another edition of ACD After Hours! If you like what you read today, consider sharing it with a friend who might also enjoy the content.

🤔If today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by leaving a comment.