How NanoTicker scores representatives
The six measurements behind every health score, what each one rewards, and why a representative with less voting weight scores higher than one with more.
The health score adds up six measurements of a representative and shows the total as a percentage. It estimates how useful that rep is to the network. Holding less voting weight scores better, on purpose.
The six measurements
All six count equally, so a rep has to do well across the board to score well.
Voting weight
A small share of online weight scores highest.
The only measurement where less is better. The network is safer when many smaller reps share the weight.
Uptime
Consistently online scores highest. Frequent gaps score lowest.
The network cannot use weight sitting behind an offline node.
Connected peers
A high peer count scores highest.
A well connected node hears about blocks sooner, and its votes reach the network faster.
Unconfirmed blocks
A near empty backlog scores highest, and the score falls as the backlog grows.
Blocks the node has received but not yet cemented. A growing backlog means it is struggling to keep up.
Node version
Graded against the newest releases of the node.
The C++ and Rust nodes number their releases independently, so each is judged on its own scale.
Recent votes
Voting at the going rate scores full marks. Only reps well below it lose points.
Counts votes seen from this rep, weighted so recent ones matter more. Proof the node is voting, not just online.
One adjustment sits outside the six: a rep publishing no alias takes a small penalty. An anonymous rep is harder to identify and harder to hold accountable, so a named one edges ahead on an equal record.
Turning that into a percentage
The six scores are summed and shown as a share of the maximum, which gives the percentage on each rep's card. Strong scores show green, middling ones amber, and weak ones red.
The rankings page sorts by that total, so the number beside each rep is its place by health, not by size. Open a rep to see all six measurements with their own ratings, and which one is dragging the total down.
Five of the six need the node to publish telemetry. A rep that publishes none shows as not rated and sits below the scored reps, with no rank. That is missing information, not a verdict: the node may well be running fine.
Why holding less weight scores better
Every other measurement asks whether the node is doing its job well. Voting weight asks something else: would adding more weight here make the network better or worse?
For a rep already holding a large share, the answer is worse. Concentration lowers the Nakamoto coefficient and makes the network easier to stall. A ranking topped by the biggest reps would send weight where it does the most harm.
What the score does not tell you
- It measures the node, not the operator. A high score says the node performs well, and nothing about who runs it.
- Most inputs come from the node's own telemetry, none of it independently verified. A node reporting none is left unrated rather than scored, so an absent reading is never read as a bad one.
- Uptime and vote counts are seen from one vantage point, the NanoTicker node. A rep with connectivity trouble only on that path looks worse than it is.
- It says nothing about where a node is hosted. Several good reps at one provider still share one point of failure, so hosting is tracked separately on the Nakamoto page.
How to use it
Do not just pick the top entry. If everyone chose the same rep, its growing weight would push it straight back down the list.
Pick any rep scoring well that you are happy to support, ideally a smaller one. Spreading weight across many good reps is the whole point, and changing your choice is free and instant. The voting weight explainer covers what delegating does.