Indexed HyperEVMBlockchain Data
HyperEVM is the EVM execution layer on the Hyperliquid Layer 1, sharing HyperBFT consensus and block production with the order-book side and reaching it through precompiles and a system contract.
How to query HyperEVM data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query HyperEVM 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 HyperEVM 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 HyperEVM 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 HyperEVM 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 HyperEVM activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on HyperEVM 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 HyperEVM 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 HyperEVM 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 HyperEVM balances on page load
- Compliance checks that read one HyperEVM 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 HyperEVM 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 HyperEVM data behind their own API layer
HyperEVM data: frequently asked questions
What is HyperEVM?
HyperEVM is the EVM execution environment on the Hyperliquid Layer 1, and it is not a chain of its own. It shares HyperBFT consensus, the validator set and block production with HyperCore, the state machine that runs the exchange and that Hyperliquid covers. Contracts opened to general deployment on 18 February 2025. Gas is paid in HYPE, the network’s native asset, and above that layer the environment is ordinary: Solidity bytecode, twenty-byte addresses, ERC-20 and ERC-721 contracts, and event logs that decode against their ABIs. Two things are not ordinary. Block production alternates between frequent small blocks with a modest gas limit and less frequent large blocks that admit heavier transactions, so a deployment targets one or the other. And the EVM is not sealed off from the exchange: contracts read HyperCore state through precompiles and send actions back through a system contract, so a contract call can change a position on the order-book side. Spot assets can also be linked to ERC-20 contracts, which gives a single token a representation on both surfaces.
HyperEVM data on SonarX
SonarX indexes the EVM side of the network in the shapes an EVM team expects: blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces with internal value transfers, and token transfers and balances. Those records are normalized into the model SonarX uses across every network it covers, so HyperEVM activity joins to activity elsewhere without a translation step.
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 HyperEVM on request. Kafka streaming carries the same records as a live topic today.
How SonarX indexes HyperEVM
The hard part is that this EVM does not stand alone. Its blocks are the network’s blocks, so the EVM dataset and the HyperCore dataset advance on one height and have to be indexed in step or cross-surface analysis silently mismatches. The two block sizes give the chain a bimodal profile, where gas limits and transaction weight vary by block type rather than by demand, so per-block aggregates need reading with that in mind. Linked spot assets are the other trap: the same token can appear as an ERC-20 here and as an asset on the exchange side, and supply work that counts both without reconciling them double counts.
What teams build with HyperEVM data
Work on this dataset tends to be about the boundary rather than the contracts alone. Protocol analytics is the direct case: lending, vaults and structured products deployed beside a venue that holds real order flow, studied through decoded logs and traces. Capital-routing analysis is the recurring one, following funds from EVM contracts into the exchange side and back to see where positions are actually financed. Contract-level risk work is the third, tracing which deployments touch HyperCore through the system contract and what that exposure looks like over time. Token accounting turns up as a fourth, because a linked asset has a balance on each surface and a treasury report that adds them without reconciling states the same holding twice. DeFi analytics covers the contract side of this across chains, and teams comparing dual-environment designs usually pull Sei EVM alongside it.
Getting HyperEVM data from SonarX
Tell us which surface you need, the EVM side or HyperCore or both, how far back, and where the data should land. 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 HyperEVM data API?
Real-time and batch APIs over indexed HyperEVM 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 HyperEVM 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 HyperEVM coverage go?
The historical data-share and file delivery cover the EVM side's recorded history and are available today. HyperEVM is the younger of the two execution surfaces on this network, so depth is confirmed per surface when the share is scoped. Tell us whether your workflow needs the EVM side, the HyperCore side, or both, and the backfill is cut accordingly.
Do Hyperliquid and HyperEVM share one dataset?
No. They share a chain, a consensus and a block height, but they produce different records, so SonarX indexes them as two datasets with a common height to join on. That join is the point: a position opened through a contract on the EVM side and settled in the order book is one story told in two sets of records.
What is the difference between Hyperliquid and HyperEVM?
They are two execution environments on one network. HyperCore, covered on the Hyperliquid page, is the state machine that runs the order book and the perpetuals venue. HyperEVM, covered here, is the EVM environment on the same chain under the same HyperBFT consensus, where deployed contracts live. They produce different kinds of records, so SonarX treats them as two datasets and gives each its own page.
Can HyperEVM contracts read the Hyperliquid order book?
Yes, and that changes how the data has to be read. Contracts query HyperCore state through precompiles and send actions to it through a system contract, so an EVM transaction can move a position on the exchange side. An event log on its own does not show that effect, which is why cross-surface analysis joins the two datasets on block height rather than reading logs alone.
How do I start with HyperEVM data?
Tell SonarX the delivery target, the history depth and the refresh cadence you need, and the share is scoped against that. There is no self-serve signup: every engagement is provisioned, so the first conversation is about scope rather than credentials.
