After the Fusaka hard fork, the Prysm client encountered issues, but Lido withstood the impact thanks to its client diversification strategy.

[Fusaka Hard Fork] Just after the Fusaka hard fork was implemented, a vulnerability was discovered in the Prysm consensus client, causing some participation issues across the network. However, things have remained quite stable on Lido’s side—the protocol has been running normally throughout, so stakers don’t need to worry.

The impact of this incident is actually not as big as one might think. This is mainly because validators are already deployed in a decentralized manner at the base layer, and both the Prysm team and node operators reacted quickly. As a result, Lido was less affected compared to other large staking solutions. According to the previous “Q3 2025 Validator and Node Operator Metrics” report, about 15% of node operators’ validators were running Prysm—this approach of not putting all your eggs in one basket really pays off in critical moments.

Most of the Prysm nodes that encountered issues either added the --disable-last-epoch-targets parameter or temporarily switched to other client configurations, and now most of them have basically recovered. This incident once again proves that client diversity is not just for show—it can truly be a lifesaver when single points of failure occur.