Methodology

Validator Beat v0.1 is a self-assessment tool. You answer six banded questions; each answer maps directly to a slice color (green, yellow, or red). Your overall Stage rolls up from those six colors. It's written for operators assessing their own setup — and for stakers deciding whether an operator has earned their stake. Nothing is sent to a server — scoring runs entirely in your browser, and the source code is public.

Stages#

Stage 0 — Getting started: one failure can slash you. (At least one slice is red — a single point of failure remains.)

Stage 1 — Safety: one failure won't slash you. (No red slices, but not all green yet.)

Stage 2 — Liveness: one failure won't slash you or take you offline. (All six slices green.)

The six slices#

Key Custody — Concentrated private keys are a single point of failure — one compromise lets an attacker sign slashable messages with your entire stake.
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.
Provider Diversity — One hosting provider's outage or compromise can take every validator hosted there with it.
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.
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.
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#

Each question offers three banded choices (best → worst). Your selection is the slice color — there is no separate backend calculation in v0.1.

Client diversity uses a simplified banded model; live network client share thresholds are deferred to a future operator registry (v1.2 spec).

Rule of thumb: if your setup falls between two answers, pick yellow. If the gray area hides a single point of failure, pick red. The nuances and limits section lists the known cases.

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.

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 above covers the space between them.

Known cases the questions don't spell out:

Shared owner. Two key custodians inside one company fail together. Score Key Custody yellow.
Derived distros. Ubuntu and Debian share upstream packaging. If your distros share a supply chain, score OS Diversity yellow.
One physical host. Two OSes in VMs on one machine share that machine. Score OS Diversity yellow.
Resold infrastructure. Two providers reselling the same cloud or data centre fail together. Score Infrastructure yellow.
Active/passive failover. A warm standby still goes offline during failover. The four infrastructure slices assume active/active; score them no higher than 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 Infrastructure 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.

Your six-letter share code (e.g. GYRYGG) encodes green (G), yellow (Y), or red (R) per slice, in the slice order listed above. It lets you share a result link without storing personal data.

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.