Ethereum All Core Developers Execution Call #208 Writeup
On March 27, 2025, Ethereum protocol developers met over Zoom for All Core Developers Execution (ACDE) Call #208. This week, the call was chaired by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko. The ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum.
On ACDE #208, developers tentatively agreed to set April 30 as the go-live date for the Pectra upgrade on Ethereum mainnet. They also agreed to keep EOF in the scope of the Fusaka upgrade and discussed the next steps for implementing history expiry on Ethereum.
Pectra Goes Live on Hoodi
On Wednesday, March 26, developers successfully activated the Pectra upgrade on the Hoodi testnet. EF Developer Operations Engineer Parithosh Jayanthi said there were a few non-critical bugs identified in the Erigon and Lighthouse clients following Pectra activation on Hoodi. These bugs have since been resolved by the respective client teams. Jayanthi said further testing of Pectra features is still needed but is delayed due to a backlog in validator deposits on Hoodi. Jayanthi said that as soon as the deposit queue has been cleared, his team will continue testing Pectra on Hoodi.
Ivan Metrikin from the Lido DAO said that Pectra testing for Lido operations has been going smoothly since the Pectra upgrade on Hoodi. He said 14 node operators and all 4 of Lido’s staking modules and oracles operated smoothly through the Pectra upgrade. There is still more testing for his team to do as well on Hoodi, but he emphasized that initial testing for Pectra looks good.
Beiko mentioned that other infrastructure providers and apps, such as Etherfi and Eigenlayer, have a dependency on Gnosis Safe, a multi-signature wallet application, being live on Hoodi before they can start testing Pectra features. Jayanthi said Gnosis Safe smart contracts have since been deployed on Hoodi, so this should no longer be a blocker for Pectra testing.
Formalizing the Ethereum Upgrade Process
Ethereum Foundation Researcher Fredrik Svantes then presented a document formalizing the Ethereum upgrade process and outlining key requirements for activating code changes on mainnet. Svantes said this document can help standardize how upgrades on Ethereum happen and ensure adequate safety and review for them.
He highlighted many requirements in the document. One of them is the formation of an “Incident Response Team” for each upgrade on a public testnet or mainnet that identifies key individuals from client teams and other stakeholder groups for alerting and responding to any unexpected upgrade issues. Another is ensuring that public testnet upgrades are scheduled one at a time, at least 14 days apart, and at least 30 days after client releases for public testnet upgrades have been made ready to allow sufficient time for code audits and review.
Beiko said that the document introduces many formalities to the Ethereum upgrade process that cannot all be reviewed and discussed on the call. He highlighted only the aspects of the document that apply to the Pectra upgrade for immediate review by the developers. He asked if developers would feel comfortable forming an incident response team for the Pectra upgrade on mainnet and formalizing what testing should be completed in the lead up to Pectra mainnet activation. EF Researcher Alex Stokes and Teku developer Enrico Del Fante were in favor of the document and Beiko’s suggestion. Beiko reaffirmed that developers should try to implement relevant parts of Svantes' document in the lead up to Pectra mainnet activation.
Checking Client Configurations Before Upgrades
Independent Ethereum Foundation developer Danno Ferrin also presented a document for ensuring Ethereum upgrades happen smoothly. Ferrin’s proposal, EIP 7910, recommends the creation of a new JSON-RPC method that will return information about client configurations for an upgrade, including the upgrade epoch, relevant system contracts, and precompile addresses. For context, the Pectra upgrade on the Holesky and Sepolia testnets caused major network disruptions due to issues in the configuration of system contracts in clients.
Ferrin said that he does not expect developers to reach consensus on his EIP for a few months at least and that he appreciates feedback and discussion on the idea. Beiko asked if developers wanted to try implementing the EIP for Pectra. Geth developer Felix Lange said that his team needs more time to review Ferrin’s proposal and would likely need to write new code for their client to implement it. Other developers representing the Nethermind and Reth client teams also advocated in the Zoom chat for more time to discuss the EIP. Beiko said developers can aim to implement the EIP for the Fusaka upgrade.
Pectra Mainnet Timing
Beiko asked if developers should pick a date for Pectra mainnet activation. Andrew B. Coathup, former editor of the Week in Ethereum News newsletter, shared potential dates and epoch numbers for Pectra mainnet on the call agenda. EF Developer Operations Engineer Barnabas Busa and Nethermind developer Lukasz Rozmej said the first and most expedient date of April 30 works for them. Beiko said that going with April 30 means that client teams should have final Pectra releases out between April 10 and April 14. Then, the EF can publish a blog post alerting the broader community about upgrade activation at least 2 weeks before upgrade activation.
Metrikin said April 30 is also fine with the Lido team. However, he noted that other applications, such as the liquid restaking protocol Etherfi, may need more time for Pectra testing. Teku developer Enrico Del Fante asked in the Zoom chat about the timeline for testing validator attestation aggregations and validator consolidations.
Beiko asked if any client teams would object to tentatively setting April 30 as the Pectra mainnet activation date. There were no objections. Beiko said client teams should elect members of their team to be part of the incident response group for the Pectra mainnet upgrade on April 30, according to the suggestions in Svantes’ document. He said developers will reconfirm the mainnet date on next week’s ACD call after following up with ecosystem stakeholders not present on the call, like Etherfi.
PeerDAS Updates
Minhyuk Kim is an engineer at Sunnyside Labs. Sunnyside Labs, formerly known as Test in Prod, is a core development team of the Optimism Collective. Kim shared that his team is working to help client teams ship PeerDAS faster and highlighted that there are open discussions about how to implement PeerDAS in EL clients that his team is actively trying to resolve. Kim briefly mentioned the issue of UTXO pool size limits as an example. Representatives from the Geth and Nethermind teams said these limits should not be an issue for increasing blob capacity in PeerDAS.
Then, Stokes shared two pull requests for migrating cell proofs from the EL to the CL. Stokes said that he would proceed to merge these changes posthaste if there are no objections voiced about them. Lange highlighted that these changes are purely networking changes related to PeerDAS, and they do not change any aspects of the block header.
EOF Updates
Beiko acknowledged recent concerns shared about the complexity of EOF and asked developers if EOF should be reconsidered as a whole for inclusion in the Fusaka fork. If not, Beiko said developers should discuss and agree on what version of EOF to ship in the upgrade. Before the call, the Ipsilon team offered four different versions of EOF to include in Fusaka. As background, the Ipsilon team is a research and development team funded by the EF that focuses on the Ethereum execution environment, also called the Ethereum Virtual Machine (EVM).
The first option proposed by the team is called “Complete EOF”. It is the option containing the largest amount of EIPs that also incorporates feedback from the cofounder of Ethereum, Vitalik Buterin, for banning code introspection. Nethermind developer Ben Adams expressed his support for Complete EOF in the Zoom chat. Beiko noted that the Geth team, from his understanding, was opposed to Complete EOF.
Lange, a Geth developer, said, “I feel like it’s pretty strange, for example, to remove the gas introspection because it’s something that exists right now, and it is pretty heavily used. So, creating a new model where it’s not possible, it’s just something that is going to raise some issues.” He added, “There’s just a bunch of things where I feel like it’s somehow simpler to not do these changes to the model of the EVM and just only focus on the encoding of the bytecode.”
Other EF employees, like Piper Merriam and Sina Mahmoodi, expressed their support for removing gas introspection in EOF. Nethermind developer Ben Adams also shared that the addition of the PAY opcode addresses the main issues raised by Lange about gas introspection.
Lange expressed concerns about how the removal could impact applications on Ethereum but noted that his concerns are “more like a gut feel thing” and something he would welcome deeper analysis on. Geth developer “Lightclient” reiterated his disapproval of EOF in Fusaka, saying, “There are many risks to doing this. … There is almost certainly things that are going to be negatively impacted and this is one of the reasons I’ve been against EOF but also one of the reasons that I agree with Felix, that if we are to do EOF, then we should probably not go very strong in the direction of banning a lot of behavior that exists today.”
EF Researcher Dankrad Feist wrote in the chat, “I continue to oppose EOF.” Adams noted that the scale of code changes required for EOF, while large, is significantly smaller than the amount of code changes that client teams have shipped in between prior Ethereum hard forks. Beiko said that from his read of the room, there is “broad support” among developers to keep EOF in Fusaka and “moderate support” for removing code and gas introspection in EOF.
Beiko strongly recommended that developers agree to a path forward for EOF on the call. Lange agreed, saying that if there is any major issue with implementing EOF, developers can always remove the code at a later date. Dietrichs also said that while EOF is being worked on for the Fusaka upgrade, developers should prioritize shipping PeerDAS and not wait for the readiness of other code changes like EOF for shipping the fork.
Despite strong opposition from a few individuals on the call, Beiko recommended that developers move forward with Complete EOF in Fusaka. There were no further objections to this. Ferrin said that he would update the necessary documentation for EOF to reflect the Complete EOF guidelines and clarify the implementation of Complete EOF on Fusaka devnets.
The Rest of the Fusaka Scope
Beiko said that all EL client teams, except the Geth team, have shared their views on the rest of the Fusaka upgrade scope. There is near-unanimous agreement among client teams to include EIP 7883, a modification to the “ModExp” precompile pricing algorithm that would allow higher increases to Ethereum’s block gas limit in Fusaka. Beiko asked if developers should label this EIP as “Considered for Inclusion” or “CFI”. This does not mean that developers will implement the EIP in Fusaka yet. It means that developers will strongly consider implementing the EIP once PeerDAS and EOF are already implemented. There were no objections to labeling EIP 7883 as CFI.
Beiko noted that several other EIPs have been proposed for inclusion in Fusaka. He said that developers could discuss the rest of these EIPs proposed for the fork over the next few ACD calls. Prysm developer “Potuz” said developers should discuss the timing of the Fusaka fork before deciding about what EIPs should go into the fork. Beiko said that, based on the sentiment from all client teams, the goal is to ship PeerDAS in Fusaka by the end of the year. He also emphasized that developers will not include any new EIPs into the fork and will label them as "SFI" or "scheduled for inclusion" until PeerDAS and EOF are further along in their implementations.
“For Fusaka specifically we should aim to ship it before the end of the year,” said Beiko.
History Expiry Updates
As discussed on ACDC #153, there is a dependency between history expiry and Pectra so developers are leaning towards pushing back the May 1 deadline for activating history expiry until after the Pectra upgrade is live on Ethereum mainnet. Stokes highlighted the suggestion from Jayanthi to use the May 1 deadline as the deadline for client teams to expire pre-Merge upgrade block and transaction data on the Sepolia testnet. Lead Researcher at Consensys Mikahil Kalinin said consensus layer client teams should ensure that their nodes do not depend on historical validator deposits for syncing before dropping history data and that node operators should be notified of this expiry in advance.
Merriam asked if there were client teams that are not ready to expire history. Potuz said that after the EIP 6110 transition period post Pectra activation, the Prysm client should have no issues with dropping history. Stokes clarified that the transition period for EIP 6110 depends on the size of the validator deposit queue right before Pectra activation. Stokes and Jayanthi said developers should wait for Pectra mainnet activation before setting a date for history expiry on mainnet.
Merriam said that an estimation for when history expiry could go live after the Pectra upgrade on mainnet would be useful and proposed four weeks. Busa said clients can start dropping history on the Sepolia testnet now. Lange said the Geth team is still working on their history expiry implementation and had thought client teams were coordinating to do this by May 1. That said, Lange said he can’t stop client teams from testing expiry on Sepolia earlier, though this may make it more difficult for nodes on the testnet to sync.
In the Zoom chat, Beiko confirmed that clients teams should coordinate history expiry on Sepolia by May 1. He then asked Merriam to formalize this decision by creating an informational EIP to the Fusaka Meta EIP. Beiko noted that due to limited time on the call, other discussion items related to history expiry, such as the Ethereum Wire Protocol versioning, would have to be tabled and discussed asynchronously.
Announcements
EF Research Co-Lead Barnabé Monnot announced the start of a new call series, the Protocol Research calls, to discuss big questions about Ethereum’s future. The first call, which will focus on questions about local block building, will be hosted next Wednesday, April 2, at 14:00 UTC.
Beiko highlighted an agenda item by Coathup about choosing a name for the testnet that will replace the Sepolia testnet in 2026. He directed call participants to offer suggestions and ideas on this in the dedicated Ethereum Magicians thread.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsement of any of the stablecoins mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned, hedged and sold or may own, hedge and sell investments in some of the digital assets and protocols discussed in this document. Affiliates of Galaxy Digital may also lend to some of the protocols discussed in this document, the underlying collateral of which could be the native token subject to liquidation in the event of a margin call or closeout. The economic result of closing out the protocol loan could directly conflict with other Galaxy affiliates that hold investments in, and support, such token. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email contact@galaxydigital.io. ©Copyright Galaxy Digital Holdings LP 2025. All rights reserved.