Prysm Details Fusaka Mainnet Outage and 382 ETH Loss

Prysm nodes failed under heavy attestation load during Fusaka, causing ~18.5% missed slots, low participation and 382 ETH losses.

Out-of-sync attestations forced Prysm to replay old beacon states, triggering thousands of costly recomputations and resource exhaustion.

Prysm mitigated the issue with config flags and later releases, updating validation logic to avoid historical state replays.

Ethereum’s Fusaka mainnet upgrade faced disruption on December 4, 2025, after Prysm nodes failed during attestation processing. The issue occurred on Ethereum mainnet during the Fusaka upgrade window, involving the Prysm consensus client team. It happened due to resource exhaustion, which delayed validator responses and caused missed epochs, reduced participation, and validator reward losses.

Resource Exhaustion Disrupts Fusaka Epochs

During the incident, nearly all Prysm beacon nodes struggled to process specific attestations under heavy load. Notably, the problem affected epochs 411439 through 411480, spanning about 42 epochs. However, nodes failed to respond in time to validator requests, which caused missed blocks and attestations.

Across this range, the network lost 248 blocks from 1,344 slots. As a result, the missed slot rate reached roughly 18.5%. Network participation also fell sharply, dropping to a low near 75% during peak disruption.

Validators suffered measurable losses during the slowdown. According to the Prysm team, missed attestation rewards totaled about 382 ETH. These losses accumulated as validators could not submit proofs on time.

Out-of-Sync Proofs Led to Heavy Recomputations

According to the Prysm report, the root cause involved attestations from nodes likely out of sync. These proofs referenced block roots from previous epochs, not the current chain view. However, Prysm attempted full verification to meet Ethereum consensus rules.

To validate each proof, Prysm repeatedly rebuilt older beacon states. This process required replaying past blocks and performing expensive epoch transitions. Under high concurrency, nodes attempted hundreds of such recalculations simultaneously.

One example involved an attestation referencing block 0xc6e4ff from epoch 411441. Prysm replayed multiple state transitions to verify it. Notably, engineers observed this behavior nearly 4,000 times across infrastructure.

Fixes, Detection, and Ongoing Monitoring

During the incident, the Prysm team advised users to enable the --disable-last-epoch-target flag in version 7.0.0. This temporary measure reduced state recomputation pressure. Importantly, it avoided the need for an emergency client release.

Later, versions 7.0.1 and 7.1.0 introduced permanent fixes. These updates changed attestation validation to rely on the head state, avoiding historical replay. The team warned against using the --ignore-unviable-attestations flag.

Detection came through reports from core developers and users. Metrics showed rising replay counts, high resource usage, and failing gRPC requests. According to Miga Labs data cited by Prysm, client distribution shifted during recovery, highlighting ongoing diversity concerns.

The post Prysm Details Fusaka Mainnet Outage and 382 ETH Loss appears on Crypto Front News. Visit our website to read more interesting articles about cryptocurrency, blockchain technology, and digital assets.