Aniket Pujari
Prysm developers released a post-mortem analysis explaining the December 4 Fusaka mainnet incident that threatened Ethereum network stability.
Summary
- A Prysm bug after Fusaka caused validator participation to drop to 75%.
- The network missed 41 epochs and lost roughly 382 ETH in proof rewards.
- Ethereum avoided finality loss thanks to client diversity and rapid fixes.
The consensus client suffered resource exhaustion from expensive state recomputation when processing specific attestations, causing validators to face severe operational problems.
The bug surfaced immediately after Fusaka activated at epoch 411392 on December 4, 2025, at 21:49 UTC.
The network missed 41 epochs as validator participation plummeted to 75%, resulting in approximately 382 Ethereum (ETH) in lost proof rewards. Prysm developers deployed emergency runtime flags before implementing permanent fixes in versions v7.0.1 and v7.1.0.
Resource exhaustion pushed network toward finality loss
The technical failure centered on obsolete historical states that created denial-of-service conditions on affected nodes.
Prysm core developer Terence Tsao explained that “historical state is compute memory heavy, a node can be dosed by large number of state replays happening in parallel.”
Validators running Prysm, which represented roughly 15% to 22.71% of network validators, faced crippling performance degradation. The participation drop from normal levels above 95% to 75% pushed Ethereum dangerously close to losing finality.
Had the bug affected a different consensus client like Lighthouse instead of Prysm, the network could have lost finality entirely.
Such an event would potentially freeze Layer 2 rollup operations and block validator withdrawals until developers resolved the issue.
The Fusaka upgrade itself introduced PeerDAS (Peer Data Availability Sampling) technology designed to increase blob capacity eightfold for Layer 2 scaling.
The upgrade executed successfully with zero downtime before the Prysm bug surfaced.
Ten consensus clients prevented Ethereum network collapse
Ethereum’s client diversity architecture prevented catastrophic failure. While Prysm validators struggled, ten other consensus clients including Lighthouse, Nimbus, and Teku continued validating blocks without interruption.
The decentralized client structure meant that roughly 75% to 85% of validators maintained normal operations throughout the crisis. This prevented finality loss and kept the network processing transactions despite Prysm’s degraded state.
The Ethereum Foundation quickly issued emergency guidance for Prysm operators. Validators applied the temporary fix while Prysm developers built permanent solutions.
By December 5, network participation recovered to nearly 99%, restoring normal operations within 24 hours of the incident.
