Indexed SolanaBlockchain Data

Solana is a Layer 1 that opened its mainnet beta in March 2020. Blocks come from a proof-of-stake validator set running Tower BFT, with Proof of History supplying a verifiable clock so the leader schedule can be fixed in advance: a slot is 400 milliseconds by design, and 432,000 slots make an epoch of about two days. Execution happens in the Sealevel runtime, which runs transactions in parallel whenever they declare non-overlapping account writes, and programs are compiled to SBF bytecode rather than EVM bytecode. The account model is the part that surprises people. Programs hold no state of their own, data lives in separate accounts they own, and a wallet’s position in a token sits in one token account per mint instead of a field on the wallet itself. The native asset is SOL, divisible into a billion lamports, with each base fee split between a burn and the block leader. Since 2023 the ledger has also carried compressed state, where large collections are committed as a Merkle root and the individual records exist only in transaction history.

SonarX indexes Solana at the level the ledger records it: slots and blocks, transactions with their instructions and inner instructions, account writes, program invocations, and token mints, transfers and balances. Those records are normalized into the same model SonarX uses on every network it covers, so a Solana query and a Sui query take the same shape and can be joined without a translation layer between them.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery keeps the same dataset current to chain tip. Point-in-time balance tables, the real-time balances API and the batch wallets, tokens and balances API are all available for Solana. Kafka streaming carries the same records as a live topic today.

Solana has no event logs. Nothing plays the part an ERC-20 transfer event plays elsewhere, so a transfer view is assembled by decoding instructions and inner instructions per program and by differencing the pre- and post-transaction token balances stored beside them. Versioned transactions reference accounts through lookup tables, so the account list is not fully present in the message. Slot numbers are not block numbers either: leaders skip slots, and a restart after a halt resumes from a snapshot, so absences in the sequence are expected. Compressed collections have no account to read at all, and their current state is only recoverable from history.

NFT market analysis is the loudest request here: listings, sales and royalty payments are program instructions rather than logs, so a marketplace’s history only reconstructs when that program’s instruction layout is decoded correctly, compressed collections included. Market-structure research is next, where swap-level history across several AMM programs has to land in one table instead of one per venue. Third is token distribution work, tracing an issuance from its mint authority through token accounts to the holders who kept it, which on Solana means following accounts rather than one contract’s internal ledger. Underneath all three sits the same requirement: program decoding that keeps up as the programs themselves change, since a marketplace or an AMM that ships a new version leaves its old instruction layout in the history. Token analytics and cross-chain flow studies read the same records, often beside Monad when teams are comparing execution models.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Solana history and the balance APIs are available now, so a first delivery is provisioning rather than engineering. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.