Raw

The solana dataset holds the standardized Solana tables. 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. Transactions and instructions that failed sit apart, in failed_transactions and failed_instructions, in the same shape as the two tables they mirror. 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. Amounts below are in lamports, the smallest unit of SOL: one SOL is a billion lamports.

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.

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. instructions clusters on executing_account, account_activity on account_key and transaction_id, and rewards on pubkey, so naming one of those beside the date bound is what keeps a read on the two biggest tables small.

Daily fees
One program's day
One account's balance moves
Daily rewards by type

Sum daily non-vote transactions and total fees over one week. Vote transactions are validators keeping the network in agreement, so non_vote_transaction_count is the figure closest to user activity; total_fee is in lamports and covers both kinds.

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

Measure how much work one program did on one day. The program is Orca’s Whirlpools, and executing_account is both the program that ran the instruction and the cluster key, so this reads a slice of the day rather than all of it. Inner instructions are counted here too, which is why the instruction count runs ahead of the transaction count.

select
    count(*) as instructions,
    count(distinct transaction_id) as transactions,
    count(distinct transaction_signer) as signers
from `solana.instructions`
where block_timestamp >= timestamp('2026-08-20')
  and block_timestamp < timestamp('2026-08-21')
  and executing_account = 'whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc'

Follow the SOL moving in and out of one account across a day. account_key is the cluster key, so naming the account holds the read down. The balances are lamports before and after each transaction, and their difference is what that transaction did to the account.

select
    block_timestamp,
    transaction_id,
    (post_balance - pre_balance) / 1e9 as sol_change
from `solana.account_activity`
where block_timestamp >= timestamp('2026-08-20')
  and block_timestamp < timestamp('2026-08-21')
  and account_key = 'CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C'
order by block_timestamp
limit 100

Split a week of rewards by what the chain paid them for. reward_type separates staking from voting, fees and rent refunds, and lamports divided by a billion gives SOL.

select
    timestamp_trunc(block_timestamp, day) as day,
    reward_type,
    count(*) as rewards,
    sum(lamports) / 1e9 as sol
from `solana.rewards`
where block_timestamp >= timestamp('2026-08-16')
  and block_timestamp < timestamp('2026-08-23')
group by day, reward_type
order by day, reward_type

Overview

Popular datasets

Market verticals

Chain ecosystems

Core entities

Tables

Sample queries

​Tables

​Sample queries

Tables

Sample queries