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
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. |
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 |
Column Name | Description |
---|---|
timestamp | The UTC timestamp of the block |
hash | Block hash |
height | Block height |
num_transactions | Total number of transactions in the block |
proposer | Address for the user that proposed the block. (Generated the block) |
Column Name | Description |
---|---|
action | The action triggered by the transaction. There are multiple types of actions. See notes. |
block_height | The height of the block the transaction belongs to. |
error | Error message if the action in the transaction failed. |
hash | Transaction hash. |
block_timestamp | The timestamp of the block the transaction belongs to. |
user | The address of the user that executed the transaction. |
Column Name | Description |
---|---|
Hash | Hash of the event |
Time | Timestamp |
Event | Event that happened. |
Event Types
Type | Description | Where Clause |
---|---|---|
accountActivationGas | event:LedgerUpdate:delta:type = ‘accountActivationGas’ | |
accountClassTransfer | event:LedgerUpdate:delta:type = ‘accountClassTransfer’ | |
deployGasAuction | event:LedgerUpdate:delta:type = ‘deployGasAuction’ | |
deposit | event:LedgerUpdate:delta:type = ‘deposit’ | |
internalTransfer | event:LedgerUpdate:delta:type = ‘internalTransfer’ | |
liquidation | event:LedgerUpdate:delta:type = ‘liquidation’ | |
rewardsClaim | event:LedgerUpdate:delta:type = ‘rewardsClaim’ | |
spotGenesis | event:LedgerUpdate:delta:type = ‘spotGenesis’ | |
spotTransfer | event:LedgerUpdate:delta:type = ‘spotTransfer’ | |
subAccountTransfer | event:LedgerUpdate:delta:type = ‘subAccountTransfer’ | |
vaultCreate | event:LedgerUpdate:delta:type = ‘vaultCreate’ | |
vaultDeposit | event:LedgerUpdate:delta:type = ‘vaultDeposit’ | |
vaultDistribution | event:LedgerUpdate:delta:type = ‘vaultDistribution’ | |
vaultLeaderCommission | event:LedgerUpdate:delta:type = ‘vaultLeaderCommission’ | |
vaultWithdraw | event:LedgerUpdate:delta:type = ‘vaultWithdraw’ | |
withdraw | event:LedgerUpdate:delta:type = ‘withdraw’ | |
CDeposit | Staking Deposit | event:CDeposit IS NOT NULL |
CWithdrawal | Staking Withdrawal | event:CWithdrawal IS NOT NULL |
Delegation | event:Delegation IS NOT NULL | |
Funding | Funding fee | event:Funding IS NOT NULL |
ValidatorRewards | event:ValidatorRewards IS NOT NULL |
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
Every transaction has an action.
You can see all the different types of actions by running
The above query can take a while to run
- for quicker query for a subset (may be missing some types)
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%.
This was due to two limitations.
- 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.
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.
Trades & Orders
Use order id, which is available on the trade and the order.
Orders & Transactions
While an open order is placed by making a transaction, currently we do not have the order id of the transaction available to us. So making the connection is only possible by using the order timestamp along with the size and coin, and try to match it.
Trades & Transactions
Trades aren’t exactly 1-1 with transactions. The transaction in a trade refers to the a transaction made to open one of the orders in the transaction.
Trades with 0x0 are made through TWAPS, these only have one transaction, the twapOpen and subsequent orders are done by the Hyperliquid Validators and therefore do not have a transaction hash.