At the All Core Developers Execution (ACDE) Call #217, Ethereum client teams & researchers gathered to review progress on the Fusaka upgrade & discuss critical decisions shaping Ethereum’s near-term roadmap. The call covered stability updates from Fusaka Devnet-3, an intense debate around the proposed transaction gas limit cap (EIP-7825), alignment on the rollout schedule through testnets into a November mainnet activation, planning for the Glamsterdam upgrade headliners such as block-level access lists (EIP-7928) & ePBS (EIP-7732), and a review of upcoming security audits & adversarial tests.

Fusaka Upgrade Updates

Fusaka Devnet-3 has now reached a point of relative stability, recording approximately 94% validator participation across clients. This is a crucial milestone, as validator participation is the primary measure of testnet health.

High participation means that consensus-layer and execution-layer clients are producing, propagating, and finalizing blocks consistently. With this level of performance, the development teams are confident in moving closer to rolling out the Fusaka upgrade on larger public testnets such as Sepolia and Holesky, which are precursors to eventual mainnet activation planned for November.

Despite the overall stability, individual client teams continue to work through lingering bugs.

  1. Lodestar, one of the consensus-layer clients, is grappling with a P2P networking library bug that has been under active debugging for weeks.
  2. Meanwhile, Nimbus recently faced a MEV-related bug, which affected its block production under MEV-enabled conditions, though this issue has now been patched.
  3. Prysm is also monitoring its MEV-related issues and is expected to push fixes in the next update.
  4. On the execution layer side, Reth encountered a non-client bug in its interaction with Builder for transaction relaying, underscoring the importance of cross-tooling interoperability testing across different implementations.

These bugs do not threaten the protocol itself but highlight how diverse client ecosystems need to converge on common stability before a coordinated network upgrade like Fusaka can be considered production-ready.

To ensure readiness before pushing Fusaka to major testnets, two critical categories of testing are being prioritized.

  1. The first is Perfect Peer-to-Peer testing, designed to verify that block and blob data are consistently propagated across all consensus-layer clients (Lighthouse, Teku, Nimbus, Prysm, and Lodestar). This test is especially significant because the Fusaka upgrade includes EIP-4844 (Proto-Danksharding), which introduces “blobs” as a new type of transaction payload.
  2. The second major area is Non-finality Testing, which simulates conditions under which the network cannot finalize blocks. This helps measure how clients recover, how validators respond under stress, and how fork choice logic operates when finality is delayed. Such testing became critical after incidents like the Ethereum mainnet’s non-finality events in May 2023, which revealed vulnerabilities in validator coordination.

The Holesky testnet has been identified as the most likely candidate for non-finality testing, due to its large validator set that closely mirrors mainnet scale. Together, these tests will provide the confidence needed to proceed with the proposed Fusaka rollout schedule in September.

Transaction Gas Limit Cap Debate (EIP-7825)

The transaction gas limit cap proposal, formally introduced as EIP-7825, seeks to impose a hard ceiling on the gas consumption of individual transactions. Proponents argue that such a cap is critical to prevent individual transactions from monopolizing block resources, thereby unlocking the possibility of parallel execution in the future.

The Ethereum developer community has raised significant concerns about the proposal, most prominently voiced in the Ethereum Magicians discussion thread. Developers from 0x, a DEX aggregator, explained that swap transactions that touch multiple liquidity pools can easily surpass the 16.8M threshold, especially in fragmented liquidity environments.

Beyond DEX use cases, other workflows such as batch ENS registrations or batch payout contracts are also likely to be disrupted by this cap. Another recurring criticism was that the proposal surfaced too late in the Fusaka upgrade cycle, leaving little time for ecosystem-wide adaptation and impact analysis.

Supporters of the gas cap argue that the benefits far outweigh the disruption. Large single transactions increase exposure to Denial-of-Service (DoS) attacks, where quadratic execution costs could compromise the network.

By bounding transaction size, Ethereum can mitigate such risks. The cap also makes it possible to design execution environments that leverage parallel processing, since smaller, more evenly distributed transactions can be spread across multiple cores.

Opponents of the cap argue that it introduces a breaking change for existing applications, particularly DeFi protocols that require high gas transactions to function effectively. Critics emphasize that competitiveness may be undermined, as users might migrate to alternative chains like Solana, which already handle complex transaction structures differently.

Vitalik Buterin contextualized the debate by pointing to past precedents where Ethereum introduced breaking changes that ultimately benefited the ecosystem. The removal of SELFDESTRUCT, for example, forced adaptations but simplified client development in the long run.

He stressed that limits like the one in EIP-7825 could enable future enhancements such as stateless clients, multidimensional gas pricing, and more robust parallel execution models. However, Vitalik also acknowledged that breakage severity must be judged by how many users are affected and the criticality of those use cases.

Fusaka Rollout Schedule & Upgrade Timeline

The Fusaka rollout schedule has been carefully designed to balance client readiness, ecosystem preparedness, and alignment with Ethereum’s broader developer calendar. The plan begins with the release of Fusaka-ready client binaries on September 1, 2025, which will integrate critical changes such as EIP-4844 (Proto-Danksharding blobs) and the debated gas limit cap under EIP-7825.

Following this release, a phased rollout across testnets is scheduled:

  • Holesky will fork between September 15–18, 2025, serving as the key environment for non-finality and blob propagation testing,
  • Sepolia will fork shortly after on September 22–25, 2025, ensuring dApp developers and infrastructure providers can test applications against Fusaka rules.
  • The final testnet rollout is planned for Hoodi on October 13–16, 2025, offering an additional stability checkpoint before mainnet activation.
  • If all goes according to plan, the Ethereum mainnet will activate Fusaka between November 3–6, 2025, just ahead of Devconnect, ensuring the developer community can assess early mainnet outcomes in person.

Client teams expressed both support and caution regarding this ambitious schedule. Teams like Lighthouse and Nimbus noted that while a September 1st release is “aggressive but doable,” they emphasized the need for at least an extra week of adversarial testing to ensure Fusaka stability under hostile network conditions.

Importantly, Holesky is expected to be deprecated after Fusaka, meaning infrastructure operators must prepare migration plans well in advance. This sequencing reflects a balance between ensuring robust validator-level testing and maintaining application developer confidence.

While a tentative roadmap has been sketched, client teams agreed that the final rollout order and dates must be locked by the August 7 ACDC call. This confirmation is crucial to align several moving pieces: security reviews, adversarial testing, and application ecosystem preparedness.

Once the dates are finalized, infrastructure providers such as Infura, Alchemy, and exchange validators will be able to plan their deployments across Sepolia and Hoodi, while dApp and wallet developers can begin testing Fusaka compatibility in a structured manner.

Glamsterdam Upgrade Planning

One of the strongest candidates for the Glamsterdam upgrade on the execution layer side is Block-Level Access Lists (BALs). This proposal, described in EIP-7928, extends the idea introduced by Access Lists in EIP-2930, but moves from the transaction level to the block level.

The proposal has received strong community & developer support. Feedback gathered on the Ethereum Magicians forum highlights BALs as a “low-risk, high-value” headliner for the execution layer. Major client teams including Geth, Besu, and Erigon have already signaled support, and there is even a plan for a dedicated testnet (“BALs-devnet-0”) later in August to begin practical validation, as noted in the GitHub PR #10083.

While consensus is clear on BALs for the execution layer, the consensus layer headliner remains a matter of debate. Two competing proposals are under consideration.

The first, Enshrined Proposer-Builder Separation (ePBS), is outlined in EIP-7732. Client teams and many researchers have shown strong support for ePBS, describing it as the most forward-looking choice for Ethereum’s long-term resilience.

The alternative is Delayed Execution (DE), introduced in EIP-7862 and further refined in EIP-7886. This mechanism would defer the execution of transactions until the following slot, meaning validators could attest to block validity without executing all included transactions in real-time.

Proponents argue that delayed execution simplifies validator duties, brings ~80% of the scaling benefits of ePBS, and helps L2s by smoothing execution of precompiles. However, it does not scale blobs as effectively as ePBS, and some developers worry that introducing delayed execution may complicate testing without providing the full benefits expected from PBS integration.

The final choice of consensus-layer headliner will directly affect the execution-layer selection. If the community chooses ePBS, then BALs will almost certainly be locked in as the execution-layer headliner for Glamsterdam, as the two are complementary.

Following this, execution-layer developers will confirm BALs as the headliner if ePBS is selected, and work will proceed on benchmarking the different BAL variants. If Delayed Execution gains enough traction, however, further specification refinement will be required before BALs can be fully confirmed.

Security Reviews & Audits

Security reviews in Fusaka and Glamsterdam upgrades are meant to ensure that no single client crashes under heavy load, validators continue to finalize blocks even under stress, and all consensus- & execution-layer clients remain aligned on the same chain. They also safeguard against potential denial-of-service vectors, particularly from new transaction rules like the gas cap introduced in EIP-7825, and ensure backward compatibility so that existing dApps do not break in unintended ways.

The scope of reviews spans multiple critical changes.

  • The blob transactions introduced under EIP-4844, which form the heart of the Fusaka upgrade, must undergo extensive P2P stress testing to confirm that blob-heavy blocks can propagate reliably without leaving validators behind.
  • Beyond Fusaka, Glamsterdam headliner EIPs are equally under review. The introduction of Block-Level Access Lists (EIP-7928) requires benchmarking both read+write and write-only variants to determine trade-offs between block size and prefetch efficiency.
  • Meanwhile, the consensus-layer debates around enshrined proposer-builder separation (EIP-7732) and delayed execution (EIP-7862, EIP-7886) are being examined for long-term implications, such as MEV relay behavior, validator incentives, and the “free option” problem.

The current target is for all clients to release Fusaka-ready binaries by September 1, 2025, but client teams have already flagged this as aggressive. For example, the Lighthouse and Nimbus teams have requested at least one additional week of buffer for adversarial testing before forks on Sepolia, Holesky, or Hoodi are launched.

This buffer would allow them to address last-minute stability issues without putting the mainnet timeline at risk. The security testing strategy is designed to be multilayered and redundant.

Adversarial testing will push clients to blob maximum loads, with past Devnets already having stress-tested scenarios such as 72 blobs per block. Non-finality testing, scheduled for Holesky, will simulate conditions where finality is intentionally stalled for long periods, validating fork-choice safety and validator recovery.

At the code level, formal audits of client implementations are expected, focusing on new Fusaka and Glamsterdam logic. Together, these methods aim to ensure that if one layer of review misses a bug, another layer will catch it.

Several upgrade decisions hinge directly on the outcomes of these reviews. The transaction gas cap EIP-7825 will have its final call during the August 4 ACDT testing call, where developers expect updated analysis from DEX aggregators like 0x.

The custody adjustment in PR #4477 has already been deferred, precisely because it was deemed too late in the Fusaka cycle to conduct the necessary validation. For Glamsterdam, the final decision between ePBS (EIP-7732) and delayed execution (EIP-7862) will come at the August 7 ACDC call, and here too, security feasibility will weigh heavily in the outcome.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

Related Articles

  1. Highlights of Ethereum's All Core Devs Meeting (ACDC) #153
  2. Highlights of Ethereum's All Core Devs Meeting (ACDE) #207
  3. Highlights of Ethereum's All Core Devs Meeting (ACDC) #152
  4. Highlights of Ethereum's All Core Devs Meeting (ACDE) #206
  5. Highlights of Ethereum's All Core Devs Meeting (ACDE) #205
_____________________________________________________________________

Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.

For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Share if you like the content. Donate at avarch.eth.

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.