HyperCore ledger events: deposits, withdrawals, sends, vault flows, funding payments, staking and bridge events, plus actions written from HyperEVM contracts.
Hyperliquid ledger and funding data from the HyperCore L1. The misc_events table holds every non-trading account event: ledger updates (deposits, withdrawals, sends, sub-account and account class transfers, vault flows), funding payments, bridge deposits and withdrawals, staking delegations, validator rewards and gossip. InnerType says which event a row is, and only that group's columns are filled. The core_writer_actions table records actions HyperEVM contracts wrote into HyperCore through the CoreWriter precompile, with the HyperEVM transaction hash that triggered each.
Balances are not a table here; derive them by summing ledger deltas per User and Token from a known starting point, and add the fills from the Hyperliquid Trades dataset for perp position changes. Amounts are decimal strings, addresses are 0x-prefixed hex, and Time is epoch nanoseconds.
Ledger updates (deposits, withdrawals, sends, transfers, vault flows), funding payments, bridge events, delegations, validator rewards and gossip. InnerType says which; only that group's columns are filled.
hyperliquid/misc_events<start_block>_<end_block>.parquet200 blocks per fileActions written into HyperCore from HyperEVM contracts through the CoreWriter precompile: spot sends, orders, vault and class transfers, staking, with the HyperEVM transaction hash.
hyperliquid/core_writer_actions<start_block>_<end_block>.parquet200 blocks per filemisc_events38 columnsLedger updates (deposits, withdrawals, sends, transfers, vault flows), funding payments, bridge events, delegations, validator rewards and gossip. InnerType says which; only that group's columns are filled.core_writer_actions27 columnsActions written into HyperCore from HyperEVM contracts through the CoreWriter precompile: spot sends, orders, vault and class transfers, staking, with the HyperEVM transaction hash.Send this dataset’s full schema to an assistant and ask it anything. It reads the plain-text brief first, so the answer comes from the real column list rather than a guess.
Opens a new chat with the question filled in. Nothing about you is sent to Bitquery, and the assistant sees only the public brief.
Parquet files, delivered as signed download links by email after payment, in this layout:
# misc_events — 200 blocks per file hyperliquid/misc_events<start_block>_<end_block>.parquet # core_writer_actions — 200 blocks per file hyperliquid/core_writer_actions<start_block>_<end_block>.parquet
Two Parquet tables from HyperCore: misc_events and core_writer_actions, with 65 documented columns. Every row carries Block_Number and Block_Time, so the tables join on block with each other and with the Hyperliquid Trades and Order Book datasets.
Small next to the order book. In a measured 1,000-block slice (about 73 seconds) we counted 32 misc events and 10 CoreWriter actions. Scaled to a day that is roughly 40,000 ledger rows; exact row counts and sizes come with the delivery manifest, and these figures are estimates.
No. It includes every event that changes a balance, so balances can be derived per User and Token by summing LedgerUpdate_Delta_Amount from a starting point. Perp position changes come from fills in the Hyperliquid Trades dataset.
Filter misc_events on InnerType = Funding. The Funding column holds the payment details for that row; the LedgerUpdate_ columns are null on funding rows.
A HyperEVM smart contract calling into HyperCore: placing an order, sending spot tokens, moving funds to a vault, staking. Each row names the action type, its fields and the EvmTxHash on HyperEVM that caused it, so the two chains can be joined.
30 days. HyperCore history is kept as a rolling 30-day window, so a purchase covers the 30 days up to yesterday and there is no longer window to buy. For a continuous feed beyond that, ask about the live stream.
Because the node emits them that way and we keep the values as emitted. Block_Time and the Time column on statuses and events are epoch nanoseconds; Fill.Time and Order.Timestamp are epoch milliseconds. Divide by 1e9 or 1e3 respectively when converting to timestamps.
The node emitted a field that the schema does not model yet, and we kept it rather than dropping it. Extra is empty on nearly every row. When a new field appears it lands there first, so nothing is silently lost between schema versions.
With DuckDB: SELECT * FROM read_parquet('fills/*.parquet'). With pandas: pd.read_parquet('fills/'). Parse Px, Sz, Fee and the other money columns with Decimal rather than float; they are stored as decimal strings on purpose.
Yes. These field definitions are the ones Bitquery's Hyperliquid Kafka topics use, so a backtest reading this archive and a production consumer reading the live stream decode with the same code.
As flat Parquet files under a stable S3 layout, one prefix per table and one file per 200-block range, with a JSON manifest listing every file and its sha256. Signed HTTPS links are emailed once the files are prepared. Refreshed daily with T+1 latency; a purchase made today includes everything up to yesterday.
Yes. Every table links to a public sample Parquet file from a real 1,000-block slice, and the sample repository on GitHub shows the first records of each table as readable JSON. No email address required.
Every bonding-curve trade, token creation, migration and pool on Pump.fun, plus per-token OHLCV, decoded and USD-priced.
Every Pons launch, bonding-curve trade and graduation on Robinhood Chain, decoded from the chain and priced in USD.
HyperCore fills, order statuses, L4 book diffs, oracle pushes, ledger events, TWAPs and CoreWriter actions, block by block, as Parquet.
Tell us the chain, tables and date range.