Indexed HyperliquidBlockchain Data
Hyperliquid is the Layer 1 built around a fully onchain order book, where perpetuals and spot markets run as chain state under sub-second HyperBFT consensus.
How to query Hyperliquid data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Hyperliquid 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
Used for:
- Analytics teams already on Snowflake that want Hyperliquid 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 Hyperliquid 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 Hyperliquid 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 Hyperliquid activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Hyperliquid 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 Hyperliquid datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- Perps (DeFi)
- Staking positions
Used for:
- Position-level Hyperliquid 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 Hyperliquid share with a modelled slice
Hyperliquid data: frequently asked questions
What is Hyperliquid?
Hyperliquid is a Layer 1 appchain that has been producing blocks since 2023, and it exists to run one application: the Hyperliquid exchange. Where a typical chain hosts a trading venue as a set of smart contracts, Hyperliquid implements the venue in the chain itself. Placing an order, cancelling it, matching it and paying funding are state transitions executed by the protocol, on a validator set running HyperBFT, a BFT consensus in the HotStuff family, with sub-second block times. That state machine is called HyperCore, and it is what this page covers. The native asset is HYPE. HyperCore has no EVM: contracts cannot be deployed to it. A paired EVM execution layer, HyperEVM, was added in February 2025 and shares the same consensus and the same block production, which makes Hyperliquid one of the few networks where two execution environments advance in lockstep. Spot markets run in the same state machine as perpetuals, under Hyperliquid’s own token standard rather than as deployed contracts, so listings and trades are protocol events too.
Hyperliquid data on SonarX
SonarX indexes Hyperliquid’s chain history and normalizes it into the same model used across every network SonarX covers, so Hyperliquid records can be joined to activity on other chains without a translation layer. Because the exchange is part of the protocol rather than a contract deployment, the interesting records are chain state rather than decoded logs, and they are indexed as such.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery keeps the same dataset current to chain tip. Hyperliquid has no token-balance surface to index: user state lives as positions inside the exchange state machine, so balance products do not apply here. Kafka streaming carries the same records as a live topic today.
How SonarX indexes Hyperliquid
Three things make this chain unlike an EVM L1. The exchange state has no event-log equivalent, so an indexer cannot subscribe to transfers and reconstruct the rest; it has to follow the protocol’s own state transitions. Blocks arrive faster than a second, which changes the economics of a streaming pipeline more than the total data volume does. And the network carries two execution environments on one consensus, so HyperCore and HyperEVM have to be indexed as separate datasets that nonetheless share a block height, or cross-surface analysis silently mismatches.
What teams build with Hyperliquid data
Hyperliquid requests come from research and risk teams more often than from application developers. Market-structure research on a fully onchain order book is the recurring one: funding and basis series, liquidation clustering, and maker and taker behavior studied across the venue rather than sampled through an API. Flow analysis is the second, following capital between HyperCore, HyperEVM and bridges to see where positions are actually funded from. Third is reconciliation, where a desk with exposure on the venue needs its own records to agree with the chain’s. None of that work needs an API: it is range queries over a long history, which is what a warehouse share is for.
Teams comparing venues usually pull Injective alongside it, and DeFi analytics work spans both surfaces of the network.
Getting Hyperliquid data from SonarX
Tell us which surface you need, HyperCore or HyperEVM 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 Hyperliquid data API?
No. Hyperliquid has no balance surface: user state is held as positions inside the exchange state machine. The indexed dataset covers fills, funding, transfers and staking positions instead, delivered as a data-share or a file delivery.
How do I get Hyperliquid 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 Hyperliquid coverage go?
The historical data-share and file delivery cover the chain's recorded history and are available today. Because Hyperliquid and HyperEVM are two execution surfaces on one chain, depth is confirmed per surface when the share is scoped, so tell us which side of the network your workflow needs.
What is the difference between Hyperliquid and HyperEVM?
They are two execution environments on one network. HyperCore, covered on this page, is the state machine that runs the order book and the perpetuals venue. HyperEVM is an EVM environment on the same chain, sharing 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.
Does Hyperliquid data look like EVM data?
No, and that is the main thing to plan for. There are no ERC-20 transfer events and no contract logs behind HyperCore activity, because the exchange is not implemented as contracts. Analysis that would join on decoded logs on an EVM chain joins on chain state here instead.
Is Hyperliquid EVM-compatible?
HyperCore itself is not an EVM environment. EVM compatibility on this network comes from HyperEVM, which runs alongside it under the same consensus, so contracts deploy there rather than to the order-book chain.
How do I start with Hyperliquid 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.