ACDC #171 on 11 December 2025 ended up being one of those calls where routine status updates slowly turned into bigger questions about how Ethereum should move forward. What began as a simple post-Fusaka review quickly opened into a wider conversation about upgrade pacing, how closely the community should adhere to the new process rules, & how to balance expectations that have been building across the ecosystem for months.

During the call, developers walked through Fusaka’s early behaviour on mainnet, tied up the last loose ends for the Glamsterdam fork, debated the path forward for FOCIL, & set the timeline for choosing headliners for the upcoming Heka/Bogotá upgrade.

• Fusaka Updates
• Glamsterdam Updates
• Heka/Bogotá Updates

Fusaka Updates

The call opened with a retrospective on Fusaka’s mainnet rollout, which core devs described as “smooth overall,” reinforced by successful testing during BPO1 just days earlier. But not everything was frictionless. Prysm users reported attestation drops tied to disk-write bottlenecks.

Prysm shipped a quick-fix hotpatch (7.0.1) along with feature updates, while Teku developers signalled more refinements coming in the next week.

Prysm v7.1.0 is now live

If you're still on v7.0.0, move to v7.0.1 or later and drop the flag --disable-last-epoch-targets

Highlights:

1. Backfill for Fulu

Checkpoint sync now backfills data columns. Turn it on with --enable-backfill.

2. Semi supernode mode… pic.twitter.com/2NC7yJWVtI— Prysm Ethereum Client (@prylabs) December 10, 2025

Glamsterdam Updates

A key agenda item was Trustless Payments, a critical part of the ePBS design for Glamsterdam. Across several ACDC calls and breakout discussions, builders and raised concerns about how the feature would operate in practice, especially with respect to staked relays and their churn behaviour.

Despite the concerns, no one identified a security issue serious enough to justify removing the feature. With that in mind, developers confirmed that Trustless Payments will remain in the Glamsterdam upgrade.

Core developers also noted the community fatigue created by the long debate, but said that the wide range of feedback ultimately strengthened their confidence in keeping the feature. One of the more technical discussions centered on whether builders should continue to operate as validators.

Builder teams suggested a different model where they would keep their stake but not act as validators. This would let them enter the system more quickly without churn delays, while still ensuring they have funds at risk if they behave incorrectly.

Removing validator duties, however, comes with clear tradeoffs.

1. It would help avoid churn bottlenecks and create a cleaner protocol surface, and in some cases it would simplify parts of the design.
2. But it would also remove the ability for validators to submit bids, weaken the fallback guarantees that rely on self building, and force changes to several parts of the ePBS architecture.

Because this idea touches core assumptions about how block production stays decentralized, developers agreed that it needs deeper examination in dedicated ePBS breakout calls.

The longest segment of ACDC #171 revolved around FOCIL. FOCIL has strong support from L2s, intent-protocol designers, & censorship-resistance researchers. But the process for including it in Glamsterdam or HEKA created intense disagreement. FOCIl strengthens guarantees for protocols that rely on timely inclusion:

• Optimistic rollups
• Intent settlement layers
• Prediction markets
• Exit windows in staking & bridging protocols
• Any system with challenge periods or fraud-proof timers

Analysis cited during the call suggested FOCIL improves censorship-resistance economics by roughly an order of magnitude in certain attack models, by making it far more expensive for an attacker to keep censoring a target transaction compared to the honest user’s cost to fight back.

Ethereum recently adopted a structured headliner-first upgrade process. Short-circuiting that process by pre-declaring FOCIL’s inclusion risked undermining the very governance reforms that were meant to stabilize the upgrade pipeline.

Some participants argued that “credible commitments” to ship a feature must not override the shared rules of decision-making. After an extended debate, the room converged on a compromise:

• FOCIL is DFI for Glamsterdam (Deferred for Inclusion, not shipped in this fork).
• FOCIL is CFI for HEKA (Considered for Inclusion in the next upgrade).

By the end of the call, Glamsterdam’s scope was essentially locked.