The recent ACDC #160 call on July 10, 2025 focused on raising the gas limit to 45 million, reviewing Fusaka Devnet 2’s status & bug fixes, and locking in July 21–22 as the “happy-path” stress test for DevNet 3.

The meeting also debated Engine API v3 blob semantics & a Builder API payload change, outlined the PeerDAS/mainnet roadmap, planned blob throughput scaling via BPO forks, and chose a single “headliner” EIP for the Glamsterdam upgrade.

Gas Limit Updates

Most client teams agreed that the protocol-level gas limit should be increased to 45 million for improved throughput without compromising node stability.

  • Prysm plans to ship the 45 M bump “by next week.”
  • Nimbus has its 45 M update “imminent.”
  • Lodestar is actively testing the 45 M increase in its CI pipelines.
  • Lighthouse merged its bump yesterday/today & will include it in the next minor release.

Rather than enforce a hard deadline, the group discussed a soft target of “end of July” for all CL clients to have the new limit live, ensuring applications & tooling could adjust uniformly.

Fusaka Devnet 2 Status & Devnet 3 Preparation

During Devnet 2, client teams conducted daily health checks and uncovered several cross-client bugs. For example, Nimbus nodes experienced a P2P negotiation issue that caused repeated connect/disconnect churn, although this bug was confined to Nimbus and did not impact other execution-layer clients.

To address these issues, the client teams agreed on an expedited remediation schedule. Nimbus and Lodestar deployed immediate patches midweek and began running daily CI tests to verify improvements in connectivity metrics. Meanwhile, churn-rate dashboards in the ACDC channel are updated each morning, showing validator participation climbing from approximately 82 percent at the beginning of the week to around 87 percent following the fixes.

Post-patch metrics indicate that Devnet 2 is in a healthy maintenance state, block proposal success for correctly configured nodes remains above 99.9 percent. The network will continue running through the end of the week to validate that no regressions occur before moving on to the next phase.

Core Devs have agreed to activate Devnet 3 on July 21–22, 2025. To ensure a smooth rollout, the spec will be frozen by July 17, allowing four full days for final integration testing. There are no plans to have Devnet 4.

engine_getBlobsV3 Proposal

EL teams found that the current V2 engine_getBlobs API was too permissive, clients could choose whether or not to return partial blob data, leaving consensus layer (CL) implementations unable to depend on it. To solve this, Raul proposed restoring V2 to its original all or nothing behavior & creating a new V3 endpoint that would require EL clients to emit partial blobs.

CL clients would hold off on using V3 until after Fusaka’s activation, giving EL teams time to implement & test the new behavior without disrupting the upcoming fork. When debating the spec change, participants weighed validation needs against timing risks.

Some, like mkalinin, worried that without CL consumption there’d be no easy way to test V3, but ralexstokes pointed out that EL only tests could catch any issues. Others, including Barnabas, urged caution about introducing a core API change so close to Fusaka, while vdWijden & raulvk argued it was straightforward & could align with the Osaka hard fork for smoother coordination.

In the end, the group approved merging the PR #674 at & agreed to perform primary testing on the EL side before any CL clients adopt V3. The rollout plan focuses on a short window between Fusaka & Glamsterdam.

GetPayload Change

The current Builder API’s GetPayload call bundles both the execution payload & blob bundles into a single synchronous response. As BPOs expand, this all-in-one endpoint could become a performance bottleneck for proposers.

To optimize proposer workflows & offload blob distribution, the proposal is to simplify GetPayload so that it returns neither execution payloads nor blobs. Instead, relays would take full responsibility for serving blobs, decoupling payload retrieval from blob delivery.

During the call, every client team expressed support for dropping payload data from the GetPayload endpoint. The change is formally tracked in the Builder specs repository under pull request builder-specs#123.

With unanimous consensus, the specification update is now ready for implementation across all participating clients. Testing is slated to begin immediately.

Roadmap to Fusaka Mainnet, PeerDAS Plan & BPO Rollout

To articulate the PeerDAS strategy, the Sigma Prime team published a detailed blog post “Shipping PeerDAS” which lays out the rationale, design trade offs, and implementation recommendations for bringing PeerDAS to mainnet. You can read it here. Before committing to mainnet, it is critical to validate Beacon Chain sync performance without finality.

To that end, teams will spin up non finality testnets (that is, disabling finalization) to measure sync rates, failure modes and gossip resilience under adversarial conditions. Furthermore, to guide BPO parameterization, core devs emphasized deploying large scale test networks of at least 1,000 nodes, far above the typical 50 to 100 node setups, to collect meaningful data on propagation delays, block root attestations and overall network health.

Based on feedback in the call and the Sigma Prime planning section, the working hypothesis is a mainnet fork around mid October 2025, contingent upon testnet stability. To introduce higher blob throughput without destabilizing the network, the team agreed on a two-step BPO rollout strategy.

Glamsterdam Headliner Discussion & Selection Process

Core devs agreed on a "one headliner per layer" rule for the Glamsterdam upgrade i.e. one consensus layer (CL) feature and one execution layer (EL) feature will carry the fork.

Here is a list proposed CL headliners include:

Key viewpoints voiced in ACDC 160 included:

  • adietrichs favoring a slot time reduction first deferring ePBS,
  • dapplion arguing for shorter slots plus FOCIL while holding ePBS until after initial scaling wins,
  • nero_eth emphasizing EL and CL coordination irrespective of the chosen EIP,
  • sauliuseth reminding the group to focus on the change they wanted not just the EIP number, &
  • dankrad suggesting cutting slot slack to force clarity on ePBS and DE trade offs.

These varied perspectives underscored the importance of gathering broader stakeholder input especially from users and application teams not typically active in ACDC or ACDE channels.

Looking ahead, the target decision date is July 24 2025 for selecting the CL headliner, with parallel EL headliner decisions to follow in ACDE calls.

The process will unfold in two stages:

  • first, a discussion call in this week’s ACDE to narrow the candidate set based on DFI feedback; &
  • second, a decision call one to two weeks later to formally CFI of the chosen headliner.

Core devs will merge the engine_getBlobsV3 PR #674 and update the builder specs PR #123 to begin multi client testing. Core devs will launch large scale PeerDAS testnets such as Sepolia in August and Holesky in September leading into a mid October mainnet fork.

Core devs will execute a two phase BPO rollout with BPO 1 at approximately 8 to 12 one week after Fusaka and BPO 2 at approximately 16 to 24 one to two months later. The ACDE call this week will focus on Glamsterdam headliner discussion and stakeholder input followed by a decision call to finalize both the consensus layer and execution layer headliners.

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.