What will correlated downtime
actually cost you?

Short-term pain for long-term gain. The crowding that makes a client’s outage a correlated one also makes its bugs dangerous. A signing bug in a client with 25% of stake slashes ~75% of every affected validator’s principal. A consensus bug shared by clients with ⅔ of stake carries them onto a fork they can’t leave without losing most or all of it. Those failures are rare and the protocol prices them only after they happen. Downtime is common, so pricing it (a few hundred dollars per validator in a large event, around 1/100th of a correlated slashing or less) is how the protocol nudges stake to spread out before the rare failure. The tiers and client combinations are above.

Two forces move in opposite directions. Nominally, more hours down always costs more — the bill grows monotonically. But the scaled hours are only the ones where the cohort is still down with you; after that, the baseline has absorbed the event and you’re back to ~1× while today’s rules keep charging linearly. So the ratio of revised-to-today shrinks the longer you take. Flip the chart above to “× today” to watch it fall. Practically: a fast responder might pay 30× today’s rate on a small bill, while a straggler pays 5× on a bigger one.

A validator whose downtime is uncorrelated with the rest of the network pays exactly today’s penalties — the factor is never below 1× and never above it for lone failures. The mechanism only bites when a meaningful share of total stake fails simultaneously, which is characteristically a large-operator, shared-infrastructure, or majority-client failure mode. Small diverse setups are the beneficiaries, not the targets.

No. Scaling requires the “offline signature”: missing both the timely-source and timely-target flags. If your node was live but voted a wrong target — a late epoch-boundary block, running a minority client while a majority client splits the chain, a relay outage — you keep the source flag and pay only today’s unscaled penalty. This deliberately protects minority-client operators during majority-client incidents.

While roughly a third of stake is newly offline and your validator is fully down, the revised mechanism bleeds at most ~0.75% of principal per day — and that rate requires the cap to bind continuously. Below the cap it’s proportionally less, and it decays as the moving average catches up. Crucially, that daily rate cannot run for long: summed over any outage, however endless, the total extra cost is hard-bounded at ~0.2× the event’s size — about 2.6 years of rewards in the absolute worst case (a ⅓ outage you never return from). The next question walks through why. Principal-scale losses remain exclusive to the (pre-existing) inactivity leak and slashing; this EIP touches neither.

No — the moving average is the built-in bound. The factor prices the excess over a reference that chases any persistent outage with a 6.3-day half-life, so the penalty rate halves every ~6 days even if nobody patches anything. Suppose something ugly took 30% of the network down for a month (below ⅓, so no inactivity leak): the bleed starts at ~0.66%/day — the full 0.75% needs a ⅓-of-stake event — is down to ~0.33%/day by day 6 and ~0.06%/day by day 25. Integrated over forever, the extra cost above today’s rules converges to about 0.2× the event’s size: ~6% of principal for a 30% event, ~2% for a 10% event — roughly 2.6 years of rewards even in the absolute worst case (a ⅓ outage, never recovering). Coming back online stops the scaling instantly, and half the lifetime total lands in the first week. And a consumer-scale nightmare bounds itself further: solo and home stakers are collectively a low single-digit percent of stake, so even a failure hitting every home setup at once is a small event here — a ~3% cohort draws a ~24× onset and a lifetime bound near 0.6% of principal, months of rewards, however hard it is to fix. For scale: if the same scenario crossed ⅓ and finality broke, the pre-existing inactivity leak alone takes ~50% of principal in 18 days. This mechanism’s worst multi-week trajectory stays far below the protocol’s existing crisis pricing.

No — and that’s by design, not by omission. Around 0.3% of stake is offline at any given moment in normal operation, and the mechanism’s moving average sits at that level in steady state. An event is measured as the excess above it: with a 0.3% baseline and a 10% outage, the offline share is 10.3%, the reference is 0.3%, and the factor prices exactly the 10% spike. This calculator models it that way explicitly (see BASELINE_OFFLINE_FRACTION in the source), and every number is identical to a zero-baseline assumption because the slope is normalized by total stake, not by the moving average — a design chosen precisely so the curve doesn’t drift as network participation changes.

They’re burned, like all attestation penalties today — not redistributed to online validators. Your competitor going down earns you nothing, which removes any incentive to attack other operators’ infrastructure.

Scale linearly: the calculator’s per-32-ETH figures multiply by your validator count (the mechanism is balance-weighted, so per-32-ETH stays the right unit even with 2048-ETH validators). As an anchor: a 10%-of-stake event lasting 24 hours costs roughly 900 ETH per 1% of total stake an operator runs — around 9,000 ETH for a 10% operator. If your whole fleet shares one client, cloud, or team, your event size is your fleet size.

EIP-7716 is in Draft status and Proposed for Inclusion in the Hegotá fork (All Core Devs – Consensus #177, April 2026). Forkcast tracks its status as Hegotá’s scope is decided. The mechanism described here is the 2026 revision, now the published EIP text, which replaced the 2024 draft’s counter-based design after replays showed it barely differentiated correlated from uncorrelated failures. Nothing here is final — treat every number as an estimate of a proposal that can still change.

At Holesky’s Pectra upgrade on 24 February 2025, Geth, Nethermind and Besu each had a different wrong deposit-contract address in their Holesky config. Each fell back to an empty deposit list, so all three agreed on the same wrong result and accepted an invalid block that Erigon and Reth rejected. A supermajority of validators followed that chain and justified it. From then on, voting on the correct chain meant a surround vote, so their slashing protection refused. The choices were wiping it and getting slashed, or sitting out an inactivity leak. Finality came back on 10 March after two weeks of coordinated recovery. The exit queue was left full for over a year, and the testnet was replaced by Hoodi (post-mortem). Mainnet ran different, correct config for that fork. But the same three clients carry well over ⅔ of mainnet nodes today, and every hard fork activates new code for all of them in the same epoch. EIP-7716 doesn’t prevent a bug like that; it pays operators to make sure no bug is shared by that much stake.

From downtime, yes. From a wrong fork, no. A primary/fallback setup uses whichever node answers, so if your primary follows a bad chain, you sign it. Protection comes from requiring agreement: a majority or threshold rule across nodes running different clients, where each node checks what it’s asked to sign against its own view. When the nodes disagree, a setup like that halts instead of signing. Halting costs a downtime penalty; signing a justified wrong fork can cost the validator. The trade-off is liveness: the stricter the agreement rule, the more often a single node’s trouble stops you.

By failing alone, not together: run a minority client, avoid the most crowded cloud providers and regions, and stagger upgrades rather than rolling a whole fleet at once. Splitting a validator across independent nodes (distributed validators) is another option — if part of the cluster fails, the rest keeps attesting, and if the nodes disagree about the chain, the cluster halts rather than signing a fork only some of them see. Under a mechanism that prices correlation, anything that de-correlates your failures is the direct hedge.