How the Slashr Risk Index works

Every validator we track gets a score from 0 to 100, where higher means riskier. The score is fully mechanical: it is the inverse of an internal operational health grade, recomputed continuously from the published events and infrastructure scans you can see on this site. Nothing on this page is aspirational - it describes the code that runs today, and every score can be traced back to the inputs that produced it.

Inputs and weights

The health grade starts at 100 and subtracts five weighted penalty factors, computed over the trailing 90 days of published events. The risk score is 100 minus the health grade.

Deliberately not inputs: commission level or commission changes (shown on the surface, but not scored), stake size, and token price. A slashing event contributes to the incident count like any other published event - slashing history is not separately weighted.

Tiers

These thresholds are operator-set judgement bands, not a derivation. They divide the 0–100 score into four ranks at round numbers we chose; they are not fitted to realized outcomes such as actual slashing or failure rates, because that calibration has not yet been done. A tier is therefore a ranking band - where a validator sits relative to others on the score - and not a prediction that a Critical validator will fail or that a Low one will not. We state this plainly rather than imply a derivation that does not exist. Calibrating the bands against outcome data is open work; when it is done, this section will say what they were fitted to.

What the stake figures mean

Where the surface shows a dollar figure next to a validator, it is that validator’s total delegated stake (native stake times a live token price) - stake associated with a validator currently meeting risk conditions. It is never a prediction of loss, an expected-loss estimate, or a claim that the protocol will confiscate anything.

Whether stake can be lost to a protocol penalty differs per network, and that difference is shown wherever risk is presented:

For example: Solana does not enforce slashing today - SIMD-0204 deploys the Slashing Program for observability, giving the protocol a cryptographically-proven view of violations without modifying stakes or rewards. Sui’s tallying rule withholds an epoch’s staking rewards. On Ethereum, Cosmos Hub, Celestia and Polkadot, protocol violations destroy part of the bonded stake itself. Incidents on this site are operational observations; they do not imply misbehaviour or malice unless the event itself is a protocol-confirmed violation.

What the infrastructure scan reads

The 15% infrastructure factor uses two numbers from NullRabbit’s security scanner: the count of known CVEs associated with the software your node exposes, and the number of open, publicly-reachable services (ports) on the host your validator advertises. It reads only what is already public-facing - the scan is non-invasive: it does not attempt to exploit anything, access data, brute-force credentials, run denial-of-service tests, or touch private networks.

You can verify this against your own host. NullRabbit publishes every IP it scans from and offers an opt-out, on its scanner transparency page. A validator with no scannable public IP - most chains identify validators by an on-chain key, not a host - simply has no scan data, and the infrastructure factor contributes nothing (neither penalty nor credit) to its score.

Tracing a score

Click any validator row to see the signals behind its score: incident count, downtime, recovery, infrastructure findings, and the event history itself. The same inputs are available programmatically from GET /v1/risk/validators, so any score can be recomputed independently.

Mechanism references

Slashr is NullRabbit’s live observation layer: it shows validator faults happening in the real world. Where an incident class corresponds to a documented fault mechanism, we point to the research registry that names it. Where no mechanism applies - the majority of incidents, which are operational or configuration events - we say so plainly.

What the score does not claim

The index describes observed operational behaviour. It is not a prediction of future incidents, not a probability of slashing, not an expected-loss model, not a security audit, and not delegation advice. A low score is not an endorsement. Networks and detectors in their soak window are excluded from the public surface until they meet go-public criteria, so coverage differs by chain - a quiet chain may be quiet because it is quiet, or because a detector class is not yet public.

Known limitations

• One global formula: weights and thresholds are currently identical across networks with very different penalty regimes.
• Tier thresholds are operator-set judgement bands, not yet calibrated against realized outcomes.
• The window is 90 days: older history does not affect the score.
• Only published events count - gated chains and gated detector classes are excluded until their soak completes.
• Infrastructure scan coverage is partial; validators without a scan are not penalised on that factor.
• Uptime percentage is not yet an input.

Disputes

Operators will sometimes disagree with a score. There is no formal dispute process today - we would rather say that plainly than imply one exists. What we do offer: every score is mechanically reproducible from the published events shown on the validator’s profile, so a dispute is always a dispute about a specific event. If an underlying event is factually wrong (for example a detector fault), reach us on X at @SlashrDev and we will review the event data. Factually wrong events can be suppressed by an operator, which removes them from scoring; scores themselves are never manually adjusted.

Corrections

When we change how the score is calculated in a way that moves published scores, we record it here with a date and a reason rather than letting scores shift silently.