Indexed HederaBlockchain Data
Hedera produces no blocks: transactions are gossiped, ordered by virtual voting into a hashgraph and stamped with a consensus timestamp, on a public ledger governed by a council of named enterprises.
How to query Hedera data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Hedera 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 Hedera 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 Hedera 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
Curated Datasets
Available todayPurpose-built tables
Protocol-level Hedera datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- Staking
Used for:
- Position-level Hedera 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 Hedera share with a modelled slice
Realtime API
Enabled on requestREST over the indexed dataset
Query indexed Hedera 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 Hedera data behind their own API layer
Hedera data: frequently asked questions
What is Hedera?
Hedera’s mainnet has been open since 2019, and it is not a blockchain in the ordinary sense: there are no blocks. Transactions are gossiped between the network’s operators, ordered by virtual voting over the resulting graph, and stamped with a consensus timestamp, which produces asynchronous Byzantine fault tolerance and a total order without a chain of blocks. HBAR is the native token and pays fees. Accounts are numbered rather than hashed, identified as 0.0 followed by a number, and an account may also carry an EVM address alias for use by the smart-contract service on Hedera EVM. Tokens are issued through the Hedera Token Service as protocol objects with their own supply and freeze controls, so moving one is a ledger operation rather than a contract call. The network is governed by a council of named enterprises, and in 2024 its code moved to the Linux Foundation as the Hiero project.
Hedera data on SonarX
SonarX indexes the ledger’s records: transactions and their receipts, transfer lists, HBAR and Hedera Token Service balances, account and token lifecycle operations, and the consensus timestamps that order all of it. Those records land in the normalized model SonarX uses on every network it covers.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request.
How SonarX indexes Hedera
There is no block to key on, and that changes everything downstream. Ordering is by consensus timestamp at nanosecond precision, so the axis of this history is time, and a block number in a query is a grouping derived from the record stream rather than something the network produced. Token operations are protocol-level: one transaction carries a list of transfers that debits and credits several accounts at once, so a model with one sender and one recipient loses most of what a payment run did. The two datasets advance on one consensus timestamp sequence, so they are joined on time rather than on a block number.
What teams build with Hedera data
Token accounting is the first workload, and it is unusual here because a token’s supply, its freeze and its treasury are ledger state rather than contract state, so the audit trail is a series of typed operations. Token analytics is the solution area that work belongs to. Payment reconciliation is the second, matching a run of atomic multi-party transfers against what an institution’s own books recorded. Audit-trail reconstruction is the third, and the nanosecond timestamps are the point: two records that share a second are still strictly ordered. Teams comparing ledgers where assets are protocol objects usually pull Algorand alongside this one.
Getting Hedera 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. Hedera history is available now as a share or a file delivery, and streaming is provisioned on request. 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 Hedera data API?
APIs over indexed Hedera 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 Hedera 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 Hedera coverage go?
The historical data-share and file delivery cover the ledger from its 2019 mainnet forward, and are available today. Because ordering is by consensus timestamp, depth here is a date range rather than a block range, and that is how the share is scoped. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.
Are Hedera and Hedera EVM the same network?
Yes, and Hedera EVM is one service inside it. This page covers the native ledger: hashgraph consensus, HBAR transfers, and tokens issued through the Hedera Token Service without contract code. The smart-contract service, covered on its own page, executes Ethereum bytecode in the same transactions and under the same consensus. They produce different records, so SonarX indexes them as two datasets joined on consensus timestamp.
Is Hedera EVM-compatible?
Through its smart-contract service, yes: that service executes Ethereum bytecode and charges gas in HBAR. The native ledger is not an EVM chain, and most activity never touches one, because transfers and token operations are protocol services rather than contract calls. Coverage tables file Hedera under a non-EVM heading for that reason, and the EVM side has its own page and its own dataset.
