Solana Token Metrics Explained, Figure By Figure

Every figure on a Solana token dashboard is a derived number, not a measurement. Each one is produced by a formula applied to indexed chain data, and each formula depends on inputs of very different quality. Supply comes straight from the mint account and is hard to dispute. Circulating supply is an editorial judgement. Volume depends on which venues an indexer covers. This page defines the nine core figures, names the input each one inherits, and gives you a reading order.

What a token dashboard actually is

It helps to picture the pipeline once. A dashboard is an aggregation layer sitting on top of an indexer. The indexer subscribes to chain data, decodes transactions it recognises, and writes structured events into a database. The dashboard then runs queries against that database and formats the answers into the page you see. Nothing in that chain observes a market directly.

Three consequences follow, and they explain most of the confusion readers have about token data. First, coverage is a choice: if the indexer does not decode a particular program, trades through that program do not exist as far as the dashboard is concerned. Second, valuation is a choice: a swap of one token for another has no dollar value until someone picks a reference price for one side. Third, freshness is a choice: recomputing an expensive figure on every block is not economical, so some numbers lag.

The three families of token metric

The nine or ten figures on a standard page fall into three families, and the families matter because members of the same family share inputs. If circulating supply is wrong, market cap is wrong and the liquidity ratio is wrong in exactly the same direction. They are not independent confirmations of each other, even though a dashboard presents them as separate facts.

• Supply-derived. Total supply, circulating supply, market cap, fully diluted valuation. All of them descend from the mint account plus a decision about which balances are in circulation.
• Flow. Volume, transaction count, unique wallets, buy and sell ratios, price change over a window. All of them descend from the indexed set of swap events in a chosen window.
• Distribution. Holder count, top holder share, liquidity, liquidity lock status. All of them descend from the current set of token accounts and pool accounts.

Reading across families is where the useful work happens. A flow figure divided by a distribution figure produces a ratio that is much harder to manufacture than either input, which is the central idea this desk keeps returning to.

Every figure, its formula and its weak input

This table is the reference version of the whole site. Each row states what the figure counts, the arithmetic behind it, the input it inherits that can be soft, and the characteristic way it fails. Nothing here is specific to any token.

Supply-derived figures

An SPL token mint is an account with a fixed layout. It carries the supply, the number of decimals, the mint authority and the freeze authority. Supply is stored as an integer in base units, and the decimals field tells you where to put the point. Native SOL uses nine decimals, so one SOL is 1,000,000,000 lamports; SPL tokens choose their own, and six is common on Solana launches. The SPL token documentation describes the account layout in full.

Total supply, then, is not a matter of interpretation. You read it. Two things about the mint account matter more than the number itself. If the mint authority is still set to a live address, more supply can be created, and any valuation you compute is a snapshot of a variable. If the freeze authority is set, individual token accounts can be frozen, which is a different risk with the same source.

Circulating supply is where judgement enters. It is total supply minus balances the provider considers not in circulation: team allocations, unvested tranches, treasury holdings, sometimes burn addresses. There is no protocol-level definition of circulating supply. There is only a policy, and it is applied by people who cannot inspect every allocation agreement behind a token.

The full comparison between the two valuations, including how to reconstruct both from mint data, is in market cap vs FDV. It is the single most consequential distinction in this family.

Flow figures

Flow figures describe activity in a window. Volume sums the value of swaps; transaction count tallies the number of them; unique wallets counts distinct addresses involved; the buy and sell split compares the two directions. All of them are computed from the same underlying event set, which means a gap in venue coverage damages all of them together.

Volume is the figure most often quoted and the least often defined. To turn a swap into a dollar amount, the indexer must pick a side to value and a price to value it at. A swap of a token for SOL is naturally valued through SOL, but the SOL price itself comes from elsewhere. A swap of a token for a stablecoin is easier. A route that passes through two pools raises a genuine question: is that one trade or two? Providers answer differently, and the answer can double a headline.

Transaction count avoids the pricing problem entirely, which makes it more robust and much less informative. It cannot tell a one-lamport trade from a large one. Its real value is as a denominator: volume divided by transaction count gives you average trade size, which is the first derived figure worth computing on any token page. That relationship is worked through in detail in volume vs transaction count.

It is worth being explicit about why flow figures are the softest family in practice. Producing on-chain trades is not difficult. Any operator can fund a set of wallets and route swaps through pools on a schedule, and each of those swaps is a real transaction paying real fees. Tools built for this purpose, from a single-venue script to a Solana volume bot that spreads activity across several venues, produce events that are indistinguishable from organic ones at the event level. No indexer can label them, because there is nothing to label.

Distribution figures

Distribution describes state rather than activity: who holds the token right now, and how much value sits in pools. These figures are computed by scanning accounts rather than events, which makes them expensive to refresh and therefore more likely to be stale than volume or price.

Holder count is the number of token accounts with a non-zero balance. Read that definition twice, because it explains nearly everything about how the figure misleads. A pool is a token account. A program vault is a token account. One person can open many token accounts. The count is real, but it counts accounts, and the reader almost always translates it to people. Holder count and what it hides takes that apart properly.

Liquidity is the value of reserves in pools associated with the token, usually reported as both sides added together. This convention matters: a pool holding 500 SOL and the token equivalent is commonly reported as the full round-trip value, not the SOL side alone, so the number that looks like available exit liquidity is roughly twice what you could realistically extract before impact takes over. The relationship between that figure and valuation is the subject of the liquidity to market cap ratio.

The reading order that catches contradictions

Most people read a token page in the order the interface presents it, which is normally price first, then volume, then everything else. That order is designed for engagement. A diagnostic order runs the other way, from the hardest input to the softest, so that a soft figure cannot borrow credibility from the layout.

1. Mint state. Total supply, decimals, mint authority, freeze authority. If the mint authority is live, treat every valuation below as provisional and say so in your notes.
2. Liquidity. How much value is in pools, in how many pools, and on which venues. This bounds everything else: no valuation can be realised faster than liquidity allows.
3. Distribution. Holder count and top holder share, with pool and vault accounts identified and set aside before you read the percentage.
4. Flow. Volume and transaction count together, never one without the other, and always as a ratio against liquidity.
5. Valuation. Market cap and FDV last, because they are the softest figures and the most persuasive. By the time you reach them you already know whether they mean anything.

The point of the order is contradiction detection. A token with heavy volume, thin liquidity and a small number of independent-looking wallets is telling you something specific. If you read valuation first, you arrive at the flow figures already anchored to a number, and anchoring is exactly what a manufactured page relies on.

Worked example: reading one page in order

Notice what the exercise did not require: no proprietary data, no API key, no paid tier. Four divisions on figures already printed on the page produced a sharper picture than any of the headline numbers on their own. This is the whole method, and the rest of the site is that method applied one metric at a time.

What none of these metrics can tell you

Being clear about the ceiling matters as much as the definitions. There is a category of question that on-chain metrics simply cannot answer, and pretending otherwise is how confident analysis becomes wrong analysis.

• Who is behind an address. Chain data shows behaviour, never identity. Funding graphs narrow the space of explanations; they do not close it.
• Intent. A large sell and a rebalance look identical on chain. So do a market-making inventory adjustment and a distribution event.
• Whether activity is organic. There is no on-chain marker distinguishing a trade placed by a person from one placed by software. Both pay the same fee and produce the same event.
• What happens next. Every metric here is backward-looking. A ratio that describes fragility describes it now, not on a schedule.

That last limitation is worth sitting with. When operators run a multi-DEX Solana volume bot across several pools, the resulting activity is genuinely on chain in every respect. The interesting question is therefore not whether volume is real, since it is, but whether the volume is accompanied by the things volume normally drags along with it: deepening liquidity, a widening spread of trade sizes, growth in funded independent wallets. When flow rises and none of its usual companions move, the ratio table tells you before the headline does.

A five-minute first pass

This is the compressed version of the reading order, written as things to write down rather than things to look at. The act of recording an answer is what stops the pass from collapsing into a glance.

• Total supply and decimals, taken from the mint account rather than the dashboard summary.
• Mint authority and freeze authority: present or revoked, recorded as a yes or no.
• Number of pools, and the reserve value of the largest one on its own rather than the summed total.
• Volume divided by liquidity, as a plain multiple.
• Volume divided by transaction count, as an average trade size.
• Transactions divided by unique wallets, as an activity-per-address figure.
• Top ten holder share, after pools, vaults and known program accounts are removed from the list.
• The gap between market cap and FDV, expressed as a ratio rather than two separate numbers.
• One line naming what you could not verify, which is the most valuable line in the set.

Run this on a few tokens and the ratios start to have a felt range. That range is the actual skill here. No individual figure on a dashboard is a lie, but a page is arranged to be read in a particular order, and reading it in a different order is most of the defence. When you are ready to make the pass repeatable, the scorecard template turns these nine lines into a record with pass conditions written before you look.

Questions the desk gets asked