Active stake
—
SOL delegated to voting validators
Planetarium No. 06 · Solana mainnet-beta
Validome maps Solana's validator set as a live night sky — who holds the stake, how few it takes to halt the chain, who has gone dark, and what software they run.
Bright cyan stars and the rose constellation = the superminority (smallest group holding >33.3% of stake). Star size ∝ √stake. Live data, not a mock-up.
I · The observatory
Pulled straight from getVoteAccounts, getBlockProduction and getEpochInfo on public Solana RPC. Cached in your browser for 10 minutes so we don't hammer a shared node.
We couldn't reach the public RPC node.
—
SOL delegated to voting validators
—
vote accounts in "current"
—
validators needed to pass 33.3% of stake
—
vote accounts not voting recently
—
stake-weighted mean: —
—
leader slots without a block, this epoch
Validators ranked by stake (x) against the share of total stake they hold together (y). The rose line marks 33.3% — the halting threshold.
How many validators sit in each stake band, and how much stake each band holds.
Validator count by commission rate. Bar fill shows stake share at that rate.
The smallest set of validators that together hold more than one third of stake. If all of them went offline together, the network could not finalize blocks.
Vote accounts the RPC node reports as delinquent — they haven't voted on a recent slot. Stake on a delinquent validator earns no rewards while it is dark.
Which validator software is running the stake? This uses getClusterNodes, a ~1.5 MB response, so it only loads when you ask.
| Status | |||||||
|---|---|---|---|---|---|---|---|
| Loading… | |||||||
II · Mechanism
Your browser sends one JSON-RPC request to a public Solana node for every vote account, its delegated stake, commission and recent vote credits. One request, ~300 KB, cached for 10 minutes.
Validators are sorted largest to smallest. We walk down the list adding stake until the total passes one third — that count is the Nakamoto coefficient, and those validators form the superminority.
getBlockProduction tells us, per identity, how many leader slots each validator was given this epoch and how many blocks it actually produced — the gap is its skip rate. Vote lag compares its last vote to the current slot.
Press "Load client census" and we fetch the gossip table (getClusterNodes), match each validator's identity key, and tally stake by client software and version.
III · Uses
Paste its vote key to see commission, stake, recent vote credits, skip rate and whether it is delinquent right now.
The Nakamoto coefficient and superminority list show how concentrated stake is — and whether your delegation adds to the concentration.
The delinquent list surfaces vote accounts that have stopped voting. Stake there earns nothing until they come back.
See where a validator's commission sits in the whole-network spectrum, both by count and by stake weight.
A network where one client runs most stake is exposed to that client's bugs. The census shows the mix.
The dome and stake curve are a quick way to explain to newcomers why "one third of stake" matters on Solana.
IV · The star atlas
Every validator has two important keys. The identity key (the "node pubkey") signs blocks and gossip messages and pays the voting fees. The vote account is a separate on-chain account that records the validator's votes, its commission and the credits it earns. Stake accounts delegate to the vote account, not the identity — which is why staking tools always ask for the vote key. Validome lets you search by either.
Solana is proof-of-stake: the more SOL delegated to a validator, the more its votes weigh in consensus and the more leader slots it is assigned in the leader schedule, which is computed per epoch (432,000 slots, roughly two to three days). A leader slot is a ~400 ms window in which that validator is expected to produce a block.
If a leader fails to produce a block in its slot — because it was offline, slow, or its block didn't propagate — the slot is skipped. Skip rate = 1 − blocks produced ÷ leader slots. Some skipping is normal across the whole cluster; a validator with a skip rate far above the cluster average is losing its own block rewards and fees.
Inflation rewards are paid per epoch to stake accounts in proportion to the vote credits their validator earned. The validator keeps its commission percentage and passes the rest to delegators. 0% commission is common for validators funded in other ways (for example MEV tips or block fees); 100% means delegators get none of the inflation reward. Commission can be changed by the validator, so it is worth re-checking.
Validators earn credits for voting on blocks that become rooted, with more credits for faster votes (timely vote credits). The epochCredits field lists, for the last few epochs, the cumulative credits at the end and start of each epoch; the difference is what the validator earned that epoch. Similar credits across validators mean similar performance — a big drop is a red flag.
An RPC node marks a vote account delinquent when its last vote is more than a set number of slots (127 by default) behind the tip. Delinquent stake still counts as delegated, but earns no rewards while dark, and it doesn't help consensus.
Solana's Tower BFT consensus needs more than two thirds of stake to confirm blocks. So any group controlling more than one third can stop finalization by going offline together. The smallest such group is the superminority; its size is the Nakamoto coefficient. A higher number means it takes more independent parties to halt the chain. Note: several vote accounts may be run by the same operator, so the real number of independent parties can be lower than the count shown.
Validators run different software: Anza's Agave, Jito's Agave fork with MEV block-building, Firedancer/Frankendancer from Jump, and other forks. If one client holds more than a third of stake, a single bug in that client could stall the network; more than two thirds, and a bug could finalize something wrong. A spread across clients is healthier.
V · Questions
Names and logos live in "validator info" accounts that can only be listed with getProgramAccounts, which the free public RPC we use blocks. Rather than show names from an unverified third-party list, Validome shows keys only. You can copy a key into any explorer to see a name.
It is computed directly from activated stake per vote account at the moment of loading. Other sites may group vote accounts by operator, or by data centre, which gives a lower number. Ours counts vote accounts.
From getBlockProduction for the current epoch: 1 − (blocks produced ÷ leader slots), matched by identity key. Early in an epoch numbers are based on few slots and can swing a lot.
The number of slots between the current slot (from getEpochInfo) and the validator's last vote. A healthy validator is usually within a few dozen slots. Hundreds or more means it is falling behind or offline.
No. Validome is strictly read-only: no wallet connection, no signing, no transactions. Use your own wallet's staking feature and paste in the vote key you chose.
getClusterNodes returns every node in gossip — thousands of entries, about 1.5 MB. We only fetch it when you ask, to keep the page light and be polite to the shared public node.
Not by itself. Uptime (vote credits, delinquency) matters as much: a 0% validator that is dark earns you nothing. Also consider not adding to the superminority, so your stake helps decentralisation.
Everything is fetched live when the page loads, then cached in your browser tab for 10 minutes. The status bar shows the age; press "Refresh data" for a new snapshot.
solana-rpc.publicnode.com. Another RPC node may disagree slightly about delinquency at any instant.