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, stop you, or censor you.

The six slices

1. Key Custody — Concentrated private keys are a single point of failure — one compromise and an attacker can sign to slash your stake.
2. Client Diversity — A supermajority-client bug can cause you to lose 100% of funds; refusing to attest during a chain split turns that into mere downtime.
3. Provider — 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 backdoor or zero-day could jeopardise a huge amount of validators.
5. CPU Architecture — A CPU-architecture monoculture is a hardware-level supply-chain and side-channel risk.
6. Geographic — A validator fully in one country or region can be impacted by a natural or man-made disaster.

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 — Validator Operator Standards — the canonical risk-and-mitigation catalogue 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).

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.