Definitions, formulas, data sources and caveats for every Solana Observer metric, with a glossary of Solana terms and the rules for weights and aggregation.
Whenever a per-unit metric (a rate, a per-block value, a latency) is rolled up from individual validators to a client, scheduler, or network figure, Solana Observer takes a weighted average rather than a plain mean of the per-validator numbers. The weight makes each validator's contribution proportional to its real footprint on the network.
Inflation rewards, Jito tip recipients, vote credits, voted slots, and vote credits per slot are reported at their native epoch grain. Validator economics also needs a daily view, so those flows are allocated by the exact portion of each epoch that overlaps each UTC date.
Each validator gets one label per UTC day, with the same rules as schedulers.watch. The label has a client, a scheduler, and two optional splits: the FD submode and the Harmonic strategy.
A handful of conventions apply to every metric on the dashboard. They are stated once here so the per-metric cards can stay focused on what is specific to each number. 1 SOL = 1,000,000,000 lamports, the conversion applied to every raw lamport value.
How Solana's ~400 million SOL of delegated stake is spread across the validator set, and how that concentration has changed over time. These metrics are the primary lens for assessing decentralization and network security.
Total SOL delegated to validators that is eligible for leader-slot assignment and inflation rewards in the current epoch. The core measure of economic security: the higher and more widely distributed the active stake, the more expensive it is for any coalition to attack the chain.
Each validator's active stake in SOL is recorded daily. At the network level, all validator stakes are summed to produce the total. The same sum is applied within each client, scheduler, or country group. A USD equivalent is computed using the daily average SOL price.
Number of distinct validators active on a given calendar day. At the network level this is strictly validators that produced at least one block; at client and scheduler groupings it is validators with valid stake data. Tracks whether the active validator set is growing or consolidating.
At the network level, a validator is counted if it produced at least one block that day. For client and scheduler views, a validator is counted if it has an active stake recorded, which may include validators that did not produce any blocks that day.
The minimum number of top-staked validators, ranked by active stake, largest first, whose combined stake reaches or exceeds 33.34% of total network active stake. This is the size of the smallest coalition that could halt the chain by refusing to vote. A higher number means greater decentralization.
Validators are ranked by active stake from largest to smallest. The superminority count is the smallest number of top-ranked validators whose combined stake reaches or exceeds 33.34% of total network active stake. This is the smallest coalition that could halt the chain by refusing to vote.
The percentage of total network active stake held by the top N validators (by stake), for N ∈ {1, 3, 5, 10, 25, 50, 100}. A direct concentration indicator: lower values signal more even stake distribution; rising values indicate stake is gravitating toward a smaller number of large validators.
Validators are ranked by active stake from largest to smallest. For each value of N (1, 3, 5, 10, 25, 50, or 100), the combined stake of the top N validators is divided by total network active stake and expressed as a percentage.
Total network active stake expressed as a percentage of the circulating SOL supply on the same day. Measures what fraction of liquid supply is actively securing the network; higher values indicate stronger economic participation in consensus.
Total network active stake is divided by the circulating SOL supply on the same day and expressed as a percentage. Circulating supply covers the period from 2025-01-01 onward.
The stake-weighted geographic centroid of the validator set, a single (latitude, longitude) point summarizing where network security is physically concentrated. Movement toward a single country or continent indicates growing geographic centralization risk.
Each validator's active stake is used as a weight, and the stake-weighted average of each validator's datacenter latitude and longitude produces a single geographic centroid for the epoch. That centroid is applied to every calendar day within the epoch.
How much work the network and its validators are doing: blocks produced, slots skipped, compute consumed, and transaction throughput. Drawn from Firedancer validator reports and Dune Analytics network-level data.
Fraction of assigned leader slots that produced no accepted block, expressed as a percentage. A skipped slot most commonly reflects slow block propagation, poor connectivity, or hardware overload on the leader validator. Lower values indicate a healthier network and more reliable validators.
Skip rate is the percentage of assigned leader slots that produced no accepted block. For any group, the rate is computed from total skipped slots divided by total leader slots across all validators in that group, not as an average of individual validator rates.
Network-level transaction throughput in transactions per second, broken down along two independent dimensions: outcome (total / successful / reverted) and type (total / vote / non-vote). The headline 'real TPS' figure is successful non-vote TPS, which strips out consensus vote traffic and failed transactions to reflect genuine user demand.
Daily average transactions per second is computed from on-chain data. TPS is available across nine combinations of outcome (total, successful, or reverted) and type (total, vote, or non-vote). The headline real TPS figure is successful non-vote TPS, which strips out consensus vote traffic and failed transactions to reflect genuine user demand.
Compute units (CUs) consumed per block. One CU corresponds roughly to one BPF instruction. Each block is capped at up to 100M CUs at 400 ms slots (raised from 48M to 50M in April 2025, to 60M in July 2025, and to 100M on 2026-07-29 via SIMD-0286 at epoch 1009, slot 435,888,000). SIMD-0525 then cuts the cap with each slot-time step: 87.5M at 350 ms, 75M at 300 ms, 62.5M at 250 ms and 50M at 200 ms. Higher average CU usage indicates blocks are fuller; sustained near-cap usage suggests network congestion.
Firedancer reports average compute units per block for each validator each day, along with 10th, 50th, and 90th percentile values across that validator's blocks. Network, client, and scheduler figures are a blocks-produced weighted average across all validators in the group. A 7-day rolling average is available at the network level.
Compute units (CUs) that blocks consume per second of time. When slots get shorter, CU per block falls, but CU per second shows whether the network does more or less work.
The network mean is the cost units of all blocks of the day divided by 86,400 seconds. For a client, scheduler or validator, the mean is the cost units of its blocks divided by the time of those blocks. The percentiles (P10, P50, P90) divide the cost units of each block by its own duration. A block has no duration when the next slot has no block, or when the duration is outside 0 to 5,000 ms. The Outcome, Type and % views work as on Compute Units Per Block.
Blocks produced is the count of blocks a validator (or group) successfully produced and had accepted by the network on a given day. Leader slots is the total count of slots assigned to a validator as leader, both successful and skipped. Together they establish the denominator and numerator of block production efficiency. The daily slot count follows the target slot time: about 216,000 at 400 ms and 432,000 at 200 ms (SIMD-0525, from October 2026).
Firedancer’s raw blocks count is assigned leader slots. The mart stores that count as leader_slots and derives blocks_produced (and curated blocks) by subtracting skipped slots. The daily slot count is 86,400 seconds divided by the average slot time: about 216,000 at 400 milliseconds per slot, and more when slots are faster.
Percentage of transactions included in a block that reverted (failed execution). A transaction that is included in a block but whose program logic fails still consumes compute and fees; it is counted as reverted, not as a dropped transaction. The non-vote revert rate is the primary user-facing failure signal because vote transactions almost never revert.
The revert rate is the percentage of transactions included in a block that failed execution, available for three types: total, vote, and non-vote. A transaction that is included but whose program logic fails is counted as reverted, not as dropped.
How long each produced block takes on Solana, measured from Trillium's per-validator slot-duration telemetry. All metrics are blocks-produced–weighted so that high-throughput validators drive the aggregate in proportion to their actual share of block production. The target slot time was 400 ms until August 2026 and is 200 ms from October 2026 (SIMD-0525).
The blocks-produced-weighted arithmetic mean of each validator's average slot duration in the epoch. Each validator's contribution is scaled by how many blocks it produced, so high-throughput validators drive the aggregate proportionally and the result reflects the network-wide average experienced across actual block production rather than a simple average over validators.
Each validator's mean slot duration for an epoch is weighted by the number of blocks that validator produced. The network figure is the sum of (mean slot duration times blocks produced) divided by total blocks produced across all validators with valid data. Validators that produced no blocks in the epoch are excluded.
The blocks-produced-weighted P50 over each validator's own within-epoch median slot duration. Because the ranking uses validators' medians rather than their averages, this is a weighted median-of-medians: it is less sensitive to validators with a few extremely long blocks than the average, but it is not the true median across all individual blocks network-wide.
Validators are ranked by their within-epoch median slot duration (not their mean), and a blocks-produced weighted quantile is computed at P50. The result is the median slot duration of the validator at the midpoint of cumulative block production. If a validator lacks a median reading, its mean slot duration is used instead.
Nine blocks-produced-weighted quantiles (P1, P5, P10, P25, P50, P75, P90, P95, P99) of the distribution of validators' average epoch slot durations. P1 marks the average block time below which the fastest 1% of block production (by blocks produced) falls; P99 marks the boundary above which the slowest 1% falls. Every percentile ranks validators by their average slot duration.
Validators in an epoch are sorted by their mean slot duration and a blocks-produced weighted cumulative distribution is built. Nine fixed quantiles (P1, P5, P10, P25, P50, P75, P90, P95, P99) are taken as the first validator whose cumulative block-production weight crosses each threshold. No interpolation is applied between validators.
Block time split by FD submode (BAL, BUN, PRF, BDL, PBL, AUC, PUF) and by Harmonic strategy (FBA, MREV, FIFO). It shows whether different scheduling strategies produce measurably different slot durations. It uses the same blocks-produced–weighted average and percentile method as the network view.
The same blocks-produced weighted average and percentile method used for the network view is applied separately to each split group, such as Frankendancer Jito · BAL or Agave Harmonic · FBA. Validators without a submode or strategy stay in their parent scheduler group.
Three complementary measures of Solana block economics, REV (user-paid demand), Block Revenue (validator-received), and Total Block Value (all-in including inflation), built from four fee/tip components and normalized per block, per second, or per compute unit.
Total network-wide signature fees charged each day. Every included signature costs exactly 5,000 lamports (vote transactions use the same mechanic). 50% of base fees are permanently burned; 50% are paid to the block-producing validator.
Every included signature costs exactly 5,000 lamports. Non-vote base fees are summed across all transaction signatures per block, and vote base fees are summed separately. Both are averaged per block, then multiplied by the day's block count to recover daily totals.
Total network-wide priority (compute-budget) fees collected each day. Priority fees are optional payments that boost inclusion priority; they are determined by the requested compute unit limit and price, not actual CUs consumed. Post-SIMD-0096 (2025-02-14), 100% of priority fees go to the validator. Pre-SIMD-0096, 50% were burned.
Priority fees are isolated by subtracting the base-fee portion (signatures times 5,000 lamports) from each transaction's total fee. The result is averaged per block, then scaled to a daily total using the day's block count.
Real Economic Value: the total daily economic value users paid for Solana blockspace. Defined per Blockworks Research as the sum of all four fee/tip components, counting base fees at 100% (pre-burn). The burned half is included because it represents real economic cost to the user, even though it is destroyed.
REV sums base fees, priority fees, Jito tips, Rakurai tips, and Other inclusion-service tips per block, then multiplies by the day's block count. Per-second and per-CU views use the same denominators.
Daily validator-realized revenue from transaction activity: the economic value validators actually receive after the base-fee burn. Differs from REV in that base fees are counted at 50% (the kept half only). Excludes inflation.
Block Revenue uses the kept half of base fees, the historically retained priority-fee share, and Jito, Rakurai, and Other inclusion-service tips. Per-block, per-second, and per-CU views use the same denominators as REV.
The broadest daily measure of block-production economics: all transaction fee/tip revenue (at 100% base fees) plus the day's inflation issuance. Represents the full economic output associated with producing Solana's blocks.
Total Block Value adds actual Dune issuance to REV. Issuance is allocated by exact epoch/day overlap and divided by block count for per-block views. If issuance is unavailable, Total Block Value remains blank rather than silently degrading to REV.
All major fee/REV metrics are available in three normalized intensity views: per block (raw block-level average), per second (block average ÷ block duration), and per compute unit (block average ÷ block compute units). These reveal demand intensity independently of block count or throughput changes.
Per-block values are the direct daily block-level averages. Per-second divides the per-block figure by average block duration in seconds; per-CU divides it by average compute units. Either view returns no value when its denominator is missing or zero.
How much SOL validators and stakers earn, and from which sources. Inflation rewards are protocol-minted (dilutive); tips and priority fees are demand-driven (non-dilutive). APY figures decompose total yield into its constituent parts so you can track the shifting balance between base-rate staking income and market-driven extras.
Network-wide Jito tips annualized as a percentage of active stake. Answers: if Jito tips paid out at today's rate every day of the year, what annual yield would a staker see? Formerly labeled 'MEV APY' and renamed because Jito bundles are the source; in these figures MEV refers to Jito tips, and non-Jito MEV is tracked separately.
Daily Jito tips paid to the network are divided by total active stake and multiplied by 365 to annualize. This is simple, non-compound annualization: the daily rate is scaled linearly, not compounded.
Network-wide tips from transaction-inclusion services other than Jito and Rakurai, annualized as a percentage of active stake. The flows are estimated from classified onchain transfers.
Other inclusion-service tips, explicitly excluding Jito and Rakurai, are divided by active stake and multiplied by 365. The flows are estimated from onchain transfer patterns rather than decoded provider distribution contracts.
Total annualized staking yield per unit of stake, combining inflation rewards, priority-fee block rewards, and Jito tips. Compound (assumes rewards are reinvested each epoch). The single headline number for 'what did staking pay?'
Per-validator compound overall APY is provided by Trillium and covers all yield sources: inflation rewards, priority-fee block rewards, and Jito tips. The network figure is the stake-weighted average across all validators with a valid reading. The exact compound formula is provided by Trillium and is not reproduced here.
The two primary sub-components of Overall APY: (1) Inflation APY, yield from protocol-minted SOL that dilutes all holders; and (2) Block Rewards APY, yield from priority fees plus Jito tips, driven by user demand. Watching the ratio shows whether staking yield is protocol-guaranteed or market-earned. Both are available for delegator, validator operator, and combined (total) recipient.
Overall APY is decomposed into two sub-components provided by Trillium: Inflation APY (yield from protocol-minted SOL) and Block Rewards APY (yield from priority fees and Jito tips combined). Each is a stake-weighted average at network level. Delegator, validator-operator, and combined-total views are all available.
New SOL minted each day through the inflation schedule, split into staking inflation (delegator rewards) and voting inflation (validator consensus rewards). Total issuance is the network's 'cost of security.' The annual inflation rate follows a deterministic decay schedule toward a 1.5% terminal floor.
Staking and voting rewards are summed from onchain reward records. Each complete payout epoch is allocated to UTC dates using exact seconds of overlap. Payout epoch e + 1 supplies the network total earned in epoch e; Trillium supplies delegator and validator attribution.
Total SOL in existence, split into circulating (freely transferable) and non-circulating supply. The latest point comes from finalized Solana RPC getSupply. Historical reconstructed and estimated rows carry explicit provenance fields.
Historical total supply from March 5, 2026 is reconstructed from Dune issuance minus burned base fees and anchored to finalized RPC. The historical circulation split comes from the approved Blockworks snapshot through July 16; July 17–19 is an explicitly labeled bridge. Finalized RPC snapshots continue prospectively.
Validators vote on every block to drive Solana's consensus. These metrics measure how reliably and quickly validators cast those votes, and how efficiently they convert participation into the TVC (Timely Vote Credits) rewards that determine their inflation share.
The number of slots between when a block is produced and when the validator's vote for that block is confirmed on-chain. Reported as a daily average and as tail percentiles. Measured in slots; the physical minimum is 1 slot, a vote cannot land before the slot it votes on.
Firedancer reports each validator's average vote latency and tail percentiles (P90, P95, P99) for the day. When rolling up to a client or network figure, each validator's value is weighted by the number of votes it cast that day, so validators that cast more votes carry proportionally more weight.
Percentage of votable slots in which the validator submitted a successful on-chain vote. A missed vote forfeits both vote credits and the associated inflation reward for that slot.
For each validator, the vote success rate is votes landed on-chain divided by total votable slots (successful plus missed votes), as a percentage. At client and network level the rate is recomputed from pooled totals rather than averaging per-validator percentages, giving each slot equal weight.
Protocol vote credits earned per voted slot during an epoch. The theoretical maximum under TVC is 16. The metric primarily measures timeliness among slots where a vote was recorded; missed slots are shown separately.
For each vote account and epoch, protocol credits are credits minus previousCredits. The mart joins that delta to Trillium by vote account and epoch, falls back to Trillium credits when RPC history is unavailable, and divides resolved credits by voted slots. The same numerator/denominator formula is used after pooling network, client, or scheduler totals.
Percentage of a validator's votes that land in exactly the next slot after the target block (1-slot latency). This is the best achievable vote latency under TVC and earns the maximum 16 credits per vote.
The latency-1 rate is the fraction of a validator's votes that landed in exactly the next slot after the target block. At client and network level the rate is vote-count weighted: each validator's rate is multiplied by its votes cast, the products are summed, then divided by total votes cast across the group.
Percentage of votes that land within 1 or 2 slots of the target block (cumulative, includes both latency-1 and latency-2 votes). Under TVC, all votes at ≤2-slot latency earn the maximum 16 credits per vote, making this the threshold for full credit capture.
The latency-2 rate is the fraction of a validator's votes that landed within 1 or 2 slots of the target block (cumulative, including latency-1 votes). At client and network level it is vote-count weighted, the same way as the latency-1 rate. A companion count of low-latency votes is also available as an absolute number.
Program-level compute and invocation metrics derived from retained Solana transaction consumed-log messages in Dune Analytics. Each parseable 'Program <pubkey> consumed X of Y compute units' line is one invocation event. The measure includes inner CPI calls and failed execution when logs are present, so it is reported invocation compute rather than proven exclusive block CU. Programs are classified into categories and projects; projects outside the all-time top 100 are collapsed into an 'others' bucket.
Sum of compute units reported by retained program invocation logs each day. It measures program execution demand across the network or selected entities, but does not claim exclusive attribution when parent and inner CPI invocation accounting overlap.
Parseable transaction-log lines report compute consumed by individual program invocations. These values are summed per program per day, then grouped into categories and the top 100 projects by all-time compute. Named projects plus 'others' conserve the retained consumed-log sum, which is not asserted to be exclusive transaction-level block CU.
Number of times Solana programs were invoked each day. This counts program-level invocations (inner instructions), not transaction counts, a single transaction can invoke the same program multiple times.
Each transaction-log line that reports compute units consumed corresponds to one program invocation. These are counted per program per day, then grouped into categories and the top 100 projects, with programs outside the top 100 merged into 'others'.
Each program category's percentage of total daily network compute. Shows whether DeFi, bots, MEV, system programs, or other segments are growing or shrinking relative to the whole.
Each category's daily compute is divided by the network-wide daily compute total and multiplied by 100. All programs contribute to both the numerator and the denominator, so category shares always sum to exactly 100 on any given day. Programs with no category label are grouped into 'others'.
Share of total daily network compute consumed by the 10 largest projects ranked by compute on that day. Tracks market concentration, a rising top-10 share indicates activity is centralizing in a handful of protocols.
Projects are ranked by their total compute on each individual day. The compute consumed by that day's top 10 projects is summed, divided by the network-wide daily total, and multiplied by 100. The ranking is recalculated every day, so the composition of the top 10 can change day to day.
Average compute units consumed per program invocation across the entire network each day. Rising values indicate programs are becoming individually more compute-intensive; falling values suggest lighter or simpler programs are gaining share.
Network-wide daily total compute is divided by network-wide daily total invocations. This is a ratio of two sums, not an average of per-program averages, so heavily invoked lightweight programs can pull the result down even when compute-intensive programs consume more absolute CUs. It returns no value when there are no invocations for the day.