Data Coverage & Retention

How far back Bitquery data goes depends on the chain, the cube (Trades, Transfers, Balances, Holders, …), the dataset (realtime, archive, combined), and the interface (GraphQL, WebSocket, Kafka, or a Data Store export). This page is the single source of truth for those windows. If a query returns empty results for a date range, check here first — most "missing data" reports are really a dataset or retention mismatch, not a bug.

Windows expand over time

Retention windows widen as coverage grows. If you need more than the realtime window, add the chain's historical add-on to a paid plan, move to Enterprise for complete history on every chain, or buy a Data Store export (see below).

The three datasets: realtime, archive, combined

Every GraphQL cube is served from one or more datasets, selected with the dataset: argument:

• realtime — the most recent data (roughly the last few hours), lowest latency. Always available.
• archive — deep history. Available where Bitquery has back-indexed the chain/cube.
• combined — stitches archive + realtime into one continuous result. Use it when you need both history and the latest rows in a single query.

Availability differs by chain and by cube. Selecting a dataset a chain doesn't support surfaces a ClickHouse error such as no table can query <Cube> ... consider use realtime dataset. That's not a bug — it means the archive/combined table for that cube isn't deployed on that chain. See the dataset reference for details.

combined is not available everywhere, and does not always fail cleanly

Two cases to know about before you rely on combined:

• Solana — combined works on DEXTrades and DEXTradeByTokens. DEXTrades on archive and combined needs a time or slot bound: see Historical DEXTrades on archive and combined. For the other Solana cubes, see the Solana table below.
• EVM Events and Calls — also return a 500 on combined, while Transfers, Transactions, Blocks and the DEX cubes work.

Where a dataset is genuinely undeployed you get the clean no table can query … message above. A raw 500 is a different thing. If you hit one, re-run the same query on archive before treating it as an outage.

Measure your own window

Retention also depends on your plan, so confirm rather than assume. One query per cube gives you the floor:

query RetentionFloor {
  Solana(dataset: realtime) {
    Transfers(limit: { count: 1 }) {
      Block {
        oldest: Time(minimum: Block_Time)
        newest: Time(maximum: Block_Time)
      }
    }
  }
}

Time(minimum: Block_Time) returns the oldest row the dataset currently holds. Swap the cube, the dataset: and the chain root to fill in the matrix for your own account.

Note that Balances and Holders expose Block.Date but not Block.Time, so the query above errors against them. Their grain is daily rather than per-block, so "how far back" is answered by ordering on Block_Date instead. See end-of-day balances.

Rule of thumb: reach for realtime for live/streaming use cases, combined for "recent history + now", and archive for pure backfills — but only where the matrix below says archive exists.

Coverage matrix

Windows are expressed as rolling ranges, not fixed dates, so they stay correct over time.

EVM chains (Ethereum, BSC, Base, Arbitrum, Optimism, Polygon, …)

Cube	realtime	archive / combined	Kafka	Notes
DEX Trades	✅	✅ full history	✅	Deep history via combined.
Transfers	✅	✅ full history	✅
Transactions	✅	✅ full history	✅
Balances	✅	✅	—	Query at a block/date for point-in-time balances.
Holders	✅	✅ all v2 EVM chains	—	The Holders API is available on all v2 EVM chains.
Calls & Events	✅ ~24 h	~3 months (Ethereum: full history)	✅	~3 months on all EVM chains except Ethereum, which keeps full history. Older data on any chain (including Ethereum) via a Data Store export. combined currently 500s on these two cubes — use archive.
Mempool	✅ (stream)	—	—	Pending-tx data is realtime only.

Solana

Cube	realtime	archive / combined	Kafka	Notes
DEXTradeByTokens	✅ ~7 days	Since mid-2024 (archive)	✅	The longer-retention chain-level trade cube (vs ~12 h on DEXTrades). For anything within ~30 days prefer the Trading cube; use this for older history or instruction context.
DEXTrades	✅ ~12 hours	Individual trades, being backfilled toward 2024 (archive / combined)	✅	Same trades as above. On archive and combined a query needs a Block.Time, Block.Slot or Block.Date bound: see Historical DEXTrades.
OHLC / price aggregates	✅	Minute-level since October 2024	✅ (trading topics)	Chain-level aggregated candles go back much further than raw trades. (Distinct from the Trading cubes' pre-aggregated OHLC, which is ~30 days.)
Transfers	✅ ~12 hours	—	✅	Older history via a Data Store export.
Instructions	✅ ~12 hours	—	✅	Deep historical instruction lookup by signature is not available via API.
InstructionBalanceUpdates	✅ ~12 hours	—	✅
BalanceUpdates	✅ ~12 hours	—	✅	Solana has no Balances cube; balance changes are queried here.
DEXPools	✅ ~12 hours	—	✅	Realtime only. The archive / combined datasets do not exist for this cube — a query against them errors with no API tables for cube DEXPool. For historical pool state use a Data Store export.
Transactions / Blocks / Rewards / DEXOrders / TokenSupplyUpdates	✅ ~12 hours	—	✅

Two Solana cubes carry the same trades with very different depth

On realtime, DEXTrades retains roughly 12 hours; DEXTradeByTokens retains roughly 7 days — about 15× longer, from the same underlying trades. On archive, DEXTrades holds individual trades, being backfilled toward 2024, and DEXTradeByTokens reaches back to mid-2024 as aggregates.

That pair is the exception, not a general rule: every other Solana realtime cube measured here holds roughly 12 hours, including BalanceUpdates, DEXPools, Transfers, Instructions and TokenSupplyUpdates. If a Solana query "loses" older data, check whether DEXTradeByTokens or an archive dataset covers the same question before assuming the history is gone.

Tron & Bitcoin

Cube	realtime	archive / combined	Notes
Transfers / Transactions	✅	✅ full history	Full archive available.
Balances	✅	✅	Point-in-time supported.
Coinpath (money flow)	—	✅ (v1)	Coinpath is served by the v1 API; there is no v2 equivalent yet. For AI-driven fund tracing, use the Bitquery MCP server (Tracing MCP guide).

Trading cube (cross-chain Trades / Tokens / Pairs)

Surface	Window	Notes
Trades / Tokens / Pairs / Currencies	~30 days	All four cubes measure the same floor. For older raw trades use chain-level DEXTradeByTokens or a Data Store export.
Price / OHLC aggregates (Tokens / Pairs / Currencies)	~30 days	Pre-aggregated OHLC down to 1-second intervals, same rolling window as Trades. See the Crypto Price API.

Robinhood chain

Cube	Window	Notes
Trades	Since the chain was onboarded	Full history from onboarding forward.
Transfers	Complete history	Full transfer history available.

Arc mainnet

Circle's Arc mainnet uses EVM(network: arc). The realtime path, USD fields, Holders, and the cross-chain Trading.Trades, Trading.Tokens, and Trading.Pairs cubes returned live data in checks on 16 September 2026. dataset: archive and dataset: combined were not enabled, so leave the dataset argument out and measure the live window before assuming a range. See the Arc Mainnet API guides.

Surface	Window	Notes
EVM cubes	Realtime window	Query with EVM(network: arc) and no dataset argument.
Trading.Trades, Trading.Tokens, Trading.Pairs	Trading rolling window	Filter with network name Arc or network id bid:arc.
archive, combined	Not available	Retry before building a historical backfill.

Arc testnet

Circle's Arc testnet (EVM(network: arc_testnet)) is served from the realtime dataset only. There is no archive for the testnet, so dataset: archive and dataset: combined return errors, the Holders cube is not available, and every ...InUSD field is 0. The realtime window is a rolling range of recent blocks; measure it with Block { Time(minimum: Block_Time) }. Use Arc mainnet for live production data with USD pricing. See the Arc Testnet hub.

Cube	Window	Notes
DEXTrades, DEXTradeByTokens, Transfers, Events, Calls, Transactions, Blocks, Balances, TransactionBalances	Realtime window only	No archive; USD fields are 0.
Holders, DEXPoolEvents, DEXPoolSlippages, Trading.*	Not available	Holders needs the archive; pool cubes have no data yet; the Trading cubes cover mainnet chains only.

Hyperliquid

Hyperliquid core is an L1 order-book exchange, so its cubes carry exchange events rather than EVM blocks. The cubes are served from the realtime dataset only: dataset: archive and dataset: combined return the error API schema not configured. Windows measured on 13 October 2026:

Cube	realtime / API	API archive dataset	Kafka	Notes
Trades, PerpLiquidations, PerpFundings, Twaps, PriceUpdates, TraderLeverageUpdates, Candles	✅ ~30 days	Not available	✅	Fills, liquidations, hourly funding, TWAPs, leverage changes, and oracle and mark prices (HIP-3 markets only). Candles stream on their own topic.
Orders, BookUpdates, SignedActions	✅ ~7 days of raw rows	Not available	✅	Order counts by market, trader, status, side or type come from 10-minute aggregates that reach back ~30 days, so a count over an older date returns numbers while a row-level select for the same date returns [].
CurrentPositions, MarkPrices	Current state, no time window	Not available	—	One row per account and market; MarkPrices has one per HIP-3 market. RealizedPnl and Funding are sums since the data window began (~30 days), not lifetime. Query only.

Where older Hyperliquid data lives

The API window is rolling, which suits bots, dashboards and monitoring. A query for a date before the window returns an empty list with HTTP 200, not an error. For older data:

• Data Store export: parsed Hyperliquid tables as Parquet files. The Data Store lists the last 30 days on every table, including the order flow the API keeps for only ~7 days. Older ranges are available on request from sales@bitquery.io.
• Blockchain Data Lake: the raw HyperCore feed (the node's event streams and consensus transactions) from 17 July 2026, which you decode and parse your own way. The parsed messages that Kafka and the API serve are not stored there.

Hyperliquid's own s3://hyperliquid-archive bucket holds L2 book snapshots and asset contexts only, refreshed roughly monthly with no completeness guarantee. Contact sales@bitquery.io for a Hyperliquid export covering an older range.

Kafka is not a historical firehose

Streams are for live data. Kafka keeps a short replay window, not history. Solana gRPC has no replay. If you connect a fresh consumer, you get recent messages forward, not the chain from genesis. For older data, use GraphQL (within the API's retention) or a Data Store export. See the Kafka Operations Cookbook.

Need more history than the API keeps?

When you need a full backfill beyond the API windows above:

• Data Store exports: parsed Parquet datasets you download from S3 or Cloudflare R2 (or get delivered to your own bucket or warehouse as a custom export), including history older than the API window. See Data Store exports.
• Blockchain Data Lake: raw Protobuf blocks over S3, using the same schema as the Kafka streams, which you decode and parse your own way. For Hyperliquid it holds the raw feed from 17 July 2026. See Data Lake.
• Enterprise plans — the self-serve plans (Personal/Pro/Scale) share a rolling window (about 30-day trades and 4–8h on-chain data); history on a self-serve plan comes from a per-chain historical add-on, Enterprise includes complete history on every chain, and a Data Store export covers bulk history. See the pricing page. See Plans, Points & Limits.

Contact sales@bitquery.io for custom export ranges.

Frequently Asked Questions

How far back does Solana DEX trade data go?

It depends which cube and dataset you ask. Solana.DEXTrades keeps roughly the last 12 hours on realtime, and its archive and combined datasets hold individual trades, being backfilled toward 2024, with a required Block.Time, Block.Slot or Block.Date bound. Solana.DEXTradeByTokens keeps roughly 7 days on realtime and reaches back to mid-2024 on archive as aggregates. The cross-chain Trading.Trades cube keeps about 30 days. For raw trades beyond the archive, use a Data Store export.

Why does my query return empty results for old dates?

Usually the date range is outside the retention window for that cube/dataset, or the cube isn't deployed on that chain's archive. Realtime does not error when you ask beyond its window — it silently returns fewer rows, so a chart just starts late. Check the coverage matrix above and switch to archive for history. On Solana DEXTrades, archive and combined both need a time or slot bound, and lists should be ordered by Block_Slot.

What is the difference between realtime, archive and combined datasets?

realtime is the most recent data — roughly 12 hours on Solana raw cubes, about a day on EVM Events/Calls and a few days on EVM Transfers and DEX cubes, and about 2 days on Tron. archive is deep history. combined merges both, but it is not available everywhere: on Solana it works on DEXTrades and DEXTradeByTokens only, and it is not available on EVM Events and Calls. Availability differs per chain and per cube.

How far back does Hyperliquid data go?

The Hyperliquid API keeps about 30 days of trades, liquidations, funding, TWAPs, prices and candles, and about 7 days of raw orders, book updates and signed actions. The API has no archive dataset, so older dates return an empty list, not an error. For older parsed history, use a Data Store export: the Data Store lists the last 30 days on every table, order flow included, and older ranges are available on request. The Blockchain Data Lake holds the raw HyperCore feed from 17 July 2026, which you decode and parse your own way. Hyperliquid's own public s3://hyperliquid-archive bucket carries L2 book snapshots and asset contexts only, with no trades, candles or spot data.

Does Kafka include historical data?

No. Kafka streams realtime data plus a few hours of backfill. For history, use GraphQL (within retention) or a Data Store export.

How do I get data older than the API retention window?

Use a Data Store export (parsed Parquet), or an enterprise historical export. See the Data Store exports page and contact sales for custom ranges.

Next steps

• Datasets: realtime, archive, combined
• Common errors — including empty results
• Kafka Operations Cookbook
• Data Store exports (Parquet)