Proposal: Ethereum slashing risk pipeline for ETH Slashing Cover (history, correlation, price calculator)

Governance Discussions
1

We are MigaLabs, a blockchain research group in Barcelona. We have measured the Ethereum consensus layer since genesis with our own network instrumentation, and we work under Ethereum Foundation research grants. Before this proposal, two examples of the kind of analysis we publish, both on ethresear.ch with the Ethereum Foundation’s robust-incentives group:

One thing to state up front, since past data proposals here have rightly been asked this: none of what follows duplicates Dune, beaconcha.in or rated.network. The free sources show current state and per-validator status. They do not carry per-event slashing history to genesis depth, they do not model correlated failure, and the two best-known ones are owned by staking operators (rated.network by Figment, beaconcha.in by bitfly). We run no validators, custody no assets and sell no staking. Our only product is measurement.

We propose a three-milestone research pipeline built for the underwriting of ETH Slashing Cover. Each milestone is a standalone artifact. The committee confirms each one before the next tranche, so the mutual can stop after any deliverable it does not find useful.

Milestone 1 (160 NXM): the complete slashing record since genesis. Every slashing event from December 2020 to date, with dates, penalties and reward losses per event, and how the penalty rules themselves changed across hard forks. The register comes with loss frequency and severity distributions in actuarial form. For scale: our index counts 573 validators slashed since genesis, network-wide, against roughly 896,000 currently active, and the two largest single-operator incidents in the curated set we monitor hit 11 and 20 validators in one event each. This is the base layer everything else prices from.

Milestone 2 (320 NXM): correlation analysis, observed and forward-looking. Slashing losses cluster. When an operator fails, it tends to fail across many validators at once, and the historical record lets us measure that clustering directly. The second half models what has not happened yet: scenario analysis of correlated failure, for example a bug in a consensus client at a hard fork such as Glamsterdam, and what that would mean for operator downtime and subsequent slashings. This is the severity question an insurer actually prices, and it is the heaviest deliverable of the three.

Milestone 3 (160 NXM): an insurance price calculator. A working deliverable, not a report: a calculator that takes the frequency, severity and correlation results from milestones 1 and 2 and produces indicative pricing for slashing cover under configurable assumptions, including the 40-day loss window ETH Slashing Cover pays on. The mutual keeps the artifact and the methodology.

Ask: 640 NXM total (about $32K at the time of writing) over a 12-week plan, paid per milestone in three tranches of 160, 320 and 160 NXM, each released only after the committee accepts the preceding deliverable. Milestone 1 lands at week 3, milestone 2 at week 9, milestone 3 at week 12. If milestone 1 is not what the mutual wanted, the exposure stops at 160 NXM and three weeks.

The pipeline runs from history to correlation to risk evaluation to a commercial pricing tool. We are open to adjusting scope, adding deliverables, or shaping any of this toward what the underwriting team actually needs. Happy to answer any question in this thread.

1 Like
2

Thanks for joining our forum and for the proposal @MigaLabs

While I very much appreciate the proposal, the core Nexus Mutual team has already performed analysis very similar to your proposed approach and is actively using it in pricing for slashing coverages.

I would also note that the tail risk aspects are the hardest piece to quantify as there is literally no data on a widespread tail slashing event, which is the primary concern of most cover holders and the aspect that drives most of the pricing premium. Therefore this type of analysis very quickly gets into the field of actuarial art, rather than more pure data science.

Thanks again for your proposal.

3

Hugh, thanks for the direct answer. Good to hear the team already runs this class of analysis internally. That is more than most underwriters in this market can say.

On tail risk you are right, and it shaped how we scoped milestone 2: scenario modeling rather than historical extrapolation, because there is no observed widespread slashing event to fit anything to. What observation can still contribute is the correlation structure of the events that did happen (slashings arrive in operator-level batches, and that batch-size distribution is measurable to genesis depth) and network instrumentation to parameterize the scenarios cover holders actually worry about, like a consensus client bug at a hard fork. Where the art takes over from there is your team’s craft, not ours.

So instead of a counter-pitch, one question: when the team built its internal analysis, was there a dataset or measurement it wished existed, especially on the correlated failure side? We run network-wide consensus-layer instrumentation since genesis, and we would rather build against a gap you actually have than resubmit a scope you have already covered. If a short call with the pricing side is easier than a thread, happy to do that.