How To Analyze Any Solana Program In Five Minutes

Get started with analyzing any Solana program (on Dune.com)

Jun 26, 2023

Solana programs are super complex to analyze - requiring you to understand a complex instruction structure, multiple program types, and some rust. We’ve made it easier to work with using decoded data in SQL tables, and now even easier using a quickstart dashboard.

You’ll be able to:

Understand the structure and usage of instructions
See the historical trend of activity in transactions and addresses
Find which programs are invoking or being invoked by the program

All of this will make it much faster for you to find the right tables to query on Dune and start your own analysis.

You can get started with the dashboard here.

Finding your program

Let’s walk through using this dashboard for the Jupiter v4 program, which is a dex aggregator (it routes your swap through multiple exchanges to get you the best trading price).

I found this program by searching “jupiter” in this first query below, where you can find all the other six versions as well.

This result set shows programs that have been decoded already in Dune - you can submit any program id but they need to have their Anchor IDL verified or have their lib.rs/interface open sourced somewhere online.

If you don’t know the program name but have an example transaction, you can search the transaction id and block slot in the other finder to check for the program id (and also see the decoded instruction table).

Once you’ve found the program id, you can enter it at the top of the dashboard and select a day range (anything more than 60 will likely time out due to the size of Solana tables).

Understanding Instructions and Activity

After the results load, you’ll find all the instructions and the total times they’ve been called. The “Discriminator” is the leading set of bytes that identifies the function call, and the inputs and accounts are parameters that go into the call logic. You can find all of those parameters as columns in the Dune decoded table.

So here, the top instruction called is the “route” instruction - called 156 million times in the last 60 days.

You can start working with any table here by querying *SELECT * FROM jupiter_v4_solana.jupiter_call_route* in the query editor.

For activity, you can see the weekly number of calls and transactions over the time period. Jupiter isn’t super interesting here since there is only one instruction really called, but it is great to check for liquidation spikes and such in lending protocols.

We also want to understand how sticky users are, so we check out new versus returning wallets over time (as well as the top users). We can see that most wallets are old, with the exception of a spike in May 22nd - generally seeing 15-20k active wallets a week on Jupiter v4.

If you look at the top account, they’ve actually been inactive for more than a month now - which is curious. I wonder if they were a bot that stopped trading for some reason.

Understanding Program Invokers and Invokees

On Solana, you can call a program to invoke another program in a “Cross Program Invocation (CPI)”. That’s why you’ve seen us reference outer and inner accounts in instructions tables - although that doesn’t always indicate the invocation depth. Let’s say I call Jupiter, which routes and calls Whirlpool to swap, which then calls spl token to make the transfers. The Jupiter call is “outer” or top level with a depth of 1, the Whirlpool call is “inner” instruction/level with depth of 2, and the spl token is the same “inner” instruction/level with depth of 3. I’m getting the depth using the logs, since you can’t figure it out by just looking at the instructions data column.

Let’s first look at what programs are calling Jupiter. I know these are only programs because I’m checking Jupiter sits at depth of 2, and wallets can only make the first call to depth 1.

The top program caller here is the TWAMM protocol, which operates as an order book so you can schedule to fill at certain prices over time. The other programs are not verified - so we can’t dive deeper into them.

Let’s look at what programs are called by the Jupiter v4 program next:

Here we can see Whirlpool at the top with Raydium in following positions - these are the top routing destinations in this case for Jupiter. The other programs are other DEXs, but aren’t open sourced in any capacity. Shame!

Continuing your analysis

You should look at all this data and start asking questions - should I dive deeper on a specific program invocation connection? Or a set of users? or a specific time frame?

And come back to this dashboard as reference when you’re done, as some weird spike or behavior you’ve seen in the data might be explained by a bunch of new users or a new CPI source/destination.

Make sure you subscribe and also follow me on Twitter for more web3 data guides and updates - and feel free to reach out anytime with questions or suggestions on this dashboard :)

Web3 Data Degens