The cost of failure

Is it worth paying your operators to run your validators together?

Splitting your stake across operators that each run their share alone (Stage 0) leaves each share one leaked key away from slashing. Running every validator together as a multi-operator distributed validator (Stage 1) removes that, for a higher fee. Is it worth it?

View
Solo-operator setup · Stage 0
Your stake is split across operators that each run their share alone. One compromised key at any of them can get that share slashed.
Multi-operator distributed validator · Stage 1
The same operators run every validator together, and signing needs a threshold of them. No single compromise can get you slashed.
Step 1

Setup

ETH · $480.8M
How often a key is compromised
How bad an incident is
Operator fees, as a share of staking rewards
Step 2 · Results

Do you expect each of your 4 operators to go 122 years without a security incident?

That's how rare incidents must be for running them separately to pay off: none at an operator since about 1904. You assumed about one every 25 years per operator, or none since 2001.
If not, run them together. On average the multi-operator DV saves you 374 ETH a year ($898K) after its extra cost.
Expected loss a year
498 ETH Solo operators · Stage 022 ETH Multi-operator DV · Stage 1
Extra cost of running together102 ETH a year up front4% instead of 2% of rewards. One worst case costs 96 years of it.

The worst case: one operator's keys leak and are all slashed

Areas to scale. The blue speck in the corner is the second loss.
Solo operators: slashed and exited9,762 ETH$23.5M · the 50,000 ETH that operator ran
Multi-operator DV: replace the operator6.5 ETH$16K · at your own pace
1,506× smaller
See how often the solo setup still comes out ahead ↓
Read this as a floor

The worst case isn't on this page: a client bug can lock you out#

A bug in the clients most of the network runs can cost far more than a leaked key: on the Holešky testnet in 2025 it trapped validators on an invalid chain[1]. On mainnet that could cost each trapped validator 72–93% of its balance[2]. A multi-operator DV with diverse clients is far less exposed.

How a lockout works, and the numbers

Everything above prices a key compromise at one operator. A bug shared by the clients most of the network runs can cost more. If ⅔ or more of stake follows the same invalid chain and justifies it, those validators can't vote on the correct chain without a surround slashing. So they stay offline while the inactivity leak drains them, until the honest side holds ⅔ of what's left[3].

That happened on the Holešky testnet in February 2025. Geth, Nethermind and Besu shipped the wrong deposit contract address and accepted an invalid block. The invalid chain was justified at epoch 115,968, and the network then ran two weeks without finality[1][4]. Those three clients run roughly 94% of mainnet stake today, according to clientdiversity.org[5]. The downtime calculator lists which client combinations are large enough to cause a lockout today.

At mainnet scale, a lockout of 67–94% of stake would cost each trapped validator about 72–93% of its balance over 30–45 days[2]. That is three to four times the ~20% this page shows when a whole 10% operator is slashed, and it doesn't depend on your operator's size, only on your clients'. So the losses above understate what a solo-operator setup risks. A multi-operator DV with diverse clients across its key shares has a smaller lockout risk: one client's bad vote can't reach the signing threshold, so the cluster misses those duties instead of signing the wrong chain. See the Client Diversity slice of the assessment.

Lockouts aren't added to this page's totals or odds.

How often the solo setup still comes out ahead#

The share of simulated runs where running your operators separately is still ahead. With 4 operators there are that many chances of an incident each year, so the odds fall fast.

Heatmap view
Rows: key incidents per operator per year, and how often that is. Columns: years held, 1 to 20, from 1,500 simulated runs per row. Your rate and your 10-year setting are outlined.
Simulating…

Want to see more detail?

Advanced shows each incident day by day, the full range of outcomes, the model behind every number, and lets you change every assumption: queues, operator size, how the attack plays out.

Which stage is your validator at?

Six questions, about a minute, nothing stored.
Assess your validator →

Prefer to ask your AI?

Paste this into ChatGPT, Claude, or any assistant that can read a URL. It will ask for your numbers and build you a pre-filled link.

Read the "Cost of failure" section of https://validatorbeat.com/llms-full.txt, then help me decide whether to pay my operators to run my validators together as a multi-operator distributed validator (Stage 1) instead of separately (Stage 0).

Ask me for anything missing below, then build me a pre-filled https://validatorbeat.com/cost-of-failure/ link with my numbers, and tell me: my expected loss a year each way, the extra cost, the break-even as "one incident every N years per operator", and what a worst-case incident would cost me. Remind me the figures are a floor: wrong-fork lockouts aren't included.

My setup: [stake in ETH, how many operators, roughly how big each is (% of all staked ETH), fees I pay now and fees quoted for a multi-operator DV].
For agents: llms.txt · llms-full.txt · skill.md

References#

  1. Holešky Pectra incident post-mortem (opens in a new tab) · Ethereum Foundation, ethereum/pm
  2. EIP-7716 downtime calculator: client failure tiers and wrong-fork lockout model (opens in a new tab) · validatordowntime.obol.org
  3. get_inactivity_penalty_deltas (inactivity leak) (opens in a new tab) · ethereum/consensus-specs, Bellatrix
  4. Holešky incident debrief, 26 February 2025 (opens in a new tab) · Ethereum Magicians
  5. Client diversity, including stake-weighted execution client shares from supermajority.info (opens in a new tab) · clientdiversity.org
  6. Validator queue history (opens in a new tab) · validatorqueue.com (etheralpha/validatorqueue-com)
  7. process_slashings and slash_validator (opens in a new tab) · ethereum/consensus-specs, Electra
  8. EIP-7716: Anti-correlation attestation penalties (opens in a new tab) · Ethereum Improvement Proposals
  9. EIP-7251: Increase the MAX_EFFECTIVE_BALANCE (consolidations) (opens in a new tab) · Ethereum Improvement Proposals