Indexed AvalancheBlockchain Data
Avalanche is a Layer 1 that runs three chains at once, and the C-Chain is its EVM: contracts and accounts ordered under Snowman consensus, where an accepted block is final.
How to query Avalanche data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Avalanche blockchain data with plain SQL from a live database inside your own Snowflake account, populated with the indexed chain dataset. There is no pipeline to build and no second copy to store. The same dataset ships as file dumps to your own object storage for lakes and warehouses that are not Snowflake.
- Full history as a Snowflake data-share
- File dumps to S3 or your own object storage
- Real-time delivery, current to chain tip — on request
Used for:
- Analytics teams already on Snowflake that want Avalanche data beside their existing tables
- Fund accounting and treasury reporting that reconciles against a fixed history
- Cross-chain questions answered in one SQL statement instead of one query per chain
- Loading Avalanche history into BigQuery, Databricks, Redshift or a Spark lake
- Replacing a self-hosted indexer and the engineering time that keeps it running
- Serving one governed dataset to several desks without copying it per team
Kafka Streaming
Available todayEvent stream
Consume Avalanche activity as a continuous stream of normalized records, produced as the chain is indexed instead of polled for.
Used for:
- Trading and execution systems that act on Avalanche activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Avalanche wallet or protocol activity
- Feeding a stream processor that already reads from Kafka
- Keeping an internal store hot without waiting for a batch window
- Event-driven services that would otherwise poll on a timer
Curated Datasets
Available todayPurpose-built tables
Protocol-level Avalanche datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- DeFi
- Tokens and payments
Used for:
- Position-level Avalanche lending, swap and liquidity analysis
- Reward, delegation and validator reporting without rebuilding the model
- Token distribution, holder and payment-flow reporting
- Risk and exposure work that needs protocol state, not raw logs
- Skipping the decoding layer an in-house team would have to maintain
- Extending an existing Avalanche share with a modelled slice
Balances
Available todayTables and REST
Read what a Avalanche address held, either as it stands now or exactly as it stood at a past block or timestamp.
- Point-in-time balance tables, as at any block or timestamp
- Real-time balances API for latest and historical balances — on request
- Batch API for wallets, tokens and balances in bulk — on request
Used for:
- Reconstructing Avalanche portfolios and NAV as at a reporting date
- Audit and reconciliation work that has to be repeatable months later
- Wallet and portfolio products that render Avalanche balances on page load
- Compliance checks that read one Avalanche address at one block height
- Refreshing holdings for a whole book of accounts on a schedule
- Tax and cost-basis workflows that need holdings at each event
Realtime API
Available todayREST over the indexed dataset
Query indexed Avalanche records over REST, reading the same dataset the share reads, with no warehouse in the path.
Used for:
- Applications that need one answer rather than a table scan
- Customer-facing screens where query latency is visible to a user
- Services that have no data warehouse and do not want to run one
- Prototyping against production data before committing to a share
- Backend checks that run per request instead of per batch
- Teams that want indexed Avalanche data behind their own API layer
Avalanche data: frequently asked questions
What is Avalanche?
Avalanche has produced blocks since its mainnet launch in 2020, and it is not one chain but three running side by side. The C-Chain is the EVM chain and the subject of this page: Solidity contracts, twenty-byte addresses, receipts and logs, ordered under Snowman consensus. The X-Chain handles asset exchange, and the P-Chain records validators, staking and the networks built on top of Avalanche, both using bech32 addresses rather than hex. Snowman reaches agreement by repeated randomized sampling among validators, which gives Avalanche a property that matters more to a data pipeline than its speed does: an accepted block is final, so there are no reorgs to unwind. AVAX is the native token, capped at 720 million, and transaction fees on the C-Chain are burned rather than paid to a proposer.
Avalanche data on SonarX
SonarX indexes the Avalanche C-Chain end to end: blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces including internal value transfers, and token transfers and balances. The same normalized model is used on every chain SonarX covers, so an Avalanche query and an Ethereum query take the same shape and join without a translation layer.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Point-in-time balance tables are available for Avalanche, and the rest can be enabled on request. Kafka streaming carries the same records as a live topic today.
How SonarX indexes Avalanche
The three-chain design is what makes this network its own indexing problem. AVAX can sit on any of the three chains, and moving it between them is an export on one and an import on the other rather than a transfer with a counterparty, so a balance history built from C-Chain records alone will show value vanishing at the edges. SonarX resolves those atomic pairs so the two sides reconcile. Finality works in SonarX’s favor here: because accepted blocks are never reorganized, the pipeline appends rather than revises, which is the opposite of the correction model an Ethereum-style chain needs.
What teams build with Avalanche data
Portfolio reconstruction is the recurring request: a wallet’s holdings as at a block or a date, reconciled against transfers rather than inferred from a current snapshot, which is what point-in-time balances exist for. Supply accounting is the second and is unusual here, because fees are burned, so issuance and burn have to be netted from chain records instead of read from a published figure. Position-level DeFi analytics is the third, built from decoded logs and traces together. Bridge reconciliation runs underneath all of it, since assets arrive from other networks as wrapped representations that have to be tied back to their origin before a position is counted once rather than twice. Teams benchmarking high-volume EVM networks usually pull BSC into the same warehouse and compare fee behavior across both.
Getting Avalanche data from SonarX
Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Avalanche history is 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.
Is there an Avalanche data API?
Yes. A real-time API over indexed Avalanche data is available today, reading the same indexed dataset as the Snowflake share. The balances and batch APIs are enabled on request, so tell us the lookup pattern you need and we will confirm what is possible.
How do I get Avalanche data into Snowflake?
SonarX provisions a data-share into your own Snowflake account. The share appears as a database you query with SQL, so there is no pipeline to build and no second copy to store, and it stays current as SonarX advances the indexing pipeline.
How far back does Avalanche coverage go?
The historical data-share and file delivery cover the C-Chain's recorded history from the 2020 mainnet launch forward, and are available today. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.
Is this the C-Chain, the X-Chain or the P-Chain?
The C-Chain, which is the EVM chain of the Avalanche primary network and where contracts, tokens and DeFi activity live. The P-Chain, which records validators, staking and the networks built on Avalanche, is a separate dataset with its own page. The X-Chain handles asset exchange under a different transaction model again.
How are AVAX movements between Avalanche chains handled?
As matched pairs rather than as transfers. Moving AVAX off the C-Chain produces an export on one chain and a corresponding import on the other, so the value leaves without a counterparty address ever appearing in EVM data. SonarX indexes both sides, which is what a complete AVAX flow for an address requires.
Does Avalanche coverage include subnet activity?
No. Networks built on Avalanche run their own chains with their own validator sets, so each one produces its own history rather than appearing inside C-Chain blocks. Tell us which of them your analysis needs and we will confirm what is covered and what would have to be scoped.
