Hyperliquid 🌱
Hyperliquid data is currently in beta and the schemas are subject to change. DEX Trades:
Data is backfilled, but as of March 2025, the Hyperliquid API has a limitation so only the last 10k trades per address are available. This means that we’re unable to get 100% coverage of trades for ~1% of traders (~4,000 traders). Once this is accessible, any gaps will be backfilled.
Hyperliquid 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.
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. Currently the order ‘open’ status is not showed, as this is a limitation in the information provided by the node. Subsequent status changes will be reflected. |
Coming Soon
Widthdrawals and deposits into Hyperliquid across Arbritrum, Bitcoin, Ethereum and Solana. See how value is flowing across chains.
L1 blocks with transactions.
- Track user interactions across HyperEVM and HyperCore L1.
- Track builder fees (what fees are applications charging)
Sample Queries
Get total monthly DEX volume on Hyperliquid over time
Get all available trades for a given user
Get all trades of BTC in the last 24 hours
Get a list of tokens traded in the last 24 hours, with a breakdown of spot vs perpertuals volume, ordered by total USD volume traded
Get daily activity metrics, aggregated by token, for the last 7 days
We can use some simple queries to view market resistance levels for the last 24 hours. (For more sophisticated clustering consider exporting the data and usind statiscal tools to identify clusters.)
Please be advised that this data is currently incomplete as open orders are still missing. We are working to complete this data set. However this will give you some sense of the levels.
- Limit losses levels
- The query below give you levels where traders are more likely to sell to limit their losses.
- Take Profit Levels
- This will give you the levels where traders are more likely to take profits.
- Circular Trading - two addresses trading back and forth
We can use some simple queries to view market resistance levels for the last 24 hours. (For more sophisticated clustering consider exporting the data and usind statiscal tools to identify clusters.)
Please be advised that this data is currently incomplete as open orders are still missing. We are working to complete this data set. However this will give you some sense of the levels.
- Limit losses levels
- The query below give you levels where traders are more likely to sell to limit their losses.
- Take Profit Levels
- This will give you the levels where traders are more likely to take profits.
- Circular Trading - two addresses trading back and forth
Monitor big movements and predict what is happening in the market
- Identify top sellers in the last month
- Identify Top Buyers
- Monitor the above addresses for open trades (coming soon)
For now you can view what these whales have been doing by removing the o.STATUS = ‘open’, which will show you all the order status changes, so will capture a lot of the movement, but any orders that were placed and have not been cancelled, modified or filled, will not be visible.
- Most profitable traders
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. |
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. |
Column Name | Description |
---|---|
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 |
price | Price of the coin at the time of the trade |
side | B = Buy (spot) / Long (perpetuals) A = Sell (spot) / Short (perpetuals) |
size | Units of the coin that were traded |
users | An array of 2 users that were involved in the trade |
transaction_hash | The transaction hash for the trade. *See notes for Null Transaction hash. |
trade_id | An identifier for the trade. Some historical trades share a tid of 0 |
timestamp | The UTC timestamp of when the trade was executed |
unique_id | A unique identifier for each trade |
extra_fields | Additional information for each trade. See notes for more details. |
Column Name | Description |
---|---|
client_order_id | Custom order ID provided by the user |
order_id | Order ID generated by Hyperliquid |
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 |
is_take_profit_or_stop_loss | Boolean Whether this order is a take profit or stop loss order |
is_trigger | Boolean Whether this order has a trigger condition. For instance the order is only in effect if the price goes above 25. See Notes for more details. |
type | The type of order. Refer to the Hyperliquid Docs |
original_size | The size of the original order For example if the order size has since changed since it was partially filled, then the original_size will show a different value |
is_reduce_order | Whether this order reduces the current position, instead of opening a new order in the opposite direction. Refer to the Hyperliquid Docs |
side | B - Buy A - Ask (Sell) |
size | Order size. This is the current order size. So if partially filled, this will be the size of the unfilled part |
time_in_force | Behaviour for the order. Refer to the Hyperliquid Docs |
order_timestamp | This refers to the original order timestamp. See original_size. So depending on when the order status changes, this can be quite different from status_change_timestamp . |
trigger_condition | What will make this order become active, go into the order book. For example ‘Price below 1560.1’ The value can also be ‘Triggered’ which means the trigger condition has already been met and the order is in active in the order book. For an example see SELECT * from hyperliquid.raw.orders where order_id = '44776647532'; |
trigger_price | The price for it to be triggered, if it is a trigger. See is_trigger Will match the value in trigger_condition |
limit_price | Maximum price the buyer or seller are willing to pay |
children | Children will contain one or two orders, which will be added once the parent order is triggered. These can be a take profit and/or a stop loss. For examples see SELECT * from hyperliquid.raw.orders where order_id = '82039428821' or order_id = '82161896540' or order_id = '82182749399'; |
status | The status which the order has after the order_status_change_timestamp. Refer to the Hyperliquid Docs for a list of all possible statuses. Currently we do not have the initial status Open refer to the Notes |
user | user that owns the order |
status_change_timestamp | The time at which the status of this order changed. Basically represents the time at which the entries in this row took effect |
unique_id | A unique id generated by Allium to represent each record |
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_fields
are 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_fields
not 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_fields
populated 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_fields
populated with both buyer and seller details: we were able to backfill details for both sides of the trade
**Sample on **
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_fields
are 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_fields
not 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_fields
populated 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_fields
populated with both buyer and seller details: we were able to backfill details for both sides of the trade
**Sample on **
In most cases, the trade_id
can be thought of as the unique identifier for a trade. However, there are cases where this isn’t true:
- Before 24 Nov 2023: For historical Hyperliquid trades before 24 Nov 2023, the
trade_id
for all trades was 0. For those trades, we construct a unique_id from other values. - After 24 Nov 2023: There are a handful of trades where the Hyperliquid API returns the same
trade_id
for trades from different transactions. Because of this, we use the combination oftrade_id
andtransaction_hash
unique identifier for trades.
You can maybe find null transaction hashes, these are TWAPs
See Hyperliquid TWAP for more details.
A transaction with action “Place TWAP order” will look like the one linked in the; [Hyperliquid Explorer](https://app.hyperliquid.xyz/explorer/tx/0xd6f17b6efa51bd1a1ff30420be17af02015400689f842aff45bb18a090bd8c44
Once such a transaction is sent multiple, orders will be placed within the specified time range, these will have a null transaction hash.
The hyperliquid node currently does not save order statuses unless the order already exists. Therefore open is not saved into the file, that the node generates, which is the source of this data.
For all the statuses the orders currently have run:
is_trigger
field is either true or false.
In the case where is_trigger
is true the field
FAQs
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.
**How are liquidations treated in the **dex.trades
table?
To find liquidations, look for any dex.trades where the HLP Liquidator (0x2e3d94f0562703b25c83308a05046ddaf9a8dd14
) is either the buyer or seller address.
Hyperliquidity Provider (HLP) is a protocol vault that does market making and liquidations. The HLP Liquidator is a component strategy that’s part of the HLP. As per Hyperliquid, “this strategy liquidates positions on all coins as soon as they become liquidatable. Once it acquires these positions, it exits the positions using a market making algorithm.”
**Why is the buyer or seller (sometimes both) in **extra_fields
in the trades table sometimes null?
This is due to two current limitations. (We are working on improving these.)
- 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.
Issue 1 coupled with 2 can cause us to not be able to fetch the fills before the the end up outside the 10000 limit, for users with very high trading volume.