Highlights from the All Core Developers Consensus (ACDC) Call #167

Ethereum’s All Core Developers Consensus (ACDC) Call #167 focused on the Fusaka rollout, confirming stable Devnet performance, smooth Holesky & Sepolia forks, and completion of the security contest with no critical issues.

The call also discussed bandwidth optimization for blob retrieval, exploring lighter supernode configurations and EL-based tracking to cut custody costs. With testing nearly complete, Fusaka remains on track for its December 2025 mainnet launch.

• Fusaka Updates
• Glamsterdam Updates
• Miscellaneous Updates

Fusaka Updates

The call opened with a review of Fusaka Devnet-3, which continues to run smoothly with only minor issues reported. A few bugs concerning database usage & blob-dropping on the server side had been identified earlier, but developers confirmed that these were now resolved.

The network remains stable, showing no major client regressions. Overall, the discussion reflected confidence in Devnet-3’s health as it moves closer toward production readiness.

Both the Holesky and Sepolia fork were executed successfully, marking an important phase in testing. While there was some turbulence on the operational side, no critical issues arose in client behavior.

The Fusaka security contest, which ran until October 13 2025, concluded successfully with no high-severity findings that would justify postponing the mainnet upgrade. Reviewers are now finalizing the severity classification of discovered issues, and a complete vulnerability list will be made public within the next few weeks.

The consensus on the call was that Fusaka’s codebase appears robust & the upgrade can move forward on schedule.

Core Developers emphasized that rollups must treat Devets as genuine staging environments rather than production systems. Many L2s use public testnets for live operations, which limits their ability to catch last-minute issues.

Core devs suggested encouraging rollups to deploy against late-stage DevNets (like DevNet-3) for feature validation. The idea of reviving a long-lived user-testing network, similar to the historic “Mekong” testnet, was discussed but recognized as difficult due to the faster release cadence for Fusaka.

A significant portion of the call focused on bandwidth optimization for blob retrieval. Representatives from Aztec highlighted difficulties faced by decentralized sequencers in retrieving blobs efficiently without running supernodes, which demand high bandwidth & custody costs.

Several solutions were explored:

• “Light supernode” mode, where a node subscribes broadly but stores only a minimal set of columns sufficient for blob reconstruction.
• EL-side tracking, enabling the execution layer to store blobs from transactions relevant to that rollup.
• Mempool fallback, where many blobs can be sourced from the un-sharded public mempool, with consensus-layer fallback for redundancy.
• Storage trade-offs, where nodes store more proofs (cheap) and fewer cells (costly), cutting resource usage by nearly 50%.

ACDC Call #167 is Live!

🗓️ Oct 16, 2025 at 14:00 UTC

Agenda:
• Fusaka devnet-3 updates
• Holesky BPO2 & Sepolia fork
• Blob APIs & custody columns
• Fusaka mainnet timeline
• Trustless payments in ePBS
• EIP-7688 & Glamsterdam

🔴 Live stream with @ECHInstitute
▶️…

— Pooja Ranjan | ranjan.eth (@poojaranjan19) October 16, 2025

Glamsterdam Updates

As the Fusaka upgrade nears mainnet readiness, the developer community has turned its focus toward Glamsterdam. One of the most debated topics in ACDC #167 was whether Trustless Payments should remain integrated with enshrined Proposer-Builder Separation (ePBS) or be separated into an independent EIP.

Trustless Payments provides an on-chain settlement mechanism between block builders & validators, a step toward reducing reliance on off-chain relay coordination. Others proposed creating standardized off-protocol payment frameworks within clients to mitigate the disruption of shipping Trustless Payments in V1.

Liquid-staking operators such as Lido and Rocket Pool noted that if both off-chain and on-chain payment paths coexist, they will need enhanced monitoring & auditing pipelines. In the end, the group reached a pragmatic consensus: retain Trustless Payments bundled with ePBS for Glamsterdam V1, focus on completing the integrated spec, and reserve structural redesign for a potential V2.

Locking in ePBS with Trustless Payments naturally consumes much of the consensus-layer engineering bandwidth. Several participants observed that this limits the possibility of including other heavy features.

Beyond the headliner, EIP-7688 has been Proposed for Inclusion (PFI’d) for Glamsterdam. However, the group decided to postpone any formal inclusion decision until the Fusaka mainnet date is fully set.

The primary risk identified is scope creep: adding further consensus features could delay the upgrade and strain validation pipelines. To mitigate this, developers agreed to treat ePBS + Trustless Payments as locked and apply strict evaluation criteria for any new additions.

Client developers should now proceed with ePBS + Trustless Payments V1 implementation and target early Devnet deployments later this year once Fusaka stabilizes. Builders & relay operators need to begin testing on-chain settlement flows and ensure fallbacks for off-protocol paths in accordance with new client standards.

Staking protocols must adapt their accounting & monitoring systems to handle dual payment flows, starting with sandboxed testing environments. Infrastructure providers and L2 teams should monitor the status of PFI’d EIPs like 7688 but avoid assuming their final inclusion until post-Fusaka triage is complete.

Governance Updates

Ethereum’s governance process enforces a disciplined upgrade sequence beginning with feature design, Devnet testing, and moving through public testnets before any mainnet activation is considered. Each ACDC or ACDE call performs a “temperature check” first, i.e., an informal signal of readiness which is followed later by a formal decision once all clients are upgraded, bugs resolved, and communication plans cleared.

This prevents premature commitments and ensures that the broader ecosystem (client teams, rollups, infra providers) can align around stable milestones without last-minute regressions. Coordination between the Consensus Layer (CL) and Execution Layer (EL) is central to Ethereum’s upgrade cadence. Many proposed EIPs affect both layers simultaneously, such as changes to blob handling or RPC endpoints.

Each side is expected to publish clear release notes, with Editors ensuring that spec documents and EIPs explicitly record any breaking or behavior-altering changes. This cross-team transparency avoids fragmented implementations and reduces user confusion during testnet rollouts.

A recurring theme from ACDC #167 was the need for better communication hygiene. To prevent future confusion, EIP authors and EF editors were urged to document RPC impacts directly inside the specification and summarize them in EF blog posts.

The Ethereum governance workflow promotes Devnets as true staging environments, allowing both client teams and external rollups to verify upgrades before the more public testnets fork. This approach ensures that changes like new blob APIs or custody logic are validated under realistic conditions.

The governance model organizes proposals through a three-stage funnel: PFI (Proposed for Inclusion), Inclusion, and finally Release. PFI status signals community and client interest but stops short of formal commitment, allowing exploratory work and inter-client testing.

Actual inclusion decisions are postponed until the immediate upgrade reaches mainnet stability to avoid overlapping priorities. Meta-EIPs, such as EIP-7773, collect dozens of candidate features for later triage, helping the community track potential innovations while maintaining focus on the current cycle’s deliverables.

For client & infrastructure teams, governance best practice is to monitor GitHub PM threads for every temperature check or release date adjustment, verify all RPC changes even if EIPs claim backward compatibility, and treat the latest DevNet as mandatory staging before public testnet deployment. Using public testnets for dry-runs of operational workflows ensures a seamless transition once the upgrade reaches mainnet.

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