Solana Growth Dashboard
Solana Growth Dashboard
Context
The purpose of this dashboard is to provide insight into usage on the Solana blockchain.
In many cases, it will provide you with the information you're looking for. In some cases, it might serve as a launching pad for deeper analysis.
This dashboard is under active development/maintenance. If you have comments/questions/suggestions/philosophical disputes, please reach out to @dansabermetrics on Twitter.

1. Usage
This section considers the number of “users” active on the Solana blockchain. It also considers the kind of activity they're engaged in.
Note that, here and throughout, we use "fee payment" as our measure of activity. While this has drawbacks (see "Caveats" section below), we think it’s important to track. It's subject to change as we learn more about how builders use the chain.
User states
In the graphs below, we segment fee payers into a handful of common "user states" — namely, "new," "retained," and "reactivated."
New fee payers are those who are active for the first time in a given period, while retained fee payers are those who are active in consecutive periods (i.e., two weeks in a row or two days in a row). Reactivated fee payers are the remainder — active again after continuous usage stopped.
Cohort value
These graphs look at the average "activity/value exchanged" per fee payer in a given cohort. Right now, the measures are excessively coarse. They’re also likely artificially high because a small percentage of hot wallets are dragging up the averages. That ultimately requires its own analysis to understand, after which we will update these graphs.
As with all metrics, there are important subtleties to keep in mind. These two are the most important:
-
What counts as “user activity”?
\
Fortunately/unfortunately, we can never count "unique human beings" active on a blockchain. Although this may change in the future, for now, there are only addresses.
So, with that in mind, we have to consider, what makes an address active?
There are two primary choices: Fee payment and transaction signing. Both measures (and variations thereof) can be useful in different contexts – and have their own pros and cons – but our preferred measurement is fee payment.
Fee payers refer to accounts that signed and paid for a successful transaction in a given period, such as buying an NFT on Magic Eden. The main drawback of fee payment is that many popular apps pay fees on behalf of users (such as StepN), so even though these users are technically "active" on Solana, their activity is not counted. Nevertheless, fee payment is our best proxy for the number of non-custodial wallets active in the Solana ecosystem at any given time. They form the community that makes Solana such a valuable ecosystem to build on.
Transaction signings include any account that signed a successful transaction in a given period, regardless of whether that account actually paid for it. Since many programs pay fees on behalf of users, this measure does a better job of representing usage among such programs. The main drawback is that transaction signings are more likely to include programmatic activity that results in double-counting users.
(NOTE: If we really wanted the most accurate count of “human beings on Solana and Solana-based apps,” ideally we could dynamically determine which programs paid fees on behalf of users and which didn’t. If that capability existed, then we could say: "In most cases, count unique fee payers, but in these specific cases, count unique addresses." Alas, that's a project for another day...)
Finally, in the accompanying graphs, we show "daily/weekly active users" calculated in several different ways. They tend to be correlated.
-
What counts as “program usage”?
\
Programs can be called in two ways — by an end user or by another program, which is also known as a transaction's "inner instructions". For the most part, we measure program usage only by end-user usage, but in some cases, such as in the big “Program Stats” table, we do also count a transaction's inner instructions.
This reliance mostly on end-user usage stems primarily from computational feasibility, but there’s a philosophical reason too: This dashboard is focused on the “end user,” and the end user probably doesn’t care if they’re invoking a program that builds on top of another program. Intelligent people can probably disagree here :)
\n
This dashboard is made available as-is and neither the creator or publisher of this dashboard shall have any responsibility or liability for your use of, including any reliance on, the dashboard, any analytics, and any underlying data.
\n