Blockchain Analytics known issues

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

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.

Select category Avalanche Ethereum Fantom Optimism Tron

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.
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.

Send feedback