How we measure

Since epoch 1064 (21 October 2026), Solana mainnet runs Alpenglow, a new consensus protocol. Validators no longer send their votes as on-chain transactions. For each slot, the leader eight slots later (the validator chosen to produce that block) puts the votes it has received into its block. We call that block a paying block. Every validator whose vote is in it earns a fixed amount, set for the whole epoch and proportional to its stake. The leader earns, on top, about as much as all those voters together. If that block is skipped, or its leader does not add the votes in time, nobody is paid for that slot. That is a loss for the whole cluster, not a miss for any one validator.

Why we no longer rank by vote credits

Before Alpenglow, a validator earned 1 to 16 credits for each slot it voted on, depending on how quickly its vote landed. This was called Timely Vote Credits (TVC). Every healthy validator ended an epoch with about the same number of credits. Now the same counter holds the validator's rewards in lamports (1 SOL = 1,000,000,000 lamports), before commission: its rewards for votes plus its rewards for producing blocks. A validator with more stake shows more credits, even if it votes exactly as well. Ranking by credits would mostly rank validators by stake, so this site no longer does it. The site's address still says TVC, but it no longer measures TVC.

Votes counted (vote inclusion rate, VIR)

The vote inclusion rate (VIR) is the share of paying blocks that included a validator's vote. The VIR column shows it as a percentage, and Missed shows how many paying blocks left the vote out. VIR does not depend on stake: a small validator and a large one that are both in every paying block both score 100%. A healthy validator is counted in every paying block, or very close to it, so many validators tie at or near the top.

While this page is open, we read every validator's reward counter from a Solana RPC server (a server that answers queries about the chain) about every 5 seconds. We call the time between two readings an interval. For each interval we work out how many paying blocks there were (the same number for every validator) and how many of them included each validator's vote. Each validator earns its own fixed amount for every block that includes its vote. So, if it produced no block in the interval, the increase in its counter divided by that amount is the number of blocks that included it. It is a count, not an estimate.

Each bar in the monitor is one interval, labelled "counted in X of Y blocks". The monitor also adds up every interval since you opened it. The table shows the result for every validator over the last 5 minutes of measuring; the column header says how many seconds that covers. Right after the page opens, VIR reads "…" until the first intervals are measured. When nobody has the page open, nothing is measured.

The first measurement of each epoch takes 10 to 30 seconds, because we need to learn each validator's reward per block, which changes every epoch. After that, every new measurement needs about 20 to 30 seconds (100 paying blocks) before it shows a status. Until then the validator shows Measuring.

Colours in the monitor

Green: the vote was in every paying block of the interval.
Amber: it was missing from some of them.
Red: it was in none of them.
Purple: the validator produced a block in the interval. Its extra reward as leader hides the vote count, so we leave the interval out.
Grey: we could not measure the interval reliably (for example, the two readings came from different RPC servers, or we are still learning the validator's reward per block). It never counts as a miss.
Empty outline: there were no paying blocks in the interval, so nobody missed anything.
Hatched (on an amber or red bar): other validators holding at least 5% of the stake missed the same number of blocks in the same interval. That usually means the leader of those blocks left their votes out, not that this validator failed. These misses are shown, but they are not held against the validator in its status.

Status

Statuses appear once the first intervals since the page opened are measured; until then they read Measuring. Under review and in the migration epoch the table shows only whether a validator is delinquent.

OK: in the last 5 minutes, counted in at least 98% of paying blocks, with hatched misses not held against it.
Missing votes: below 98% on the same basis.
Not voting: not counted in any of its last 32 or more paying blocks. The validator is offline, or its votes are not reaching the leaders.
Delinquent: none of its votes has been counted in the last 128 slots (about 27 seconds). Under Alpenglow, a vote counts only when a block includes it or when the validator signs the finalization of a block. A validator outside this epoch's active set (the validators that can earn rewards this epoch; for example, because its vote account could not pay the 0.8 SOL per-epoch Validator Admission Ticket, or it has no BLS key) is always delinquent.
Measuring: not enough data yet (see above).
Not measurable: its stake is too small (below a few hundred SOL today; the limit moves a little each epoch) to learn its reward per block reliably.

Validators that are delinquent, not voting, not measurable or still measuring are listed below the ranked ones.

Epoch ratio

The epoch ratio compares what a validator has earned so far this epoch with the most its stake could have earned in the same period. That maximum is its reward for every block produced so far, plus the full leader reward for each block it was scheduled to produce. Commission does not affect it.

About half of what a validator can earn comes from the blocks it produces, so each skipped leader slot weighs as much as thousands of missed votes.

1.00 means it earned everything it could. Missing votes and skipped own blocks lower it. A healthy validator sits around 0.999, just under 1.00, because its own blocks can only carry the votes that reach it in time, and other leaders sometimes leave its vote out.

Differences of a few hundredths of a percent are normal, so positions change often. Use the epoch ratio to compare validators over the epoch, and VIR to see what is happening right now. The ratio is updated every minute. It shows "…" until we know the validator's reward per block, and "—" if we cannot learn it this epoch.

JPool's credit rank also ranks validators by a ratio of rewards earned to rewards possible, with its own formula. Its numbers will differ slightly from ours. Because healthy validators are so close to each other, a small difference in method can move a validator many places.

What you can still compare with older numbers

Skip rate, stake and version mean what they meant before (in epoch 1064 the protocol itself skipped 8 slots during the switch). Delinquency still uses 128 slots, but a vote now counts only when a block includes it or the validator signs a finalization. Last vote is now the latest slot in which the validator's vote was counted; use it only to check that the validator is alive. Vote credits, credit ranks and vote latency cannot be compared across the switch: credits are now rewards in lamports, and votes are no longer on-chain transactions. Epoch 1064, the migration epoch, mixes both systems and is not measured.

Was it the validator or the measurement?

Grey intervals, or a "Measurement under review" or migration banner: the measurement.
Hatched misses, or the cluster banner (shown when validators holding at least 20% of the stake missed blocks in the last interval): the leader of those blocks, or the cluster.
Only this validator is missing votes, or its last vote stopped moving: the validator, or its setup.

Limitations

We only measure while someone has a monitor open, and the table keeps only the last 5 minutes. Measuring stops when you close the monitor or switch to another tab. The numbers start again at the beginning of each epoch. The data comes from public Solana RPC servers and relies on how Agave, the main validator software, currently records rewards. If that changes, we show a "Measurement under review" banner instead of numbers until we update the method.