> ## Documentation Index
> Fetch the complete documentation index at: https://tokenterminal.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> Common questions about the data catalog.

## Access

<AccordionGroup>
  <Accordion title="How do I get 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.
  </Accordion>

  <Accordion title="Which datasets does the share cover?">
    `dimensions`, `facts`, `metrics` and `functions`. Standardized blockchain tables are shared separately, one dataset per chain, and [Chain verticals](/docs/catalog/chain-verticals/index) covers them.
  </Accordion>
</AccordionGroup>

## Querying

<AccordionGroup>
  <Accordion title="Why is my query scanning terabytes?">
    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.
  </Accordion>

  <Accordion title="A measure I expected is empty. Is the data missing?">
    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.
  </Accordion>

  <Accordion title="Can I add any measure up across days or across things?">
    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](/docs/catalog/metric-definitions) explains each kind.
  </Accordion>

  <Accordion title="Why can't I add up a count of distinct addresses?">
    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](/docs/catalog/assets/senders) shows how.
  </Accordion>
</AccordionGroup>

## Levels and identifiers

<AccordionGroup>
  <Accordion title="The same metric appears at several levels. Which one is right?">
    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.
  </Accordion>

  <Accordion title="What is the difference between an asset and a token?">
    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](/docs/catalog/assets/index) covers the curated layer and [Tokens](/docs/catalog/tokens/index) covers every token onchain.
  </Accordion>

  <Accordion title="Why do native and bridged supply have separate columns?">
    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.
  </Accordion>

  <Accordion title="How are identifiers put together?">
    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}`.
  </Accordion>
</AccordionGroup>

## Market verticals and coverage

<AccordionGroup>
  <Accordion title="Where are the stablecoin tables?">
    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.
  </Accordion>

  <Accordion title="Some project and app tables look thin. Why?">
    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.
  </Accordion>

  <Accordion title="How far back does history go?">
    It varies from table to table and chain to chain. Each chain page lists its layers' start dates.
  </Accordion>
</AccordionGroup>