The dashboard above is a Solana network stats page that refreshes in your browser: current slot, epoch progress, total and non-vote TPS, SOL price and market cap, circulating supply, validator count, active stake, delinquent validators, block height, total transactions, a 30-minute TPS chart and the ten largest validators by stake. Nothing is cached on our server. Each number comes from a public mainnet RPC node or a price API the moment you load the page. That makes it useful for a quick health check, but numbers only help if you read them correctly, so the rest of this page explains each metric, how a Solana explorer computes TPS, and the mistakes I see most often in tweets and dashboards.
How to read the Solana explorer TPS numbers
TPS on a Solana explorer is transactions per second over a recent sample window, and on Solana it always includes a large share of validator votes. Validators vote on blocks by sending ordinary transactions, so “total TPS” mixes consensus traffic with user activity. The “non-vote TPS” figure strips those votes out and is the one that tells you how busy the chain really is.
On 23 September 2026 we took ten one-minute samples from mainnet. Total throughput was about 4,000 to 4,300 transactions per second and non-vote throughput about 1,400 to 1,800, roughly 40% of the total. The widget shows the most recent 60-second sample for both, and the chart plots the last 30 samples so you can see whether a spike is a trend or a blip.
Two points to keep in mind. First, TPS counts transactions, not instructions or value moved: one Jupiter swap with six instructions is one transaction, and so is a spam transfer of one lamport. Second, failed transactions are still included, because a failed transaction still lands in a block and still pays its fee. If you want to see what a single transaction did, our transaction explorer guide walks through the detail page.
Common misreading: comparing Solana's total TPS with another chain's TPS. Most chains do not put consensus votes on-chain as transactions, so the fair comparison is Solana's non-vote TPS.
Where Solana explorer TPS comes from: getRecentPerformanceSamples
Almost every Solana explorer derives TPS from one RPC method, getRecentPerformanceSamples. Each sample covers a 60-second window and reports the number of transactions, the number of non-vote transactions, the number of slots completed and the window length. You can ask for up to 720 samples, which is about 12 hours of history.
The calculation is simple: divide numTransactions by samplePeriodSecs for total TPS, and numNonVoteTransactions by the same period for non-vote TPS. Vote TPS is the difference. Our dashboard does exactly that on the newest sample and also computes average slot time as window length divided by slots completed. Explorers differ mainly in which window they show. Some display the latest sample, some average an hour, and some round aggressively. That is why Solscan, Solana Explorer and Orb can disagree by several hundred TPS at the same moment and all be correct. If you want to reproduce it in your own code, the Solana explorer API guide shows how to call these methods.
Slot time, block height and SIMD-0525
A slot is the time window in which one scheduled leader can produce a block. For years the target was 400 ms. SIMD-0525 is lowering it in 50 ms steps toward 200 ms, and the change rolled out through August and September 2026. Our own measurement over the last 100,000 slots on 23 September 2026 averaged about 265 ms per slot, consistent with the 250 ms stage.
The slot counter in the widget ticks locally between refreshes using the measured slot time, then re-syncs with the RPC node, so it may jump by a few slots now and then. That is expected.
Block height is not the same as slot number. When a leader misses its slot, no block is produced, so block height grows more slowly than the slot counter. If you see a large gap between the two, that is the accumulated history of skipped slots, not an error.
Epochs: 432,000 slots, now about 32 hours
An epoch is a fixed run of 432,000 slots, and the leader schedule, stake activation and staking rewards all change at epoch boundaries. The slot count per epoch did not change with SIMD-0525; the duration did. At about 265 ms per slot an epoch lasts roughly 32 hours, while at 400 ms it took about two days. Guides that still say “an epoch is two to three days” are out of date.
The dashboard shows the current epoch number (epoch 1040 when we checked on 23 September 2026), progress as a percentage and an estimated time left. The estimate multiplies remaining slots by the current slot time, so it drifts slightly if slot times change mid-epoch. If you are waiting for stake to activate or for rewards to arrive, the validator and staking explorer guide explains what happens at the boundary.
Total supply vs circulating supply of SOL
Total supply is every SOL in existence; circulating supply excludes accounts the protocol classifies as non-circulating. Both come from the getSupply RPC method, which returns total, circulating and non-circulating amounts in lamports, plus the list of non-circulating accounts. On 23 September 2026 it returned about 634.5M SOL total and 587.5M SOL circulating.
Total supply rises over time because staking rewards are paid from inflation, and it falls slightly because half of every base fee is burned. So do not expect it to match a figure from last year. The market cap on the dashboard comes from a price API, and those services apply their own circulating-supply methodology, which may not match the RPC number to the last million SOL.
Validators, active stake and delinquency
The validator tiles come from the getVoteAccounts RPC method. “Validators” counts vote accounts that are currently voting, “delinquent” counts those whose last vote trails the tip by more than 128 slots, and “active stake” adds up the stake delegated to current vote accounts. When we checked on 23 September 2026 mainnet reported 676 current and 12 delinquent vote accounts, 688 in total.
Two cautions. A vote account is not the same as an operator: one company can run several validators, and a number of small vote accounts carry almost no stake. And delinquency is noisy. With slots at around 265 ms, 128 slots is only about half a minute, so a validator restarting for an upgrade briefly shows as delinquent. The top-validators list under the chart shows each validator’s stake, its share of total active stake and its commission. Adding up shares from the top is a quick way to see how concentrated stake is, which we discuss in the validator explorer guide.
Where this dashboard gets its data
Every tile is fetched by your browser, not by our server, so you see what a public node reports at that moment. Slot, epoch, block height and the total transaction count come from getEpochInfo. TPS, slot time and the chart come from getRecentPerformanceSamples. Supply comes from getSupply, and the validator tiles from getVoteAccounts. We send these calls to a small pool of free, keyless mainnet endpoints, including the Solana Foundation’s api.mainnet-beta.solana.com, and move to the next one if a node rate-limits or times out.
The “total transactions” tile deserves a note. The RPC documentation defines it as the total number of transactions since genesis, “if available”, and it counts vote transactions as well as user transactions. It is a big, round-looking number that grows by several thousand every second, which makes it good for a sense of scale and useless for comparing activity between two days. For that, compare non-vote TPS at similar times of day.
The SOL price and 24-hour change are not on-chain data at all. They come from CoinGecko, with Jupiter’s price feed as the backup, so a price that looks stale is a price-API issue and says nothing about the health of the network.
Quick reference: what each dashboard metric means
Use this table as a cheat sheet when a number looks surprising.
| Metric | What it measures | Watch out for |
|---|---|---|
| Total TPS | All transactions in the last 60 s | Includes validator votes |
| Non-vote TPS | User and program transactions | Includes failed transactions |
| Slot / block height | Time windows vs blocks produced | Gap equals skipped slots |
| Circulating supply | SOL outside locked accounts | Price sites may differ |
| Delinquent | Vote accounts behind by 128+ slots | Brief upgrades count too |
When the numbers look wrong
If the dashboard shows dashes or stale values, the public RPC node that answered probably rate-limited your browser or timed out. Solana’s public endpoints allow about 100 requests per 10 seconds per IP and are not meant for production use, so we rotate across several free providers. Reload once. If every explorer stalls at the same time and the slot number stops moving, check status.solana.com and our guide for when a Solana explorer is down.
A sudden TPS spike is usually a bot or airdrop campaign, not organic growth. To see what is behind it, grab a recent slot number from the dashboard and paste it into our lookup tool, which lists the block’s transactions. For a broader comparison of which explorers show network stats best, see our ranking of Solana explorers.
By the Solscanner research deskUpdated · Review methodology