EIP-7716 · anti-correlation penalties · proposed for Hegotá
What will correlated downtime
actually cost you?
Ethereum punishes correlated slashing. In 2027, it will punish correlated downtime too. Fail alone and you pay exactly today’s rates. Fail alongside 10% of the network and the first hours get expensive — fast.
The multiple falls as recovery stretches
Fast responders bear the deterrent; stragglers converge back toward today's rules. Bigger nominal bill, smaller relative one.
How real incidents would have scored
Measured by replaying the revised mechanism over actual mainnet participation data — event-window mean cost per 32 ETH, expressed as time-to-re-earn.
Loading a preset sets the sliders to an approximate reconstruction. The calculator then shows the worst case — a validator fully down at peak size for the whole window. Measured event means above are gentler: outages ramp in, many validators kept their source flag (exempt from scaling), and most recovered quickly.
“I recover slower than the pros. Am I ruined?”
No — and this is the most misunderstood part of the proposal. The charge is front-loaded: you pay for joining the correlated failure, not for how long your fix takes. Once the cohort recovers, the moving-average baseline has absorbed the event and every extra hour you stay down is charged at today’s plain 1× rate. A slow recoverer’s bill is bigger, but their multiple over today’s rules is smaller — the deterrent lands on the correlation itself, which no amount of pager-speed can dodge.
In the Prysm post-Fusaka replay, operators who took 24–36 hours to recover paid 1.5× what the 6–8 hour crowd paid under the revised rules. Today’s rules charge 4.7× for that same spread — today’s proportional bleed punishes slow fixes harder than EIP-7716 does.
The multiple over today’s cost falls with recovery time: the fastest responders in that event paid ~57× today’s rate for their short window; the slowest stragglers converged to ~9×.
Being down ten times longer cost about twice as much — not ten times. The flat tail after the cohort recovers is what makes the mechanism a correlation deterrent rather than a downtime tax.
How the revised mechanism works
Each slot’s offline balance is compared to a slow-moving average of itself (half-life ≈ 12.6 days). The timely-target penalty is scaled by the excess: factor = min(1 + 765 × excess ⁄ committee_balance, 256).
Front-loaded, not proportional
Severity scales with event size and lands at outage onset: 1% of stake failing together → ~9×, 10% → ~78×, ⅓ or more → the 256× cap. As the moving average absorbs the event, the factor decays back — stragglers’ extra hours are charged at ~1×.
Solo stakers pay today’s rates
The factor is never below 1× and there are no discount windows. A validator failing alone — hardware, ISP, a botched update — pays exactly what it pays today, to the gwei. Only failing together with a meaningful share of stake costs more.
Only the “offline signature”
Scaling applies only to validators missing both the timely-source and timely-target flags. Attested with a wrong target but a live source — late epoch-boundary block, minority client during a majority-client bug, relay outage — and you pay today’s unscaled penalty.
Burned, not redistributed
Extra penalties are burned, exactly like today’s penalties. Nobody earns more when a competitor goes down, so there is no incentive to attack or DoS other operators — the mechanism only reshapes who pays for correlated risk.
Above ⅓, the leak takes over
Past one-third offline, finality stops and the pre-existing inactivity leak — unchanged by this EIP — activates and grows quadratically, crossing the revised mechanism’s ~0.75%/day ceiling around day 2.5. Most of a multi-day finality-loss bill is the leak, not EIP-7716.
Why: decentralization pays
Diverse clients, infrastructure, geographies and distributed validators (DVT) rarely fail together, so they rarely see a factor above 1×. Concentrated setups carry correlated risk that today is priced at zero — this EIP prices it.
Frequently asked questions
Why does a slow recoverer pay a bigger bill but a smaller multiple?
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.
Does this hurt solo stakers or small operators?
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.
My client attested with the wrong target during someone else’s bug — am I scaled?
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.
What is the absolute worst case?
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. Principal-scale losses remain exclusive to the (pre-existing) inactivity leak and slashing; this EIP touches neither.
Where do the extra penalties go?
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.
I run a large share of stake. How should I read these numbers?
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.
When would this go live?
EIP-7716 is a draft under discussion, proposed for inclusion in the Hegotá fork. The mechanism described here is the 2026 revision (ethereum/EIPs#11962), 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 moving proposal.
How does Obol help with this?
Obol’s Distributed Validator Technology (DVT) splits each validator across independent operators, clients, and locations. When one node fails, the cluster keeps attesting — so a DVT validator rarely joins a correlated cohort at all, and the factor above 1× rarely applies. Under a mechanism that prices correlation, engineering correlation away is the direct hedge.
This tool models a draft EIP using an approved simplification (exact within ~5% for events ≤48h) and network economics that drift daily. It is education, not financial advice. Exact-integer models, backtests and figures live in the research repo.