Be cautious of staking risks: if you use Geth for staking, you could potentially lose all your assets
TechFlow Selected TechFlow Selected
Be cautious of staking risks: if you use Geth for staking, you could potentially lose all your assets
The article highlights the Geth client's supermajority position in the Ethereum network and the potential risks this entails.
Navigating Web3 tides with focused insightsAuthor: Labrys
Translation: TechFlow
This article discusses a recent incident involving the Nethermind execution client on the Ethereum network, which caused all validators using Nethermind—approximately 10% of the network—to go offline. The article emphasizes the dominance of the Geth client on Ethereum and the associated systemic risks. While Geth is stable and reliable, its widespread adoption means that any critical failure could have severe consequences for the entire network. The article calls on the community to prioritize execution client diversity to reduce centralization risks.
Introduction
This week, Ethereum's execution client Nethermind experienced a bug that caused all validators running Nethermind—about 10% of the network—to go offline.
This was a minor event because only a small number of stakeholders operate Nethermind. Below is a chart showing the total balance of my own validator running Nethermind. You can see that around 4 AM local time, when the bug first occurred, the validator went offline. The team released a patch about four hours later, and after I installed it, the validator resumed operation around 9 AM local time. During this period, the penalties my validator incurred were roughly equal to the rewards it would have earned. By 1 PM that same day, the validator’s balance had surpassed its pre-downtime level. Overall, this was a small incident.
Many people incorrectly assume that if a similar incident happened with Geth, the penalties would be similarly mild. This is not true. It has nothing to do with Geth itself or how it's built—it's about how many people are running it.
According to ClientDiversity.org, approximately 84% of Ethereum validators run Geth. Defenders of this status quo argue that Geth is clearly the best and most stable client. While minority clients like Nethermind faced outages and bugs this week, Geth has performed reliably since the Merge—and before. From my own experience, switching from Geth to a minority client results in validators requiring more resources and experiencing more missed attestations.
This article is not an attack on Geth. I deeply respect their team. Unfortunately, due to Geth’s overwhelming dominance, we must honestly discuss the risks of running the majority client when it controls the vast majority of staked ETH.
No one wants to leave Geth, especially those who depend on uptime to advertise maximum returns—such as professional staking operators—if they know they’re likely to experience more missed attestations and more downtime on alternative clients.
As of September last year, Lido—the largest operator—was estimated to run about 76% of its validators on Geth.
But I'm glad I’m running a minority client—even if I lose some extra rewards—not because I'm an altruist sacrificing personal gains for network decentralization, but because I know my ETH will thus be insulated from most widespread bugs.
What happens if Geth has a bug?
It depends on the nature of the bug.
Because over two-thirds of Ethereum validators run Geth, any serious bug in Geth would immediately halt chain finality. This does not mean the chain stops or breaks. As long as other clients remain operational, the chain continues. However, about 84% of blocks would be missed, meaning a new block would be proposed roughly every 75 seconds instead of the usual 12-second interval. These blocks would be prone to reorgs, so transactions included during this time would not be guaranteed to persist once the chain resumes finality. This sounds bad—but remember, Ethereum operated without finality for years before the Merge, and Bitcoin still does today. That’s why exchanges require six or more confirmations before crediting deposits, to minimize the risk of reorgs and fund loss.
Some may recall that Ethereum already experienced such an event in May 2023, when certain consensus clients had bugs. Over two days, finality halted twice, leading to many missed blocks, with only about 40% of the network active at one point. After recovery, most DApp users noticed little beyond slightly slower block confirmations.
But what happens to validators?
Inactivity Leak
When a minority client fails, validators lose ETH at the same rate they earn rewards (as seen in my validator chart above). But if Geth fails—because it immediately halts finality—the penalties become much harsher. This increased penalty is known as the inactivity leak, which activates when finality stalls for four epochs (about 25 minutes) or longer. The inactivity leak is designed to incentivize offline validators to come back online quickly—or, in the worst case, to gradually destroy the stake of offline validators until their share falls below one-third, allowing the online majority to finalize the chain.
During an inactivity leak, being offline for just two days costs 0.6% of your stake—equivalent to two months of staking rewards!
Being offline for five days consumes an entire year’s worth of staking rewards (3.5%)! This means it would take over two years of staking to recover the balance you had before the event.
Within one week of downtime, 10% of your stake—or three years of rewards—is lost. In about 20 days, 50% is lost. In about 40 days, 90% is lost.
By contrast, validators offline due to a minority client failure would lose only 0.4% of their stake over 40 days.
How long would inactivity penalties last?
It depends on the bug.
If the bug can be patched, the penalty lasts only as long as it takes for the Geth team to fix it and for users to deploy the update—or switch to another execution client.
In practice, we expect such issues to be resolved within hours or at most a few days. If the fix took as long as the recent Nethermind incident, validators would lose just 0.004% of their stake—no big deal.
But things get worse if the bug causes validators to produce invalid blocks, and Geth treats them as valid and attests to them. This would cause a chain split: one branch containing invalid blocks (the Geth chain), and another ignoring them (the non-Geth chain). Validators running Geth would consider both branches valid and build on the heaviest one. With 84% of validators staking on the Geth chain and only 16% on the non-Geth chain, the Geth chain becomes dominant.
Of course, once resolved, blocks on the Geth chain would eventually be discarded (causing their own problems), but the bigger issue is that the Geth chain would have enough stake (>2/3) to finalize the invalid chain.
Once the Geth chain finalizes, validators who attested to it cannot participate in building the non-Geth chain (until it also finalizes), or they risk slashing. Essentially, Geth validators are locked into the invalid chain. This is the key risk many misunderstand.
Because Geth validators are trapped on the invalid chain, they appear inactive on the non-Geth chain and suffer inactivity leak penalties. No software update or patch can save them. They will be drained until their stake falls below one-third of the total, enabling the non-Geth chain to finalize.
Currently, 28,976,695 ETH are staked on Ethereum. About 84% (~24 million ETH) belong to validators running Geth; 16% (~5 million ETH) to those using other clients. For the non-Geth chain to finalize, Geth validators must have their stake destroyed until their share drops below one-third. This requires burning ~21.5 million ETH (about 90% of Geth stake), reducing Geth’s stake to ~250,000 ETH—less than one-third of the remaining total (~2.5 million + 5 million ETH). The ~5 million ETH controlled by non-Geth validators would then represent over two-thirds of the stake, allowing them to finalize the chain.
This would be an extremely painful process, taking about 40 days. It would reduce the total ETH supply by roughly 18%, bringing it below 100 million ETH.
The Race to Exit
An important point here is that validators stuck on the invalid chain are unlikely to just wait passively. They still have the option to voluntarily exit their stake, and even if they don’t, the network will forcibly eject them once their effective balance reaches 16 ETH. But this doesn’t mean their losses are limited to 16 ETH.
When you exit a validator—even if forcibly—you enter an exit queue, and while in the queue, you continue to lose ETH due to inactivity leak!
We know that in the worst case, it takes about 40 days for the inactivity leak to allow the valid chain to resume finalizing. How long does the exit queue take?
The exit queue has a churn limit, restricting how many validators can exit per epoch (~6.4 minutes). The churn limit is defined as:
The current exit rate allows 13 validators to exit every 6.4 minutes. If all Geth validators wanted to exit, it would take at least ~260 days for all to leave. Since 90% of stake would be destroyed in ~40 days, most validators would be drained before they ever exit.
The first 2% of Geth validators to initiate exit would exit within five days, losing up to one year’s worth of staking rewards.
You’d need to be among the first 3% to keep losses under 10% of your stake.
Only the first 8% could limit losses to under 50% of their stake. At that point, anyone who hasn’t manually exited will be forcibly ejected with a 16 ETH balance.
After 40 days, when 90% of their stake is destroyed, over 85% of validators would still be in the queue.
Exit capability won't save you. Your downside risk isn’t limited to the forced ejection penalty (16 ETH).
What about slashing?
Some mistakenly believe that if a bug occurs, Geth stakers would face not only inactivity leak but also slashing. This is incorrect.
Slashing only applies to double-signing events, which are entirely controlled by the consensus client. A bug in Geth should not cause the consensus client to commit slashable offenses. Geth producing invalid blocks is not a slashable offense.
Only inactivity leak penalties apply in the case of a Geth bug.
What should you do?
Today’s Geth-running stakers may not fully grasp the risks of relying on a single dominant execution client. Many wrongly assume that if a bug occurs, a patch will arrive within hours, and ETH losses will be minimal.
Many don’t realize that attesting to an invalid block could lock them into an invalid finalized chain, almost certainly resulting in the destruction of most of their ETH. This is a real and plausible risk.
Staking Ethereum is not risk-free yield. Would you invest at least $75,000 into a tool offering a maximum potential annual return of 3.5%, knowing it could result in 100% loss? Probably not—yet that’s exactly what 84% of Ethereum stakers are doing today.
By switching to a minority client (assuming the same bug doesn’t exist across multiple clients), you cap your maximum loss at 3.5% per year.
With this knowledge, continuing to run Geth seems irrational. I can only assume those who do aren’t fully aware of the risk.
If you hold an LST (e.g., stETH, cbETH, etc.) and the LST runs Geth on its validators, understand that your ETH is at risk. Consider unstaking or switching to another LST until Geth no longer dominates the ecosystem.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@Labrys_io
