Every validator has a public report card, and almost nobody reads it properly. An explorer page shows uptime, attestations, proposals, balances, and history in one place, and the temptation is to glance at the biggest number, usually a reward rate, and stop there. That glance is how delegators pick a validator that looks good for a week and disappears for a month, and how operators miss a slow decline in their own validator until it becomes a penalty. Reading an explorer well means knowing which numbers are signals, which are noise, and which need a second source before you act on them.
Start with the identity question, because the rest of the page is meaningless if you have the wrong validator. On Ethereum, a validator is identified by its index and its public key, and an explorer page accepts either. On Cosmos chains, the identity is the validator address and moniker, read on an explorer such as Mintscan. On Solana, it is the vote account and identity key. Copy the identifier from the source you trust, such as the operator's own page or your staking transaction, and paste it into the explorer, rather than searching by a similar name. Monikers, names, and labels are claims made by someone, not chain facts, and two validators can share a familiar name while being entirely different operators.
Status first: is this validator even active?
The status field is the first filter, and it is also the easiest to misread. An Ethereum explorer shows states across a validator lifecycle, from deposited and pending, through active, to exiting, exited, and slashed. An active validator is currently expected to attest and propose. A pending validator is waiting to join and earns nothing yet. An exited validator has left and will not come back. A slashed validator has been penalised for a consensus violation, and its history page will show it. Do not delegate to, or judge, a validator without noting its status on the day you look, because a page cached in your head from last month may describe a validator that has since exited.
Other chains express the same idea differently, so read the chain's own vocabulary. A Cosmos validator can be bonded, unbonding, unbonded, jailed, or tombstoned after a double-sign. A jailed validator earns nothing while jailed, and a tombstoned one is permanently removed. A Solana validator can be delinquent, meaning it has fallen behind the cluster and earns no rewards while delinquent. The label differs, but the question is the same: is this validator currently in good standing and actually participating, or is it in a state where participation has stopped?
Attestations and proposals: the work itself
For Ethereum, the work is attestations and proposals, and the explorer breaks both down. Attestation rate, or the share of assigned attestations actually made, tells you whether the validator shows up for its routine duties. Attestation effectiveness, a concept popularised by beacon explorers, adds timing: an attestation included quickly is worth more than one included late, so a validator that always attests but always attests late is underperforming in a way a simple success rate hides. Missed attestations, shown as a count and a history, tell you whether the misses are a one-off blip or a pattern. A single missed attestation is noise. A cluster of misses, or misses that repeat every few days, is a signal about uptime, network, or client health.
Proposals are rarer and therefore noisier. A validator proposes only when selected, so a small validator may go a long time between proposals, and one missed proposal in a small sample looks worse than it is. Read proposals over a long window, and read them alongside attestations, which happen constantly and therefore give a much larger sample. The same sample-size caution applies to income history: a short, rising income chart may reflect a lucky run of proposals, not better operation, while a long, steady chart is the stronger evidence. The earlier posts on monitoring a validator and on reading validator logs explain how an operator turns these same signals into alerts, rather than reading them only after a delegator complains.
Uptime, commission, and the numbers that mislead
Uptime is the most quoted metric and the least standardised. Some explorers derive it from attestation success, others from node connectivity, and others from a mix, over windows that differ. Compare uptime only within one explorer, over the same window, and prefer history over a single snapshot. A validator with steady availability over weeks or months is a stronger bet than one whose recent week looks perfect after a month of gaps. Look for repeated outages, unexplained interruptions, and long inactivity, and treat a sudden change in pattern, such as a previously steady validator going quiet, as a question to ask the operator, not a verdict on its own.
Commission, where the chain has it, needs the same careful reading. Commission is the operator's share of rewards, and it can change, so the rate on the explorer today is not a promise about next month. A zero commission rate is often a promotion that ends, and a very high rate means delegators keep little even when the validator performs well. Read commission alongside performance: a low-commission validator that misses attestations regularly can still leave a delegator worse off than a fairly priced validator that rarely misses. And never rank validators by reward rate alone. Reward rates move with network conditions, proposal luck, and fee markets, and a rate quoted without a date and a window is a snapshot pretending to be a fact.
Red flags, and how to cross-check them
The red flags worth acting on are patterns, not single events. A slashing history, especially a recent one, is the strongest flag, because it means the validator has already broken a consensus rule, and the cause, often double-signing from two live key copies, may still be present. Repeated jailing, long delinquency, or a client version that is far behind the network are flags about operations, not luck. A sudden commission change, a moniker change, or a move to a new operator identity without explanation is a flag about communication. None of these, alone, proves a validator is unsafe, but together they describe an operator worth avoiding until the pattern changes.
Cross-check before you decide. Confirm the validator on a second explorer, because explorers can lag, mislabel, or index differently, and a page that looks stale may be an explorer problem, not a validator problem. Check your own node or logs if you operate the validator, because the explorer reads the chain after the fact, while your logs show what your client actually did and when. Check the operator's own communication: a status page, a changelog, or a public explanation of an outage is evidence of an operator who notices problems, while silence after a visible outage is evidence too. Finally, re-check on a schedule. Commission changes, jailings, and performance drops happen after delegation, and a validator chosen once and never reviewed is a decision that quietly expires.
An explorer will not choose a validator for you, and it should not. It will show you, in public, whether a validator shows up, does its work on time, stays in good standing, and communicates when it does not. Read status first, attestations over a long window, uptime as history rather than a snapshot, and commission as a current rate rather than a promise, and cross-check anything important on a second source. If you run validators yourself, the same reading applies to your own pages, before your delegators do it for you. For help turning explorer signals into monitoring, alerts, and a runbook, node operations covers that work, and a free infra audit is the place to start.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-11-04 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.