Indexed FlareBlockchain Data
Flare enshrines its oracles in the protocol, so the validators producing blocks on this EVM Layer 1 are the same parties supplying price feeds and attesting to outside facts.
How to query Flare data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Flare 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 Flare 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 Flare 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
Enabled on requestEvent stream
Consume Flare 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 Flare activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Flare 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
Balances
Enabled on requestTables and REST
Read what a Flare 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
- Batch API for wallets, tokens and balances in bulk
Used for:
- Reconstructing Flare 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 Flare balances on page load
- Compliance checks that read one Flare 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
Enabled on requestREST over the indexed dataset
Query indexed Flare 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 Flare data behind their own API layer
Flare data: frequently asked questions
What is Flare?
Flare is an EVM-compatible Layer 1, chain ID 14, that runs Snowman++ consensus inherited from Avalanche with proof of stake for sybil resistance and delegation built into the protocol. Blocks arrive about every 1.8 seconds and are final once accepted. What makes the chain unusual is what the protocol itself does: two data protocols are enshrined in it, the Flare Time Series Oracle for price feeds and the Flare Data Connector for attesting facts from outside the chain, and the validators that produce blocks are the same parties that supply those feeds. FLR is the native asset, divisible to eighteen decimals, and it pays for gas and carries delegated stake. Songbird is the canary network beside it, running on SGB.
Flare data on SonarX
SonarX indexes Flare blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, and token transfers and balances, in the normalized model used on every chain SonarX covers.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Balance tables and the balance APIs can be enabled for Flare on request. Kafka streaming can be enabled for Flare on request.
How SonarX indexes Flare
Most of what happens on this chain is the chain itself. Feed updates land with almost every block, anchor rounds close every 90 seconds, and provider selection, delegation and reward distribution all leave records, so protocol traffic sits in the same tables as user transactions and outnumbers them. An activity measure that counts transactions without separating the two describes the oracle, not the users. Epochs are the second wrinkle: rewards and provider performance are accounted per voting round rather than per block, so a correct reward series is grouped by epoch and then reconciled against the block-level records underneath it.
What teams build with Flare data
Oracle research is the workload specific to this chain: the history of what a feed said, when it said it, and which providers agreed is all onchain, which makes it a rare public record of how a decentralized price series behaved. Delegation and reward accounting is the second job, grouped by epoch rather than by block. Position-level DeFi analytics is the third, built from decoded events with internal transfers attached, and it depends on the feeds because collateral values here come from the protocol. Token-distribution work is a fourth: Flare’s first distribution went to XRP Ledger holders, so tracing it starts on another chain.
Getting Flare 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. Full history is available now as a share or a file delivery, and say if you need oracle rounds separated from user activity when the share is scoped. 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 a Flare data API?
Real-time and batch APIs over indexed Flare data are enabled on request: the same indexed dataset the Snowflake share reads, served over REST once provisioned. Tell us the lookup pattern you need.
How do I get Flare 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 Flare coverage go?
The historical data-share and file delivery cover Flare's recorded history and are available today, with depth confirmed when the share is scoped rather than asserted here. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.
How does oracle activity show up in Flare data?
As ordinary chain records produced by the protocol. Block-latency feeds update with each new block, roughly every 1.8 seconds, while anchor feeds settle once per 90-second voting epoch, and providers are selected by a stake-weighted random function. That means a large share of Flare's transactions are protocol submissions rather than user activity, and any usage metric has to separate the two before it means anything.
Is Songbird the same network as Flare?
No. Songbird is Flare's canary network, where protocol changes run before they reach the main chain, and its transactions cost SGB rather than FLR. It has its own blocks, its own validator set and its own history, so nothing on Songbird is part of Flare's dataset, and coverage for it is scoped separately.
