Indexed HarmonyBlockchain Data
Harmony shards its state and its validator set, drawing each shard's committee by verifiable random function, and commits a block in one FBFT round on a proof-of-stake Layer 1.
How to query Harmony data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Harmony 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 Harmony 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 Harmony 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 Harmony 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 Harmony activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Harmony 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 Harmony datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- Staking
Used for:
- Position-level Harmony 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 Harmony share with a modelled slice
Balances
Enabled on requestTables and REST
Read what a Harmony 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 Harmony 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 Harmony balances on page load
- Compliance checks that read one Harmony 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 Harmony 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 Harmony data behind their own API layer
Harmony data: frequently asked questions
What is Harmony?
Harmony’s mainnet has produced blocks since June 2019. Consensus is FBFT, a fast Byzantine agreement protocol that aggregates validator signatures with BLS so a large committee can commit in one round, and blocks arrive about every two seconds with finality at the block itself rather than after a wait. Rewards are allocated under Effective Proof of Stake, which caps what a single validator earns and pushes delegation outward. State is sharded: committees are drawn into shards by a verifiable random function, and an epoch of 32,768 blocks, roughly eighteen hours, decides when those committees change. ONE is the native token and pays gas. Execution is EVM-compatible, so Solidity deploys unchanged, but identity is local: an account has a bech32 form beginning one1 and a twenty-byte 0x form, and both are the same keys. Token standards come from Ethereum, the address book does not.
Harmony data on SonarX
SonarX indexes Harmony blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, and token transfers and balances, across shard chains rather than from a single sequence. 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. Balance tables and the balance APIs can be enabled for Harmony on request. Kafka streaming can be enabled for Harmony on request.
How SonarX indexes Harmony
A shard is a chain of its own, so this history is a union rather than a sequence: each shard advances on its own height, and crosslinks record which validators signed where. A cross-shard transfer lands twice, debited on the source and credited on the destination, and neither record alone is the transfer, so the pair is matched before a balance is derived. Epoch boundaries every 32,768 blocks reshuffle committees, which makes validator attribution epoch-scoped rather than continuous. Every account also carries a one1 form and a 0x form, and both resolve to one account first.
What teams build with Harmony data
Validator and reward accounting is the recurring workload, because Effective Proof of Stake pays out per epoch against a cap, so an accrual has to be derived from committee membership and epoch boundaries rather than read off a transfer log. Staking analytics covers that work across chains. Cross-shard flow analysis is the second, following value between shard chains so a movement is counted once. Address-level research is the third, and it is where the two encodings bite, since a study that treats one1 and 0x forms as separate holders inflates its population. Teams comparing sharded designs usually pull NEAR into the same warehouse.
Getting Harmony 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. Harmony 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 a Harmony data API?
Real-time and batch APIs over indexed Harmony 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 Harmony 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 Harmony coverage go?
The historical data-share and file delivery cover the chain from its 2019 mainnet forward, and are available today. Because state is sharded, depth is also a question of which shard chains a workflow reads, and the share is scoped against both. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.
Is Harmony EVM-compatible?
Yes. Harmony runs an EVM, so Solidity contracts deploy unchanged and ERC-20 and ERC-721 activity decodes against contract ABIs. Coverage tables that file Harmony under a non-EVM heading are describing how SonarX models the dataset, not the chain. The local difference is the address book rather than the virtual machine: one account is written both as one1 in bech32 and as twenty bytes in hex.
How does sharding change Harmony data?
Each shard is a chain with its own height, so a full history is the union of those chains plus the crosslinks that record which validators signed where. A cross-shard transfer appears twice, debited on the source shard and credited on the destination, and neither half is the whole transfer. SonarX matches those pairs and keys records to their shard, so a balance or a flow does not depend on which shard you happened to query.
