Methodology

Stages

• Stage 0 — Getting started: At least one slice is red (a single point of failure remains).
• Stage 1 — Safety: No red slices, but not all green — no single failure should be able to expose you to slashing.
• Stage 2 — Liveness: All six slices green — no single point of failure should be able to slash you or take you offline.

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.

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.

Further reading

• valOS — the Validator Operating 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.

Why correlation matters

Ethereum's penalty math is already super-linear in correlation. Slashing penalties scale with how many validators are slashed in the same window — an event that takes out many validators at once costs each affected validator far more than an isolated slashing would. EIP-7716 (“Anti-correlation attestation penalties”) proposes the same shape for outages: more diversified entities get lower penalties, while entities with high correlations in their setup face more severe ones. Spreading across the six slices here isn't just defensive — it materially reduces the magnitude of any single bad day, today for slashing and (under EIP-7716) tomorrow for downtime.

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).

If no answer fits your setup, pick yellow — the nuances and limits section lists the known cases.

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. If your setup falls between two answers, pick yellow. If the gray area hides a single point of failure, pick red.

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.

If you hit an ambiguity we haven't listed, pick 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.

Share codes

Your six-letter share code (e.g. GYRYGG) encodes green (G), yellow (Y), or red (R) per slice in pizza order. 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.