Blockchain Analytics known issues

This page lists Blockchain Analytics known issues and workarounds. For a list of bugs, new features, and other release information, see Release notes.

To filter this page, do one or more of the following: select a category, type a search term, or click a column heading to sort.

Category Subject Description
Ethereum Accounts data
  • The accounts_state table stores data about accounts seen in the to or from position of transactions initiated by externally owned accounts. Today, Blockchain Analytics does not compute mutations to account state as a result of internal transactions (transactions between smart contracts).
  • The accounts_state table shows a static snapshot of all accounts seen on-chain from the genesis block to block 17,399,999, including block 17,399,999. Starting from block 17,400,00, Blockchain Analytics adds a new row to the accounts_state table every time an account is observed participating in a transaction initiated by an externally owned account.
  • The accounts_state table does not hold storage state and storage proofs for smart contracts.
Avalanche
Ethereum
Fantom
Optimism
Tron		 Addresses

Because Blockchain Analytics indexes addresses as returned by the upstream node's JSON-RPC API, addresses in Blockchain Analytics datasets are indexed in all lowercase.

Use LOWER() when working with mixed case addresses.

For example:

SELECT
  *
FROM
  bigquery-public-data.blockchain_analytics_ethereum_mainnet_us.transactions
WHERE
  to_address = LOWER("0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48")
AND
  block_number = 17641663;
Ethereum Data freshness Blockchain Analytics indexes Ethereum upon finalized commitment. The indexer waits for majority two-thirds validation from Ethereum validators before indexing data. Because of this, data is typically two epochs (or 64 slots) behind the latest block. This is roughly 12 - 15 minutes behind latest.
Polygon Data freshness The Polygon data will remain approximately 24 hours behind the tip-of-chain.
Ethereum Traces Blockchain Analytics indexes and normalizes Ethereum traces to Parity-style traces.
Avalanche
Ethereum
Fantom
Optimism
Tron		 UINT256 To perform lossless UINT256 computation, usage of UDFs is required. UDFs are subject to quote limit, rate limit and time-outs as described in User-defined functions, Limitations.
Avalanche
Fantom
Optimism
Tron		 Missing transaction receipts Affected chains may be missing rows from the transaction receipts table. This currently affects < 0.1% of all transactions per chain.
Avalanche
Fantom
Optimism
Tron		 Table partitioning and clustering

Tables for affected chains are not partitioned. Tables are clustered by columns used to form the primary key for the table. Refer to Table Info for each table.

BigQuery table info. Click to enlarge image.

Avalanche
Ethereum
Fantom
Optimism
Tron		 Schema consistency across chains

Datasets for all chains have the following tables:

  • Blocks
  • Transactions
  • Receipts
  • Logs

Tables in the Avalanche, Fantom, Optimism, and Tron datasets share the same table schemas.

The Ethereum dataset includes additional tables and slight schema differences from Avalanche, Fantom, Optimism, and Tron.

All tables in the Ethereum dataset include the block timestamp column.

Refer to the schemas page for more information.