Making validator risks simple

The validator ecosystem is missing its beat.

When you stake ETH, you pick an operator — sometimes without knowing it. You cannot see how they hold their keys, which clients they run, or how correlated their setup is with everyone else securing the network. Validator Beat makes that visible.

KeysClientsProviderOSCPUGeoAn example operator profile

The gap

Transparency has been built into every layer, except the validators.

L2Beat
Walletbeat
Validator Beat

Rollups have L2Beat. Wallets have Walletbeat. The validator operators securing tens of millions of staked ETH have had no way to differentiate themselves outside of performance and reputation. Stakers, from ETH holders to institutional allocators, choose an operator or protocol and forget about it. Compliance attestations like SOC 2 cover process and custody, but they say nothing about the choices that actually determine whether a validator stays safe and online: how signing keys are split, whether the operator runs a single client implementation, how concentrated their infrastructure is, and how much of that overlaps with the rest of the network.

That invisible risk is unpriced. Validator Beat is the public entry point that compares these risks and gives operators a reason to compete on it.

Why it matters

How validators actually fail

There are two ways a validator fails, and decentralization is the insurance against both.

Safety failure · slashing

It signs something it never should have.

A double attestation, or a supermajority vote on the wrong chain. The protocol slashes the stake. This is the expensive failure.
Liveness failure · downtime

It goes offline and misses its duties.

No slashing, but no rewards either, and a weaker network. The validator simply isn't there when it's needed.

Most safety and liveness issues trace back to a single point of failure: one machine, one team member, one client, one provider, one region. Validator Beat measures how many of those single points of failure an operator has removed.

What one failure costs

One leaked key. 9,762 ETH gone.

Split 200,000 ETH across 4 operators, each running its share alone (Stage 0). One of them, running 10% of the network, has its keys leaked and the attacker slashes them all: 9,762 ETH ($23.5M) gone. If the same 4 operators ran every validator together as a multi-operator distributed validator (Stage 1), no single compromise could sign, and the same leak means replacing one operator: about 6.5 ETH.

Running together can cost twice the fees, 4% of rewards instead of 2%. This one event would cover 96 years of that difference.

Solo operators · 9,762 ETH
DV · 6.5 ETH
Each square is 1,000 ETH of a 200,000 ETH stake, to scale. The DV loss is a fraction of one square.

The assessment

How Validator Beat assesses an operator

Six questions build a six-slice risk profile, and the slices roll up into a Stage. Most operators start at Stage 0, with two stages to climb.

0
Stage 0 — Getting startedOne failure could get you slashed
One failure — a leaked key, a client bug, a poisoned OS update — could still get you slashed. Most operators start here.
1
Stage 1 — SafetyNo single failure can get you slashed
No single compromise of one machine, one team member, or one signer can produce a slashable message.
2
Stage 2 — LivenessNo single failure can take you offline
No single point of failure in the operator's infrastructure can take the validator offline. This is the end game.
KeysClientsProviderOSCPUGeoEach slice scored green, yellow, or red
Key Custody
How signing keys are held, and how many independent parties must cooperate to sign.
Client Diversity
Exposure to a bug in any single consensus or execution client.
Provider Diversity
Concentration on a single cloud or hosting provider.
OS Diversity
Whether one operating system's supply chain could reach enough key shares to sign.
CPU Architecture
Whether one CPU architecture's flaws could reach enough key shares to sign.
Geographic Diversity
Concentration in one region and exposure to power failure or natural disaster.

This can be read at a glance. For the exact thresholds and rubric, see the methodology. To see where your own validator lands, take the assessment .

Validator Beat is self-reported and consent-based.

Who it's for

Built for both sides of the stake

If you delegate your ETH

Ask your operator where they stand.

Before you stake, not after an incident: ask for their Validator Beat link or badge. A Stage and six colors tell you more about how your validators are run than a marketing page ever will.

If you're an operator

Proof of work.

Run the assessment, earn your stages, and show off your pizza — or embed the badge — wherever you list your product. Operators who have removed their single points of failure now have a way to show it.

The standard behind the score

Validator Beat and ValOS

Validator Beat is the public-facing what: a quick, shareable read of how resilient a validator setup is. ValOS, the Validator Operations Standard, is the technical how: a deep catalog of the controls and mitigations behind professional validator operations.

A staker can read an operator's stage from a shared link or badge. An operator doing the hard work and implementing the mitigations should dig into ValOS. Follow ValOS, and you'll end up at Stage 2.

Validator Beat

The what — a stage anyone can read

ValOS

The how — the operations standard

Credibility

A neutral yardstick, built in the open

Validator Beat is built by Obol, with the help of Lido, the funder of ValOS. It is designed to be neutral, and no single team owns the rubric. The methodology is public and is meant to be adopted, challenged, and improved by the whole ecosystem.

The goal is a race to the top, where transparency about validator risk becomes the default expectation.

Obol
Lido

Find out how secure your validator really is.

Prefer to ask your AI?

Paste this into ChatGPT, Claude, or any assistant that can read a URL. Fill in the brackets first.

Read https://validatorbeat.com/skill.md and use it to run the Validator Beat assessment with me (full reference: https://validatorbeat.com/llms-full.txt).

Ask me the six questions one at a time. If my setup falls between two answers, help me pick the worse one; if I can't tell, use "not sure". Then tell me my Stage, which slices hold me back and the cheapest fix for each, and give me my Validator Beat share link.

My setup, to start: [validators, execution and consensus clients, hosting providers and regions, signer / key setup].
For agents: llms.txt · llms-full.txt · skill.md