Skip to main content

​
Access

The catalog is shared into your own Google Cloud project as a BigQuery share. The datasets land there under their own names, so a table reads <dataset>.<table>, qualified by your project id when you query it from outside that project. Compute is billed to you. Contact us to arrange the share.
dimensions, facts, metrics and functions. Standardized blockchain tables are shared separately, one dataset per chain, and Chain verticals covers them.

​
Querying

Every events table and daily table is partitioned on its timestamp column, and the largest ones hold billions of rows. Daily tables carry timestamp, set to midnight UTC for that day; event tables carry block_timestamp, the time of the block itself. A query with no bound on either column reads the whole table. Write the bound as a plain timestamp rather than wrapping the column in a function: where block_timestamp >= timestamp('2026-08-01') reads only the days it needs, and where date(block_timestamp) >= '2026-08-01' reads everything.
An empty cell in a daily table means no figure exists for that measure, for that thing, on that day. It does not mean zero, and it does not mean the day is missing.
No. dimensions.metrics holds the rule for every measure, in the over_time and across_dimensions columns. Measures of activity add up both ways. Balances add up across things but not across days: take the last day’s figure instead. Rates and counts of distinct addresses read unsupported across things, because the daily table alone does not hold enough to combine them correctly. Metric definitions explains each kind.
Adding two daily counts counts anyone who appeared on both days twice, and the counts do not tell you how many that was. The same goes across chains, deployments and assets. A correct wider count has to be worked out from the addresses themselves, which is what the compact summaries published alongside each count are for: two summaries can be combined before anything is counted. Assets ▸ Senders shows how.

​
Levels and identifiers

All of them. Fees are published for a market, for an app, for an app on one chain, for a project, and for a project on one chain. Where a measure is one you can add up, the broader figure is the narrower figures added together. Pick the level your question is asked at. The levels always agree, because a broader figure rolls up the narrower one rather than being worked out again from source.
An asset is a curated identity that spans chains: USDC is one asset. A token is one contract on one chain. The link between them is dimensions.asset_tokens, which holds one row per deployment of an asset. Assets covers the curated layer and Tokens covers every token onchain.
A bridged deployment is a wrapper standing in for supply that was issued natively somewhere else. Add the two columns and you count the same value twice. market_cap_circulating_native answers how much of an asset exists; market_cap_circulating_total answers how much of it is out there in some form, counting tokens outstanding rather than economic value.
Basic identifiers are lowercase names: asset_id reads usdc, chain_id reads ethereum. Identifiers that combine several of those join them with dashes, so a token_id is {token_address}-{chain_id} and an asset_token_id is {asset_id}-{token_address}-{chain_id}.

​
Market verticals and coverage

There are none. A market is the shared tables with one filter applied, so stablecoins are asset_type = 'stablecoin' over the asset tables. Nothing is copied per market, which means a correction to a peg or to how a deployment is classified shows up everywhere at once.
The project and app tables start from a small set of projects and widen from there. A thin table reflects that scope rather than a fault.
It varies from table to table and chain to chain. Each chain page lists its layers’ start dates.