Ethereum’s Fusaka upgrade went live without major drama at the protocol level, but the hours that followed surfaced several unexpected behaviors across the network. None of the issues threatened overall chain safety, yet they exposed important lessons about client implementations, state regeneration, data availability, fork-choice behavior under stress & coordination between Execution Layer (EL) & Consensus Layer (CL) teams.

In the days after Fusaka, developers collected incident reports, shared preliminary analyses & started shipping mitigations. From Prysm’s participation drop to late-delivery reorgs & data availability warnings, the post-Fusaka period has already begun to shape priorities for future upgrades like Glamsterdam & Heka.

• Prysm Participation Drop
• Data Availability: Dasmon Missing Data
• Nethermind–Nimbus Validation Mismatch
• Late Delivery Reorgs & Fork Choice
• What It Means for Ethereum Going Forward

Prysm Participation Drop

The most visible Fusaka-related incident involved Prysm validators. Around epoch 411440, Ethereum’s attestation participation rate, i.e., typically around 97% suddenly fell to roughly 77%, a drop that closely matched Prysm’s estimated share of the validator set.

🚨 We have identified the issue and have a quick workaround. All nodes should disable Prysm to unnecessarily generate old states to process outdated attestation. To do this, simply add the following flag to your beacon node. This flag works with v7.0.0 and you do not need to…— Prysm Ethereum Client (@prylabs) December 4, 2025

Prysm nodes were being dragged into expensive work by stale attestations, which triggered regeneration of older states instead of operating on the most recent head. This behavior is related to a heuristic first introduced in Capella, where clients could reuse the head state when the target epoch matched the current epoch.

Fusaka’s refactor broadened what counted as a “valid checkpoint,” accidentally recreating conditions similar to the Capella-era outage. As this was happening:

• Fork choice produced many short, stale branches.
• Block delivery times grew significantly, starting around block 23937064.
• Some nodes switched away from the builder API & fell back to local block building to keep producing blocks.

Despite the disruption, the chain did not halt. Consensus continued, but overall participation looked unhealthy until Prysm operators applied a workaround.

Importantly, no client release or full resync was required. The network started recovering quickly once the configuration-based solution was communicated, & follow-up work is already underway to ship a robust fix along with a full post-mortem.

Data Availability: Dasmon Missing Data

Another post-Fusaka signal came from Dasmon, a data availability probing tool. After the upgrade, many probes reported missing data.

Preliminary analysis suggests that these reports are likely tied to late blob deliveries rather than a deeper structural failure. In other words, data did arrive, but not always within the ideal time window for the probes, causing them to flag “missing” results.

The relevant probes can be viewed here. For now, the incident has not been associated with widespread rollup failures or catastrophic data loss, but it has strengthened the argument for improving:

• Blob propagation pipelines
• Monitoring around data availability
• The tooling used to interpret & surface these metrics in real time

As Ethereum prepares for higher blob counts & more rollup activity, the post-Fusaka data from Dasmon has become a useful diagnostic hint.