The ACDC #161 call, held on July 24, 2025, brought Ethereum’s core development community together to review the progress of the Fusaka upgrade, evaluate Devnet 3 performance, and refine rollout plans for a mainnet launch before Devconnect. In parallel, developers laid the groundwork for the upcoming Glamsterdam fork, focusing on proposals that could serve as consensus-layer headliners.

Fusaka Upgrade Updates

Fusaka Devnet 2 was in its final stretch of testing. Developers discussed a series of simulated scenarios aimed at stress-testing network and client behavior. Specific issues emerged with two clients. Lodestar experienced rate-limiting problems, which stemmed from its lack of backfilling capability, i.e., essentially limiting its ability to sync to the chain head efficiently.

Nethermind repeatedly lagged by approximately two hours during sync attempts, across multiple testing sessions. These problems suggest deeper bottlenecks in client implementation that require further investigation.

Fusaka Devnet 3 Launched

Devnet 3 launched its genesis block just 24 hours before the ACDC #161 call. The next major step was the planned Fusaka fork, scheduled to activate shortly after the meeting. This fork introduces configuration aligned with the latest EIPs under test.

The developers expressed optimism that this iteration would provide stable results. If Devnet 3 runs smoothly, Ethereum clients could shift from experimental testing to hardening and preparing for release candidates.

A notable deviation from previous devnets was the introduction of rate limiting, simulating more realistic network environments. Bandwidth on 70% of full nodes was limited to 100 Mbps download and 15 Mbps upload. In contrast, 30% of nodes designated as “super nodes” were assigned a capped bandwidth of 1 Gbps, down from the 10 Gbps seen in earlier testing phases.

Prior devnets did not apply any such constraints, making this the first attempt to model real-world node performance under capped throughput. These limits are critical in understanding whether Ethereum’s infrastructure can sustain the data load introduced by blobs, MEV payloads, and future pipelining optimizations, i.e., particularly under constrained or non-ideal conditions.

Fusaka Mainnet Launch Planning

Alex Stokes laid out a timeline aiming for mainnet readiness by DevConnect Amsterdam in November 2025. The immediate goals are to stabilize Devnet 3 through July and August, followed by a phase of client hardening and bug fixes.

If achieved, this would allow release candidates to be distributed by the end of August, setting the stage for a testnet fork in early September. The Ethereum mainnet launch process follows a fixed security protocol that mandates a 30-day gap between a successful testnet fork and the final mainnet deployment.

By adhering to this cadence, the upgrade can be deployed safely and predictably. The core developers acknowledged that while this timeline is ambitious, it remains achievable if all client teams stay aligned and responsive.

Glamsterdam Upgrade Updates

The Glamsterdam network upgrade is Ethereum’s next major hard fork following Fusaka. As discussed in ACDC #161 (July 24, 2025), this upgrade aims to include one major EIP per protocol layer, serving as its “headliner.”

According to Alex Stokes, while Fusaka is being finalized, work on Glamsterdam will proceed in parallel. This strategic overlap is designed to enhance Ethereum’s development velocity while maintaining coordination between the Consensus Layer (CL) and Execution Layer (EL).

Glamsterdam Structure & Strategy

To maintain architectural clarity and development efficiency, the Ethereum core devs have agreed that Glamsterdam will feature a single anchor proposal or "headliner" per layer. The purpose is to ensure alignment across client teams while keeping the upgrade scope manageable.

While the community continues to test and stabilize Fusaka via Devnet 3, discussions and planning for Glamsterdam’s primary protocol changes are already underway. This dual-track process allows the ecosystem to move faster without compromising security or review processes.

Shorter Slot Times (EIP-7782)

EIP-7782 proposes reducing Ethereum’s current slot time from 12 seconds to 6 seconds. The goal is to enhance user experience by delivering faster transaction finality and improving throughput responsiveness.

During ACDC #161, Maria presented early findings from her team’s research on whether such a change would be technically feasible. Her study measured three key metrics:

  • block propagation time
  • attestation arrival time (which includes block propagation, execution, and validation), &
  • pure attestation propagation during missed slots.

According to the initial results, the 95th percentile for block propagation time was under 1 second for well-connected nodes. Additionally, the 95th percentile of the 95th percentile for full attestation arrival time was recorded below 4.5 seconds, i.e., an encouraging sign, though still tight.

However, a notable delay was observed among the last 10% of attestations, which arrived significantly later and could present a risk under shorter slot conditions. During the call, core developers expressed a range of opinions.

Potuz raised concerns that these delays might make 6-second slots unsafe. Dankrad Feist clarified that the use of p95 metrics was observational and not prescriptive, reinforcing that Ethereum is not strictly optimizing against those metrics.

Meanwhile, Toni Wahrstätter pointed out that PTC (Parallel Time Construction), while useful, introduces additional latency due to BLS verification, i.e., something that would need to be factored into final calculations. Maria emphasized that these results are preliminary and do not yet provide a definitive yes or no answer.

Her team plans to collect a wider dataset from additional relays and community-operated nodes, particularly to better understand the impact of block size, gas usage, and the reasons behind attestation delays. The Ethereum community continues to study this area closely before making any decisions on implementing six-second slots.

ePBS (EIP-7732) & The “Free Option Problem”

EIP-7732 proposes a consensus-level enshrinement of Proposer-Builder Separation (PBS), aiming to decentralize Ethereum’s MEV (Maximal Extractable Value) landscape by formalizing the separation of block proposers and builders. During the ACDC #161 call, Christoph and Bruno from Flashbots presented a detailed analysis of a risk inherent in this approach & what they termed the “free option problem.”

The issue arises because builders are given two deadlines to deliver a payload and blobs. They can exploit the second deadline, particularly the 10-second window for blob submission, to strategically invalidate a block after market conditions have changed. If a builder realizes that their previously submitted block is no longer favorable (for example, due to new price action or MEV opportunities), they can choose not to submit the blob and cause the block to be discarded.

This creates a “free option” that is asymmetrical and exploitable under conditions of market volatility and high liquidity. Flashbots simulated the economic value of this option using Binance trading data and found that such a mechanism could yield more than $1.2 million per day in arbitrage profits if Ethereum matched Binance-level liquidity.

The longer the option window remains open, the more dangerous and valuable this exploit becomes. Christoph pointed out that this risk becomes worse, not better, as Ethereum grows more successful, liquid, and volatile.

To mitigate this, several strategies were proposed.

  • One is to shorten the free option window by synchronizing payload and blob deadlines.
  • Another is to impose slashing penalties on builders who fail to deliver required data.
  • A third, less favored option is to block-list offending builders, though this threatens the permissionless nature of Ethereum’s builder ecosystem.
  • A more radical proposal is to completely decouple blobs from transaction blocks and establish separate fee markets for each, though this is still conceptual.

Headliner EIP Candidates – CFI’d

To keep development focused, the community agreed to CFI (Consider for Inclusion) three proposals as candidates for Glamsterdam’s Consensus Layer headliner. These are:

  • EIP-7732: Enshrined PBS (ePBS) to formalize block builder separation and improve MEV handling.
  • EIP-7782: Six-second slots to reduce confirmation latency and improve UX.
  • EIP-7805: FOCIL, which introduces fork-choice improvements that aim to reduce chain instability during latency spikes.

The final decision on which of these will become the official Glamsterdam CL headliner is scheduled to be made at ACDC #162 on August 7, 2025. Until then, all three EIPs will remain under active consideration, with core developers and community stakeholders continuing to evaluate feasibility, tradeoffs, and ecosystem impact.

Community Feedback Highlights

Community feedback played an important role in shaping the discussion. Lion⟠dapplion .eth suggested a modular approach to EIP-7732 by splitting it into two phases:

  1. slot restructuring as EIP-7732A, &
  2. trustless builder payments as EIP-7732B.

This would allow the network to adopt critical structural reforms while deferring the more complex MEV-market mechanics for future forks.

TimBeiko and Alex Stokes supported the idea of conditionally endorsing all three CFI's proposals for now and narrowing them down in the next core dev call. Their rationale was that giving early clarity on potential headliners helps Execution Layer teams plan their corresponding work.

Some participants felt ePBS was receiving more support from developers, while the broader community may have been leaning toward six-second slots. Dankrad Feist suggested creating a more centralized, canonical venue for community opinion collection, such as a dedicated EthMagicians thread.

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.