Methodology

Stages#

Safety slices and liveness slices#

Each stage answers one question, so each slice gates the stage whose failure mode it guards against. Safety slices — Key Custody, Client Diversity, OS Diversity, CPU Architecture — decide whether one failure can get you slashed or leak your keys, so a red or not-sure there holds you at Stage 0. Liveness slices — Provider Diversity and Geographic Diversity — decide whether one failure can take you offline, so they only stand between you and Stage 2. If one provider could also reach your keys, that shows up under Key Custody, not here.

The six slices#

1. Key Custody — Concentrated private keys are a single point of failure — one compromise lets an attacker sign slashable messages with your entire stake.
2. Client Diversity — If a supermajority client forks onto a wrong chain, validators that follow it face mass correlated slashing; refusing to attest on disagreement turns that into mere downtime.
3. Provider Diversity — One hosting provider's outage or compromise can take every validator hosted there with it.
4. OS Diversity — An OS monoculture is a supply-chain risk: one poisoned update or zero-day could reach every node — and every key — at once.
5. CPU Architecture — A CPU-architecture monoculture is a hardware-level supply-chain and side-channel risk — one flaw can reach keys on every machine you run.
6. Geographic Diversity — Nodes concentrated in one country or region share exposure to grid failures, natural disasters, and local policy shifts.

The active/active assumption#

For infrastructure, OS, CPU, and geography, diversity only translates into resilience when your validator runs active/active: several cooperating nodes back the same stake, with signing continuing as long as enough of them stay up. The stake isn't partitioned across machines — it's one aggregate validator whose cooperating machines you've diversified. Several setups achieve this — multi-operator distributed validators (DVT) coordinated by Charon, or validator clients like Vouch paired with multiplexers like Vero and remote signers like Dirk or Web3Signer. The common requirement: no single party holds enough key material to sign alone — at least two independent parties involved, backups kept separate, so compromising one doesn't leak the full private key.

How answers map to colors#

Colors mean the same thing on every slice: red means one failure could get you slashed, yellow means one failure could take you offline (or a safety gap is only partly closed), and green means no single failure can do either. So Key Custody and Client Diversity use all three bands; OS and CPU are green or red, because the only question is whether one OS or architecture holds enough key shares to sign; and Provider and Geography are green or yellow, because the worst they can do is take you offline. Your selection is the slice color — there is no separate backend calculation.

Every question also offers Not sure. It's treated as an open gap: a gap you can't verify is closed has to be assumed open, so it holds a safety slice at Stage 0 and a liveness slice short of Stage 2. Your results then tell you how to find out, rather than how to fix it.

Bands follow the consensus math. Distributed validators typically need ⅔ of key shares to sign, so any single party, OS, or architecture holding ⅔ or more is red. Holding ⅓ or less means losing it still leaves a signing threshold online, which is green. For Provider and Geography, anything over ⅓ on one provider or region can already drop you below that threshold, so there's a single cut-off.

Client diversity counts execution and consensus clients alike and uses a simplified banded model; live network client share thresholds are deferred to a future operator registry.

Why correlation matters#

Ethereum already punishes correlated slashing harder than isolated slashing: penalties scale with how many validators are slashed in the same window, so an event that takes out many validators at once costs each of them far more than a one-off mistake would.

EIP-7716 (“Anti-correlation attestation penalties”) proposes the same shape for outages: diversified setups would pay smaller downtime penalties, highly correlated setups steeper ones. Spreading across the six slices isn't just defensive — it shrinks the cost of any single bad day: today for slashing, and under EIP-7716, tomorrow for downtime.

The scale is what makes Stage 2 worth chasing. The EIP-7716 downtime calculator shows penalties for an outage shared by 10% of validators rising to roughly 78× their current rate, capped at 256× when a third of stake is offline. Validators that fail alone would pay what they pay today — so the Provider and Geography slices, which decide whether you fail alone or with a crowd, carry real money.

For safety failures, the cost of failure page prices it in ETH. A key compromise at an operator running 10% of the network, with every key slashed, costs a 200,000 ETH stake about 39,000 ETH at Stage 0. At Stage 1 it means replacing one key-holder, which costs a few ETH. The page also asks how often that happens, and when a higher Stage 1 fee pays for itself.

Nuances and limits#

This section lists the nuances the assessment leaves out, so you can weigh them yourself.

Why three colors#

Real setups don't fall into neat green, yellow, and red buckets. We use three colors anyway because they keep a result easy to read at a glance — the rule of thumb covers the space between them.

Known cases the questions don't spell out:

• Shared owner. Two key custodians inside one company fail together. Count them as one party when scoring Key Custody.
• Derived distros. Ubuntu and Debian share upstream packaging. If your distros share a supply chain, count them as one OS.
• One physical host. Two OSes in VMs on one machine are both reachable through the host. Count the host's OS, not the guests'.
• Resold infrastructure. Two providers reselling the same cloud or data centre fail together. Count them as one provider.
• Active/passive failover. A warm standby still goes offline during failover. The Provider and Geography slices assume active/active; score them yellow.

The remote signer stack#

Every current signing stack keeps a single point of failure somewhere, whether you run Web3Signer, Dirk, Vero, Vouch, or Charon. Validator Beat doesn't score it: penalizing something no setup can avoid would push everyone toward one architecture.

Hosting provider type#

Validator Beat doesn't rank residential, bare metal, or cloud hosting. The Provider slice already scores provider concentration, which catches the real trap: five regions all on AWS still fall to one provider incident.

CPU generation#

Validator Beat counts instruction sets and ignores chip generations. Hardware bugs sometimes hit one generation and sometimes a vendor's entire line, so mixing generations guarantees nothing.

Share codes#

Your six-letter share code (e.g. GYYGGY) encodes green (G), yellow (Y), red (R), or not sure (U) per slice, in the slice order listed above. It lets you share a result link without storing personal data. Add ?vs= with another code to share a head-to-head.

What's next#

A future operator registry will publish verified operator profiles using the fuller Validator Beat v1.2 rubric (YAML data, per-slice minimums for stages). v0.1 focuses on helping individual operators understand their own setup first.

Further reading#

• The cost of failure — what a key compromise, slashing or outage costs at Stage 0 vs Stage 1, from the consensus spec and today's queues.
• ValOS — the Validator Operations Standard — the canonical risk-and-mitigation catalog for validator operators. Nearly every risk surfaced in this assessment has a corresponding mitigation in ValOS.
• clientdiversity.org — live network share for each Ethereum consensus and execution client.
• Obol docs — distributed validators, Charon, and chain-split safety settings.
• EIP-7716 — Anti-correlation attestation penalties — proposal to scale downtime penalties by correlation, so diversified setups pay less when many validators miss attestations together.
• Validator Beat source code — this site is open source; the full scoring rubric lives in lib/rubric.