Hyperliquid
Overview
Hyperliquid (HyperCore) is an L1 built to support an ecosystem of permisionless financial applications. The flagship native application is the Hyperliquid DEX, a fully onchain order book exchange.
Click here if you are looking for the EVM compatible chain HyperEVM
This was due to two limitations.
On Hyperliquid DEX Trades:Hyperliquid DEX Trades are fully backfilled for every address, except for ~4,000 traders (~1% of traders) who had made more than 10k trades at the time of backfill in March 2025. This is because the Hyperliquid API only makes the last 10k trades available, and there are no other ways to retrieve the missing historical data. This means the following data is available:
- pre-March 2025: all trades are available for all addresses, except for ~4,000 traders, where only the last 10k trades are available
- March 2025 onwards: all trades are available for all addresses
On Hyperliquid Orders:Hyperliquid Orders cannot be backfilled.Data is available since we started running non validator nodes in house. Though we’ve tried to minimise the possibility of missing data, with reduncy, gaps may exist if node failures occur.
Tables
Using
hyperliquid.dex.trades is recommended as it enriches the raw.trades table with relevant trade & token metadata| Table Name | Description |
|---|---|
hyperliquid.raw.trades | Raw Hyperliquid spot & perpetual trades data This is available as a real-time Kafka stream without the extra_fields column. |
hyperliquid.dex.trades | Enriched Hyperliquid spot & perpetual trades data. |
hyperliquid.raw.tokens | List of tokens that are traded on Hyperliquid DEX, with token metadata such as token name and symbol. Currently only includes spot tokens. |
hyperliquid.assets.transfers | Token transfers on Hyperliquid L1. Currently only includes deposits & withdrawals for Arbitrum. (Coming Soon) Bitcoin, Ethereum, Solana. |
hyperliquid.raw.orders | Shows order status changes. So when an order goes from open, to filled, cancelled or any other possible status. See FAQ - Why are there missing orders in the raw.orders table? |
hyperliquid.raw.blocks | Blocks metadata. |
hyperliquid.raw.transactions | Transactions data for each block on Hyperliquid. |
Table Columns
| Column Name | Description |
|---|---|
| market_type | The type of market for the trade, e.g. spot, perpetuals |
| coin | A unique identifier for the asset being traded: • The coin for perpetuals is the standard token symbol, e.g. HYPE • The coin for spot tokens is an ID representing a pair of tokens based on Hyperliquid’s metadata, e.g. @4 (coin) represents token 5/token 0, which corresponds to JEFF/USDC The metadata is available from the info endpoint of Hyperliquid’s API |
| token_a_symbol | The symbol of the first token in the trading pair |
| token_b_symbol | The symbol of the second token in the trading pair. At the moment, this is always USDC |
| amount | The quantity of token_a being traded (normalized) |
| price | The execution price of token_a for the trade, in terms of token_b (usually USDC) |
| usd_amount | The quantity of token_a being traded, in USD terms |
| buyer_address | The address of the buyer in the trade |
| seller_address | The address of the seller in the trade |
| timestamp | The UTC timestamp of when the trade was executed |
| transaction_hash | The transaction hash for the trade. There can be multiple trades (i.e. multiple records with different trade_id) for the same transaction_hash. *See notes for Null Transaction hash. |
| trade_id | An identifier for the trade. Some historical trades share a tid of 0 |
| unique_id | A unique identifier for each trade |
| extra_fields | Additional information for each trade. See notes for more details. |
Notes
The
extra_fields column contains additional information for each trade including fees and liquidation details. Some caveats to be aware of:- New trades are first fetched from Hyperliquid Websocket API, so the
extra_fieldsare initially unavailable. We attempt to refetch all new trades via the Info endpoint, to source theextra_fields. Given the 10k transaction limit on the API, it’s possible that some trades cannot be refetched. - Because of the above, trades may have:
extra_fieldsnot populated with buyer or seller details: this means the trade could not be backfilled with additional information. These can be identified byextra_fields:source = 'api.hyperliquid.xyz/ws'extra_fieldspopulated with one of the buyer or seller details: we were able to backfill details for one side of the trade (i.e. the buy side or sell side)extra_fieldspopulated with both buyer and seller details: we were able to backfill details for both sides of the trade
FAQs
Is it possible to fetch all historical trades of <address>?
Is it possible to fetch all historical trades of <address>?
The Hyperliquid API currently has a limitation, so only the last 10k trades for each address is available. If an address has made less than 10k trades as of the time of backfill (~March 2025), then all their historical trades will be available. However, fetching all historical trades is not currently possible for addresses that have done more than 10k trades. Once historical data becomes accessible, any gaps will be backfilled.
Why is the buyer or seller (sometimes both) in extra_fields in the trades table, but sometimes null?
Why is the buyer or seller (sometimes both) in extra_fields in the trades table, but sometimes null?
As of the beginning of June we have remediated this problem.
At least 99.5% of the entries include buyer and seller in the extra_fields.
The amount of entries that are missing either the buyer, seller or both in the extra_fields is less than 0.5%.
At least 99.5% of the entries include buyer and seller in the extra_fields.
The amount of entries that are missing either the buyer, seller or both in the extra_fields is less than 0.5%.
- Hyperliquid’s endpoint not returning more than the 10000 latest fills.
- Hyperliquid’s api rate limiting, which causes us to not be able to fetch the data for all the trades fast enough.
Why are there missing orders in the raw.orders table?
Why are there missing orders in the raw.orders table?
From
2025-06-08 12:18:08.047 all order status are available.Up until 2025-06-08 12:18:08.047 the nodes did not expose orders when they were placed. This meant that an order with ‘open’ status did not show up, only subsequent status changes would be reflected in the table.How can I match orders, trades and transactions?
How can I match orders, trades and transactions?
While the data is available in both. It is not awalys possible to directly match them.