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)