Solana

A Solana transaction is a list of instructions run in order, and it has to name up front every account it will touch. The tables follow that shape. blocks summarizes each slot, which is Solana’s word for a block. transactions holds one row per transaction. instructions breaks each transaction into its individual instructions, one per row. account_activity shows what each account held before and after. rewards holds the payouts to validators and stakers. Two Solana words show up throughout. A program is what other chains call a smart contract. An account is a slot of storage on the chain, and everything is one: a wallet, a token balance, a program’s own code. Solana transactions have to name up front every account they will touch. Amounts below are in lamports, the smallest unit of SOL: one SOL is a billion lamports. Every table is split by day on block_timestamp. Filter on that column in every query: with a filter the query reads only the days you asked for, without one it reads the whole table.

Tables

Table	Since	Description
`blocks`	2020-10	One row per slot, with transaction counts and fee totals.
`transactions`	2020-10	One row per transaction, with its fee and signatures.
`instructions`	2020-10	One row per executed instruction, inner instructions included.
`account_activity`	2020-10	One row per account a transaction touched, with balances before and after.
`rewards`	2020-10	One row per reward credited to an account in a block.
`failed_transactions`	2025-01	Transactions that failed, in the same shape as `transactions`.
`failed_instructions`	2025-01	Instructions that failed, in the same shape as `instructions`.

instructions and account_activity are among the largest tables we publish anywhere, so keep the block_timestamp range narrow and filter on executing_account or account_key as early in the query as you can.

Columns

blocks
transactions
instructions
account_activity
rewards

A slot is Solana’s block: one batch of transactions added to the chain. Vote transactions are validators keeping the network in agreement rather than users doing anything, so the counts and fee totals here are split into vote and non-vote. blocks contains one row per slot.

Column	Type	Description
`block_slot`	`INT64`	The slot number.
`block_hash`	`STRING`	The hash of the block.
`block_height`	`INT64`	The block height.
`block_timestamp`	`TIMESTAMP`	The time the block was produced. Partition column.
`parent_slot`	`INT64`	The slot of the parent block.
`previous_block_hash`	`STRING`	The hash of the parent block.
`total_transaction_count`	`INT64`	The number of transactions in the block.
`successful_transaction_count`	`INT64`	The number of successful transactions.
`failed_transaction_count`	`INT64`	The number of failed transactions.
`vote_transaction_count`	`INT64`	The number of vote transactions.
`non_vote_transaction_count`	`INT64`	The number of non-vote transactions.
`successful_vote_transaction_count`	`INT64`	The number of successful vote transactions.
`successful_non_vote_transaction_count`	`INT64`	The number of successful non-vote transactions.
`failed_vote_transaction_count`	`INT64`	The number of failed vote transactions.
`failed_non_vote_transaction_count`	`INT64`	The number of failed non-vote transactions.
`total_fee`	`INT64`	The total fees paid in the block, in lamports.
`successful_vote_transactions_fee`	`INT64`	The fees paid by successful vote transactions, in lamports.
`successful_non_vote_transactions_fee`	`INT64`	The fees paid by successful non-vote transactions, in lamports.
`failed_vote_transactions_fee`	`INT64`	The fees paid by failed vote transactions, in lamports.
`failed_non_vote_transactions_fee`	`INT64`	The fees paid by failed non-vote transactions, in lamports.
`successful_non_vote_transactions_priority_fee`	`INT64`	The priority fees paid by successful non-vote transactions, in lamports.
`failed_non_vote_transactions_priority_fee`	`INT64`	The priority fees paid by failed non-vote transactions, in lamports.

A transaction is one signed bundle of instructions, naming every account it will touch. transactions contains one row per transaction.

Column	Type	Description
`block_timestamp`	`TIMESTAMP`	The time of the block containing the transaction. Partition column.
`block_slot`	`INT64`	The slot of the containing block.
`transaction_index`	`INT64`	The position of the transaction within the block.
`transaction_id`	`STRING`	The first signature of the transaction, the identifier used everywhere else.
`account_keys`	`ARRAY<STRING>`	The accounts referenced by the transaction.
`executing_accounts`	`ARRAY<STRING>`	The programs invoked by the transaction.
`fee`	`INT64`	The fee paid, in lamports.
`signatures`	`ARRAY<STRING>`	All signatures on the transaction.
`return_data`	`STRUCT`	The program return data: program id and data.
`compute_units_consumed`	`INT64`	The compute units consumed.
`required_signatures_count`	`INT64`	The number of required signatures.
`readonly_signed_accounts_count`	`INT64`	The number of read-only signed accounts.
`readonly_unsigned_accounts_count`	`INT64`	The number of read-only unsigned accounts.
`log_messages`	`ARRAY<STRING>`	The program log messages.
`signer`	`STRING`	The fee-paying signer.
`version`	`STRING`	The transaction version.
`logs_truncated`	`BOOL`	Whether the log output was truncated by the node.
`success`	`BOOL`	Whether the transaction succeeded.
`error`	`STRING`	The error raised, when the transaction failed.

An instruction is one call into a program, the unit of work inside a transaction. A transaction runs its instructions in order, and a program can make further calls of its own: those are the inner instructions. instructions contains one row per executed instruction, inner instructions included.

Column	Type	Description
`block_slot`	`INT64`	The slot of the containing block.
`block_timestamp`	`TIMESTAMP`	The time of the containing block. Partition column.
`transaction_id`	`STRING`	The identifier of the containing transaction.
`transaction_index`	`INT64`	The position of the transaction within the block.
`transaction_signer`	`STRING`	The fee-paying signer of the transaction.
`instruction_index`	`INT64`	The position of the instruction within the transaction.
`outer_instruction_index`	`INT64`	The index of the enclosing top-level instruction, for inner instructions.
`executing_account`	`STRING`	The program executing the instruction.
`outer_executing_account`	`STRING`	The program executing the enclosing instruction.
`account_arguments`	`ARRAY<STRING>`	The accounts passed to the instruction.
`instruction_data`	`STRING`	The instruction payload.
`stack_height`	`INT64`	The invocation depth of the instruction.
`surrogate_key`	`STRING`	A unique identifier we build for the row, because the chain gives an instruction none of its own.

account_activity contains one row per account a transaction touched, showing what it held before the transaction and after it: SOL for every account, plus the token amount for accounts that hold a token. This is where you see who gained and who lost.

Column	Type	Description
`block_timestamp`	`TIMESTAMP`	The time of the containing block. Partition column.
`block_slot`	`INT64`	The slot of the containing block.
`transaction_index`	`INT64`	The position of the transaction within the block.
`transaction_id`	`STRING`	The identifier of the containing transaction.
`signer`	`STRING`	The fee-paying signer of the transaction.
`account_key`	`STRING`	The account touched.
`account_index`	`INT64`	The position of the account in the transaction’s account list.
`pre_balance`	`INT64`	The native balance before the transaction, in lamports.
`post_balance`	`INT64`	The native balance after the transaction, in lamports.
`pre_token_amount`	`FLOAT64`	The token balance before the transaction, for token accounts.
`pre_token_mint`	`STRING`	The mint of the token balance before the transaction.
`pre_token_owner`	`STRING`	The owner of the token account before the transaction.
`pre_token_program`	`STRING`	The token program of the account before the transaction.
`post_token_amount`	`FLOAT64`	The token balance after the transaction, for token accounts.
`post_token_mint`	`STRING`	The mint of the token balance after the transaction.
`post_token_owner`	`STRING`	The owner of the token account after the transaction.
`post_token_program`	`STRING`	The token program of the account after the transaction.

A reward is a payout the chain credits to an account: for staking, for voting, or as a rent refund. rewards contains one row per reward credited in a block.

Column	Type	Description
`block_slot`	`INT64`	The slot of the block crediting the reward.
`block_hash`	`STRING`	The hash of the block.
`block_timestamp`	`TIMESTAMP`	The time of the block. Partition column.
`pubkey`	`STRING`	The account credited.
`lamports`	`NUMERIC`	The reward amount, in lamports.
`commission`	`NUMERIC`	The validator commission applied.
`post_balance`	`NUMERIC`	The account balance after the reward, in lamports.
`reward_type`	`STRING`	The reward type, such as fee, rent, staking or voting.
`commission_bps`	`INT64`	The validator commission in basis points.

Sample queries

Every table splits by day on block_timestamp. Bound that column in every query; without a bound the query reads the whole table.

Daily fees
Busiest programs
Priced tokens
Tokenized assets
App activity

Sum daily non-vote transactions and total fees over one week.

select
    timestamp_trunc(block_timestamp, day) as day,
    sum(non_vote_transaction_count) as non_vote_transactions,
    sum(total_fee) as total_fee_lamports
from `solana.blocks`
where block_timestamp >= timestamp('2026-08-16')
  and block_timestamp < timestamp('2026-08-23')
group by day
order by day

Rank programs by executed instructions on one day.

select
    executing_account as program,
    count(*) as instructions
from `solana.instructions`
where block_timestamp >= timestamp('2026-08-20')
  and block_timestamp < timestamp('2026-08-21')
group by program
order by instructions desc
limit 20

Count the Solana tokens that carry a daily USD price, day by day.

select
    date(timestamp) as day,
    count(distinct token_id) as priced_tokens
from `metrics.tokens_prices_daily`
where timestamp >= timestamp('2026-08-16')
  and timestamp < timestamp('2026-08-23')
  and chain_id = 'solana'
group by day
order by day

Rank the tokenized assets deployed on Solana by circulating market cap.

select
    symbol,
    asset_type,
    market_cap_circulating_total,
    transfer_volume_total,
    holders_native
from `metrics.asset_tokens_daily`
where timestamp >= timestamp('2026-08-22')
  and timestamp < timestamp('2026-08-23')
  and chain_id = 'solana'
order by market_cap_circulating_total desc
limit 20

Rank the apps active on Solana by fees over one week.

select
    apps.name,
    sum(daily.fees) as fees,
    sum(daily.revenue) as revenue
from `metrics.apps_chains_daily` as daily
join `dimensions.apps` as apps
    using (app_id)
where daily.timestamp >= timestamp('2026-08-16')
  and daily.timestamp < timestamp('2026-08-23')
  and daily.chain_id = 'solana'
group by apps.name
order by fees desc

Notes

Transactions that failed are kept apart, in failed_transactions and failed_instructions. Those two carry the same columns as transactions and instructions, and they start on 2025-01-01. Above the raw tables sits the rest of the catalog. Tokens covers the token list and the daily price table. Stablecoins and Tokenized assets cover the tokenized assets issued on Solana. Bridges covers the transfers that leave and arrive on it, and Projects covers app and project activity per chain.

Overview

Core entities

Market verticals

Chain verticals

Tables

Columns

Sample queries

Notes

​Tables

​Columns

​Sample queries

​Notes

Tables

Columns

Sample queries

Notes