# Token Terminal Docs > ## Agent Instructions > To query the Token Terminal data catalog, read https://tokenterminal.com/docs/catalog/agents-manual.md first. It is the whole catalog as one page: table naming grammar, key columns, partition and cluster rules, units, additivity, and the tables that are documented but not served yet. > Never query a catalog table on a time bound alone. Also filter its cluster key, which you read from INFORMATION_SCHEMA.COLUMNS; an empty result means the object is a view, whose pruning contract is on its page. Compute is billed to the caller's own Google Cloud project. # Get a list of all assets Source: https://tokenterminal.com/docs/api-reference/assets/get-a-list-of-all-assets /api-reference/openapi.json get /v2/assets Use this endpoint to retrieve a list of all assets that are available on the API. # Get a list of all reference assets Source: https://tokenterminal.com/docs/api-reference/assets/get-a-list-of-all-reference-assets /api-reference/openapi.json get /v2/reference-assets Use this endpoint to retrieve the reference assets available on the API. A reference asset is the price reference that a tokenized asset tracks — a credit fund, an equity index, a commodity, a fiat currency, or a crypto asset. It is a finer-grained classification than `asset_type`: every tokenized fund shares one `asset_type`, but each tracks a different reference asset. Use the `reference_asset_id` values returned here with the `reference_asset_ids` filter on `/v2/assets` and on the asset metrics breakdown endpoint. # Get an asset fact sheet Source: https://tokenterminal.com/docs/api-reference/assets/get-an-asset-fact-sheet /api-reference/openapi.json get /v2/assets/{asset_id}/fact-sheet Retrieve the latest fact sheet for one asset, including disclosure values, availability statuses and supporting sources. Find covered assets with `GET /v2/assets?has_fact_sheet=true`. Add `include_tokens=true` to include token deployments. Look up field titles and option descriptions with [field definitions](/api-reference/assets/get-fact-sheet-field-definitions). An asset without a fact sheet returns `404`. Response examples are abbreviated; expand the schema to see all disclosure fields. # Get asset details and available metrics Source: https://tokenterminal.com/docs/api-reference/assets/get-asset-details-and-available-metrics /api-reference/openapi.json get /v2/assets/{asset_id} Use this endpoint to retrieve detailed information about a specific asset, including the list of available metrics. # Get asset fact sheets Source: https://tokenterminal.com/docs/api-reference/assets/get-asset-fact-sheets /api-reference/openapi.json get /v2/fact-sheets Retrieve the latest fact sheets for 1–20 comma-separated `asset_ids`. Results follow the requested order; duplicate IDs appear once. If any asset has no fact sheet, the whole request returns `404` with missing IDs in `meta.asset_ids`. Find covered assets with `GET /v2/assets?has_fact_sheet=true`. Add `include_tokens=true` to include token deployments. Look up field titles and option descriptions with [field definitions](/api-reference/assets/get-fact-sheet-field-definitions). Response examples are abbreviated; expand the schema to see all disclosure fields. # Get asset metrics breakdown Source: https://tokenterminal.com/docs/api-reference/assets/get-asset-metrics-breakdown /api-reference/openapi.json post /v2/assets/{asset_id}/metrics-breakdown Use this endpoint to retrieve aggregated breakdown data for asset metrics across different dimensions (projects, chains, market sectors, etc.). If an empty `metric_ids` array is provided, it defaults to `['asset_price']`. # Get fact sheet field definitions Source: https://tokenterminal.com/docs/api-reference/assets/get-fact-sheet-field-definitions /api-reference/openapi.json get /v2/fact-sheets/fields Retrieve titles, definitions and option descriptions for public disclosure fields, keyed by field ID. Match a disclosure to `data[field_id]` and its stored option ID to `data[field_id].values[option_id]`. Fetch once and reuse across assets. An empty `values` object means no option metadata is recorded. This endpoint accepts no query parameters and does not include token standard or token permission definitions. The response example is abbreviated; expand the schema to browse all fields and recorded options. # Get historical metrics for an asset Source: https://tokenterminal.com/docs/api-reference/assets/get-historical-metrics-for-an-asset /api-reference/openapi.json get /v2/assets/{asset_id}/metrics Use this endpoint to retrieve historical data for an asset. This endpoint supports partial success - if some of the requested metric, chain, or product IDs are not found, the endpoint will return data for the valid entities and include an `errors` array with details about the invalid ones. # Get reference asset details Source: https://tokenterminal.com/docs/api-reference/assets/get-reference-asset-details /api-reference/openapi.json get /v2/reference-assets/{reference_asset_id} Use this endpoint to retrieve a single reference asset by ID — for example to resolve the `reference_asset_id` returned on an asset from the `/v2/assets` endpoint. # Best practices Source: https://tokenterminal.com/docs/api-reference/best-practices Recommendations on how to best use the API To maximize the effectiveness and efficiency of the API, we recommend following these best practices. By structuring your workflow according to these guidelines, you will ensure that your application or analysis is robust, scalable, and performs optimally. ## Maintain an up-to-date cache of projects and metrics Token Terminal regularly updates the list of supported projects and metrics. To ensure your application or analysis remains current, it is best practice to maintain your own cache or index. We recommend caching the responses from the `/projects` and `/metrics` endpoints. This allows you to quickly reference available projects and supported metrics without making redundant API calls. The responses should be updated periodically based on your needs, ideally daily or weekly, depending on how frequently you expect changes in the data. ```http theme={null} // Get the list of projects GET https://api.tokenterminal.com/v2/projects // Get the list of metrics GET https://api.tokenterminal.com/v2/metrics ``` By caching responses from these endpoints, you can easily reference available projects and supported metrics. ## Utilize metric endpoints for detailed data The most flexible and powerful way to interact with Token Terminal data is via metric endpoints. They allow you to retrieve detailed metrics for specific projects, chains, and time ranges. The following call retrieves revenue metrics for Uniswap and Aave projects on Ethereum between specified dates: ```http theme={null} GET https://api.tokenterminal.com/v2/metrics/revenue?project_ids=uniswap,aave&chain_ids=ethereum&start_date=2025-01-01&end_date=2025-03-01 ``` ## Use breakdown aggregation API for summarized responses Instead of fetching time series data first, and then aggregating it, you can directly request summarized data using the breakdown API. This is particularly useful for reducing the amount of data transferred and speeding up response times. The following call retrieves the revenue breakdown aggregation for Uniswap and Aave projects for the specified date range and applying aggregations like **avg**, **change**, **sum** and **trend**: ```http theme={null} GET https://api.tokenterminal.com/v2/metrics-breakdown/revenue?project_ids=uniswap,aave&start_date=2024-01-01&end_date=2024-03-01 ``` ## Handling errors and missing data Proper error handling ensures your application remains stable even when data is temporarily unavailable or incorrect parameters are provided. Check HTTP response status codes: * **200**: Successful response * **400**: Bad request (invalid parameters) * **404**: Data not found (possibly unsupported project/metric) * **429**: Too many requests (rate limiting) Here's an example of how to handle errors in **Python**: ```python theme={null} import requests import os def fetch_data(): # Get API key and set up headers once before the loop api_key = os.environ.get('TOKEN_TERMINAL_API_KEY', '') headers = { 'Authorization': f'Bearer {api_key}' } current_wait_time = wait_time # Use a local variable for exponential backoff for attempt in range(retry_attempts): response = requests.get( 'https://api.tokenterminal.com/v2/metrics/revenue', headers=headers, params={ 'project_ids': 'uniswap', 'chain_ids': 'ethereum', 'start_date': '2024-01-01', 'end_date': '2024-03-01' } ) # Handle success case if response.status_code == 200: print("Successfully fetched data:") print(response.json()) return # Exit after success # Handle rate limit case if response.status_code == 429: print(f"Rate limited. Waiting for {current_wait_time} seconds.") time.sleep(current_wait_time) current_wait_time *= 2 # exponential backoff else: # For other errors, print message and stop retrying print(f"Unexpected error: {response.status_code}") print(f"Response: {response.text}") return print(f"Failed to fetch data after {retry_attempts} attempts.") if __name__ == "__main__": fetch_data() ``` ## Managing rate limiting Token Terminal implements rate limiting to ensure fair usage. You should handle rate limits gracefully by implementing exponential backoff or retry logic. Rate limit recommendation: Monitor for HTTP 429 responses and implement retry logic. Here's an example of how to handle rate limiting in **Python**: ```python theme={null} import requests import os import time retry_attempts = 3 wait_time = 5 # seconds def fetch_data(): for attempt in range(retry_attempts): # Get API key from environment variable or set directly # For security reasons, it's better to use environment variables api_key = os.environ.get('TOKEN_TERMINAL_API_KEY', '') # Set up headers with API key headers = { 'Authorization': f'Bearer {api_key}' } response = requests.get( 'https://api.tokenterminal.com/v2/metrics/revenue', headers=headers, params={ 'project_ids': 'uniswap', 'chain_ids': 'ethereum', 'start_date': '2024-01-01', 'end_date': '2024-03-01' } ) # Here, just handle the rate limit case if response.status_code == 429: print(f"Rate limited. Waiting for {wait_time} seconds.") time.sleep(wait_time) wait_time *= 2 # exponential backoff else: print(f"Unexpected error: {response.status_code}") print(f"Response: {response.text}") if __name__ == "__main__": fetch_data() ``` # Get the Blockchain comparison dataset Source: https://tokenterminal.com/docs/api-reference/datasets/get-the-blockchain-comparison-dataset /api-reference/openapi.json get /v2/datasets/blockchain_comparison Use this endpoint to retrieve the Blockchain comparison dataset. You can get the whole dataset by omitting all parameters. # Get the Cohort analysis dataset Source: https://tokenterminal.com/docs/api-reference/datasets/get-the-cohort-analysis-dataset /api-reference/openapi.json get /v2/datasets/cohort_analysis Use this endpoint to retrieve the Cohort analysis dataset. You can get the whole dataset by omitting all parameters. # Get the Crypto screener dataset Source: https://tokenterminal.com/docs/api-reference/datasets/get-the-crypto-screener-dataset /api-reference/openapi.json get /v2/datasets/crypto_screener Use this endpoint to retrieve the Crypto screener dataset. You can get the whole dataset by omitting all parameters. Metrics use the following pattern in the response body: `__`. Metric IDs are the same as the ones used in the `/v2/metrics` endpoint. Intervals are `24h`, `7d`, `30d`, `90d`, `180d`, `365d`, `max`. Aggregations are `trend`, `change`, `avg`, `ath`, `atl`. # Get the Insider transactions dataset Source: https://tokenterminal.com/docs/api-reference/datasets/get-the-insider-transactions-dataset /api-reference/openapi.json get /v2/datasets/insider_transactions Use this endpoint to retrieve the Insider transactions dataset. You can get the whole dataset by omitting all parameters. # Get the Project contracts dataset Source: https://tokenterminal.com/docs/api-reference/datasets/get-the-project-contracts-dataset /api-reference/openapi.json get /v2/datasets/project_contracts Use this endpoint to retrieve the Project contracts dataset. You can get the whole dataset by omitting all parameters. # Get the Trending contracts dataset Source: https://tokenterminal.com/docs/api-reference/datasets/get-the-trending-contracts-dataset /api-reference/openapi.json get /v2/datasets/trending_contracts Use this endpoint to retrieve the Trending contracts dataset. You can get the whole dataset by omitting all parameters. # List all datasets Source: https://tokenterminal.com/docs/api-reference/datasets/list-all-datasets /api-reference/openapi.json get /v2/datasets Use this endpoint to list all datasets that are available. # Introduction Source: https://tokenterminal.com/docs/api-reference/introduction Get access to Token Terminal's data via our API ![API hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/api.png?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=d0df8efabb9b5b7d26a3db5aeedafc64) Users on the Token Terminal API plan can query the data with their designated API key, which can be found on their account page. The API key should be kept a secret, so make sure to not share it or store it in publicly accessible areas such as GitHub, client-side code, and so forth. > [!NOTE] > > If you don't have an API key, make sure to upgrade your plan to the API plan in your account billing page. > > If you're interested in talking to our team about using the API, please reach out to us at [sales@tokenterminal.xyz](mailto:sales@tokenterminal.xyz) for assistance. The API is read-only, supports REST calls, uses predictable resource-oriented URLs, and returns JSON-encoded responses and error messages. We use standard HTTP response codes | Code | Explanation | | - | - | | 200 | for success | | 308 | for redirects when e.g. project\_id has been renamed (only when projects make a significant rebranding) | | 400 | for when query parameters are invalid, see included JSON formatted error message for advice | | 402 | for when subscription isn't valid | | 403 | for invalid access | | 429 | for too many requests (rate limit: 1000 requests per minute) | | 500 | if we ever mess up | ## Rate limiting The API has a rate limit of 1000 requests per minute. If you exceed this limit, you will receive a **429** HTTP response code. ## Authentication The API uses HTTP Token Auth to authenticate requests. This means each request must have an Authorization header (your API key). ```bash theme={null} curl -X GET "https://api.tokenterminal.com/v2/projects" \ -H "Authorization: Bearer " ``` # Get a list of all market sectors Source: https://tokenterminal.com/docs/api-reference/market-sectors/get-a-list-of-all-market-sectors /api-reference/openapi.json get /v2/market-sectors Use this endpoint to retrieve a list of all available market sectors that are available on the API. # Get market sector data Source: https://tokenterminal.com/docs/api-reference/market-sectors/get-market-sector-data /api-reference/openapi.json get /v2/market-sectors/{market_sector_id} Use this endpoint to retrieve a market sector metadata and the list of all projects belonging to market sector. # Get a list of all metrics Source: https://tokenterminal.com/docs/api-reference/metrics/get-a-list-of-all-metrics /api-reference/openapi.json get /v2/metrics Use this endpoint to retrieve a list of all metrics available on the API. # Get metric aggregations for multiple projects Source: https://tokenterminal.com/docs/api-reference/metrics/get-metric-aggregations-for-multiple-projects /api-reference/openapi.json get /v2/metric-aggregations Use this endpoint to retrieve metric aggregations for multiple projects. You can get all aggregations for all projects by omitting `project_ids` and `metric_ids` parameters. Fetching all projects or metrics you can omit the parameter or using parameter value `all`. This endpoint supports partial success - if some of the requested project or metric IDs are not found, the endpoint will return data for the valid entities and include an `errors` array with details about the invalid ones. # Get metric breakdown aggregation for multiple projects, chains, or products Source: https://tokenterminal.com/docs/api-reference/metrics/get-metric-breakdown-aggregation-for-multiple-projects-chains-or-products /api-reference/openapi.json post /v2/metric-breakdown Use this endpoint to retrieve metric breakdown aggregation for multiple projects including avg, change, sum, trend, and latest values over a given interval or date range. When looking at cumulative metrics such as fees, reference sums for the total aggregate, and when looking at static metrics such as total value locked, reference latest values for the latest running total. See the response reference below for more details. This endpoint supports partial success - if some of the requested metric, project, chain, or product IDs are not found, the endpoint will return data for the valid entities and include an `errors` array with details about the invalid ones. # Get metric data for multiple projects Source: https://tokenterminal.com/docs/api-reference/metrics/get-metric-data-for-multiple-projects /api-reference/openapi.json get /v2/metrics/{metric_id} Use this endpoint to retrieve metric data for multiple projects. You can get specific metric for all projects by omitting `project_ids` or using `project_ids=all`. This endpoint supports partial success - if some of the requested entities (projects, chains, or products) are invalid or if a metric is not available for a specific project, the endpoint will return data for the valid entities and include an `errors` array with details about the issues. # Get a list of all projects Source: https://tokenterminal.com/docs/api-reference/projects/get-a-list-of-all-projects /api-reference/openapi.json get /v2/projects Use this endpoint to retrieve a list of all projects that are available on the API. # Get details for a specific product of a project Source: https://tokenterminal.com/docs/api-reference/projects/get-details-for-a-specific-product-of-a-project /api-reference/openapi.json get /v2/projects/{project_id}/products/{product_id} Use this endpoint to retrieve detailed information about a specific product within a project. # Get financial statement for a project Source: https://tokenterminal.com/docs/api-reference/projects/get-financial-statement-for-a-project /api-reference/openapi.json get /v2/projects/{project_id}/financial-statement Use this endpoint to retrieve the financial statement report for a project. # Get historical metrics for a project Source: https://tokenterminal.com/docs/api-reference/projects/get-historical-metrics-for-a-project /api-reference/openapi.json get /v2/projects/{project_id}/metrics Use this endpoint to retrieve historical data for a project. Fill in the required fields on the modal to the right. Product breakdowns and product filters support active-user and transaction-participant metrics where product-level aggregates are available. These distinct counts are non-additive: a user active in multiple products is counted in each product but only once in the project total. Do not sum product counts to reconstruct the project total. Aggregate metrics cannot combine product grouping or filtering with chain grouping or filtering. With metric_ids=all, metrics that cannot satisfy the requested dimensions are omitted. This endpoint supports partial success - if some of the requested metric, chain, or product IDs are not found, the endpoint will return data for the valid entities and include an `errors` array with details about the invalid ones. # Get historical metrics for a specific product of a project Source: https://tokenterminal.com/docs/api-reference/projects/get-historical-metrics-for-a-specific-product-of-a-project /api-reference/openapi.json get /v2/projects/{project_id}/products/{product_id}/metrics Use this endpoint to retrieve historical metrics data for a specific product within a project. Active-user and transaction-participant metrics are available where product-level aggregates exist. These distinct counts are non-additive: a user active in multiple products is counted in each product but only once in the project total. Do not sum product counts to reconstruct the project total. Chain grouping and filtering are unsupported for these aggregate product counts. With metric_ids=all, metrics that cannot satisfy the requested dimensions are omitted. This endpoint supports partial success - if some of the requested metric or chain IDs are not found, the endpoint will return data for the valid entities and include an `errors` array with details about the invalid ones. # Get metric aggregations for a project Source: https://tokenterminal.com/docs/api-reference/projects/get-metric-aggregations-for-a-project /api-reference/openapi.json get /v2/projects/{project_id}/metric-aggregations Use this endpoint to retrieve metric aggregation data for one project. # Get metric availability for a project Source: https://tokenterminal.com/docs/api-reference/projects/get-metric-availability-for-a-project /api-reference/openapi.json get /v2/projects/{project_id} Use this endpoint to retrieve the metric availability for a project. # Brand assets Source: https://tokenterminal.com/docs/brand-assets The Token Terminal wordmark and symbol are important expressions of our brand identity. It is vital that they are always applied consistently to create visual harmony and should never be altered or modified. These simple rules will help you use our wordmark and symbol to communicate the Token Terminal brand effectively. > **[Download logo kit](https://tokenterminal.com/static/assets/token_terminal_logo.zip)** > > Download the Token Terminal logo kit, which includes the wordmark, symbol, and other brand assets. ## Token Terminal wordmark Our primary graphic device which should be the first choice when choosing a graphic element to represent the Token Terminal brand. ![Token Terminal wordmark](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/tt-logo-dark.svg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=3a9e9db828e5e2fe691561f6c71e68ac) ![Token Terminal wordmark](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/tt-logo-light.svg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=05cdbda1741d2df5d08818c4eea5cf10) ## Token Terminal symbol The symbol can be used on its own in certain situations when the context and association with Token Terminal is clearly established and controlled. Use with good judgment since the wordmark has stronger brand recognition and is always the preferred way to display Token Terminal. ![Token Terminal symbol](https://mintcdn.com/tokenterminal/3uS2pEH4KO05X9az/images/tt-symbol-light.svg?fit=max\&auto=format\&n=3uS2pEH4KO05X9az\&q=85\&s=81b1019f8001cab1d897e14f2a67c108) ![Token Terminal symbol](https://mintcdn.com/tokenterminal/3uS2pEH4KO05X9az/images/tt-symbol-dark.svg?fit=max\&auto=format\&n=3uS2pEH4KO05X9az\&q=85\&s=10fe6eace0e5e36474b76926734f93e1) # Activity coverage Source: https://tokenterminal.com/docs/catalog/accounts/activity-coverage The share of each chain's daily active senders that are attributed. One row per chain per day. Coverage is reported three ways, by senders, by transactions and by native value, because a low share of addresses can still cover most activity. ## Columns
Column Type Description
`chain_id`STRINGChain the day's senders transacted on.
`activity_date`DATEUTC calendar day the senders are counted for. Partition column. The latest date is partial until the UTC day closes and is rewritten by the next run.
`active_senders`INT64Distinct senders active on the chain that day.
`tx_count`INT64Transactions initiated on the chain that day, across every sender.
`native_value`NUMERICNative value moved on the chain that day, summed across every sender, in the chain's smallest unit. Null on solana, which has no transaction-level native value.
`attributed_senders`INT64Of those, the senders `dimensions.accounts` labels, meaning a non-null `label_source`.
`attributed_share`FLOAT64`attributed_senders` divided by `active_senders`, from `safe_divide`.
`regioned_senders`INT64Of the day's active senders, the ones whose `region_confidence` on [Accounts ▸ Registry](/docs/catalog/accounts/registry) is not null.
`regioned_share`FLOAT64`regioned_senders` divided by `active_senders`, from `safe_divide`.
`regioned_tx_share`FLOAT64Transactions from regioned senders divided by `tx_count`, from `safe_divide`.
`regioned_value_share`FLOAT64Native value from regioned senders divided by `native_value`, from `safe_divide`.
## Sample queries **One chain, one day** `attributed_share` is null rather than a divide error on a day with zero active senders, since the column comes from `safe_divide`. ```sql theme={null} select active_senders, attributed_senders, attributed_share from `reports_accounts.activity_coverage` where chain_id = 'robinhoodchain' and activity_date = date('2026-09-01') ``` **30-day trend for one chain** One row per day already, so a trend is a bounded range with no aggregation. ```sql theme={null} select activity_date, attributed_share from `reports_accounts.activity_coverage` where chain_id = 'robinhoodchain' and activity_date >= date('2026-08-01') and activity_date < date('2026-08-31') order by activity_date ``` **Chain name alongside the share** `chain_id` joins `dimensions.chains` for the display name. ```sql theme={null} select chains.name, coverage.activity_date, coverage.attributed_share from `reports_accounts.activity_coverage` as coverage join `dimensions.chains` as chains using (chain_id) where coverage.activity_date = date('2026-09-01') order by coverage.attributed_share desc ``` **Sender share against value share** `regioned_share` counts senders and `regioned_value_share` counts native value moved; a chain can show a low sender share here while still covering most of the day's value. ```sql theme={null} select chain_id, activity_date, regioned_share, regioned_value_share from `reports_accounts.activity_coverage` where activity_date = date('2026-09-01') order by regioned_value_share desc ``` # Activity hours Source: https://tokenterminal.com/docs/catalog/accounts/activity-hours Transactions an address initiated, by chain and hour of day in UTC. One row per address, chain, date and hour with at least one transaction. `native_value` sums the native value the address's transactions moved in that hour, in the chain's smallest unit; it is null on solana, where native value is not tracked per transaction. ## Columns
Column Type Description
`address`STRINGAddress that initiated the transactions: lowercase hex on `ethereum`, `base` and `robinhoodchain`, base58 and case-sensitive on `solana`.
`chain_id`STRINGChain the address transacted on.
`chain_family`STRINGChain family the chain belongs to: `evm` or `svm`; joins `dimensions.chains`.
`activity_date`DATEUTC calendar date of the hour. Partition column. Full history per chain from its first standardized block. The latest date is partial until the UTC day closes and is rewritten by the next run.
`hour_utc`INT64Hour of day, 0 through 23, UTC.
`tx_count`INT64Transactions the address initiated in that hour, whether or not the address is attributed. Rows on the evm chains include reverted transactions; solana rows are successful, non-vote transactions only.
`native_value`NUMERICNative value the address's transactions moved in that hour, summed, in the chain's smallest unit (wei on the evm chains). Null on solana, which has no transaction-level native value.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `activity_date` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One address, one day** Pivots the day's rows into one, `hour_utc` becoming 24 columns. `tx_count` is 0 for an hour with no transactions. ```sql theme={null} select address, activity_date, sum(if(hour_utc = 0, tx_count, 0)) as hour_00, sum(if(hour_utc = 1, tx_count, 0)) as hour_01, sum(if(hour_utc = 2, tx_count, 0)) as hour_02, sum(if(hour_utc = 3, tx_count, 0)) as hour_03, sum(if(hour_utc = 4, tx_count, 0)) as hour_04, sum(if(hour_utc = 5, tx_count, 0)) as hour_05, sum(if(hour_utc = 6, tx_count, 0)) as hour_06, sum(if(hour_utc = 7, tx_count, 0)) as hour_07, sum(if(hour_utc = 8, tx_count, 0)) as hour_08, sum(if(hour_utc = 9, tx_count, 0)) as hour_09, sum(if(hour_utc = 10, tx_count, 0)) as hour_10, sum(if(hour_utc = 11, tx_count, 0)) as hour_11, sum(if(hour_utc = 12, tx_count, 0)) as hour_12, sum(if(hour_utc = 13, tx_count, 0)) as hour_13, sum(if(hour_utc = 14, tx_count, 0)) as hour_14, sum(if(hour_utc = 15, tx_count, 0)) as hour_15, sum(if(hour_utc = 16, tx_count, 0)) as hour_16, sum(if(hour_utc = 17, tx_count, 0)) as hour_17, sum(if(hour_utc = 18, tx_count, 0)) as hour_18, sum(if(hour_utc = 19, tx_count, 0)) as hour_19, sum(if(hour_utc = 20, tx_count, 0)) as hour_20, sum(if(hour_utc = 21, tx_count, 0)) as hour_21, sum(if(hour_utc = 22, tx_count, 0)) as hour_22, sum(if(hour_utc = 23, tx_count, 0)) as hour_23 from `facts_accounts.activity_hours` where address = '0x0000000000000000000000000000000000000000' and chain_id = 'robinhoodchain' and activity_date = date('2026-09-01') group by address, activity_date ``` **Busiest hour over a month** `chain_id` and a bounded `activity_date` range keep the scan to one chain and one month; `hour_utc` groups every address together. ```sql theme={null} select hour_utc, sum(tx_count) as tx_count from `facts_accounts.activity_hours` where chain_id = 'robinhoodchain' and activity_date >= date('2026-08-01') and activity_date < date('2026-09-01') group by hour_utc order by hour_utc ``` **Attributed senders, one day** Joining `dimensions.accounts` on `address` and `chain_id` and keeping the rows with a `label_source` narrows the hours to addresses somebody has attributed. ```sql theme={null} select hours.address, hours.hour_utc, sum(hours.tx_count) as tx_count from `facts_accounts.activity_hours` as hours join `dimensions.accounts` as accounts on hours.address = accounts.address and hours.chain_id = accounts.chain_id where accounts.label_source is not null and hours.chain_id = 'robinhoodchain' and hours.activity_date = date('2026-09-01') group by hours.address, hours.hour_utc order by hours.address, hours.hour_utc ``` **One address, two chains** The same address key on two evm chains lets you line up its hour-of-day profile on each side by side. ```sql theme={null} select chain_id, hour_utc, sum(tx_count) as tx_count from `facts_accounts.activity_hours` where address = '0x0000000000000000000000000000000000000000' and chain_id in ('ethereum', 'base') and activity_date >= date('2026-08-01') and activity_date < date('2026-09-01') group by chain_id, hour_utc order by chain_id, hour_utc ``` # Attested country Source: https://tokenterminal.com/docs/catalog/accounts/attested-country The country of residence Coinbase attested for a wallet, and the attestation it comes from. One row per wallet holding a live Coinbase Verified Country attestation: the country of residence Coinbase recorded when it verified the holder. The attestation is issued on Base, opt-in and revocable, and revoked or expired attestations are dropped. ## Columns
Column Type Description
`address`STRINGThe wallet the attestation was issued to, lowercase. The key this table is clustered on.
`chain_family`STRINGAlways `evm`: the country applies to the address on every EVM chain, so join on `address` and the chain's `chain_family` from [Chains ▸ Registry](/docs/catalog/chains/registry).
`attested_chain_id`STRINGChain the attestation was issued on, always `base`.
`attested_country`STRINGISO 3166-1 alpha-2 country of residence recorded in the attestation.
`attested_at`TIMESTAMPTimestamp the attestation was issued. A wallet with several live attestations keeps the latest.
`attestation_uid`STRINGUnique id of the attestation.
`attester`STRINGAddress of the issuer, lowercase.
## Sample queries > [!WARNING] > > The table is clustered on `address`, one row per wallet. Filter on the address where you have it; a query that filters on anything else reads the whole table. **One wallet's attested country** `address` is the cluster key, so filtering it is the cheapest lookup. ```sql theme={null} select attested_country, attested_at from `facts_accounts.attested_country` where address = '0x0000000000000000000000000000000000000001' ``` **Attested wallets by country** Wallets per country of residence. ```sql theme={null} select attested_country, count(*) as wallets from `facts_accounts.attested_country` group by attested_country order by wallets desc limit 20 ``` **Attested country by funding venue** A wallet joins on `address` and the chain's `chain_family`, which reaches its funded rows on every EVM chain. `dimensions.chains` maps each `chain_id` to its `chain_family`. ```sql theme={null} select funding.funding_venue_project_id, attested.attested_country, count(*) as wallets from `facts_accounts.funding` as funding join `dimensions.chains` as chains on funding.chain_id = chains.chain_id join `facts_accounts.attested_country` as attested on funding.address = attested.address and chains.chain_family = attested.chain_family where funding.chain_id = 'ethereum' and funding.funding_venue_project_id is not null group by funding.funding_venue_project_id, attested.attested_country order by wallets desc limit 20 ``` # Funding Source: https://tokenterminal.com/docs/catalog/accounts/funding The venue that funded a wallet, its type, and a confidence tier for the tag. One row per wallet with at least one funding edge, attributed to a project or not. `funding_venue_project_id` is null wherever a wallet's edges split across venues too evenly to name one. ## Columns
Column Type Description
`account_id`STRINGAccount as one key: `{address}-{chain_id}`. The key this table is clustered on.
`chain_id`STRINGChain the wallet is on.
`address`STRINGThe wallet: lowercase on EVM, verbatim base58 on Solana.
`funding_venue_project_id`STRINGVenue that funded the wallet: the earliest edge's venue, from [Accounts ▸ Registry](/docs/catalog/accounts/registry)'s Venues tab. Null when the wallet's edges split across venues.
`funding_venue_type`STRING`cex` or `fiat-ramps`, from Venues. Null iff `funding_venue_project_id` is null.
`funding_venue_source`STRING`curated` for an edge to a registry anchor, `detected` for an edge through a detected deposit address. Null iff `funding_venue_project_id` is null.
`funding_confidence`STRING`high`, `medium` or `low`, from the tiers described on [Accounts ▸ Registry](/docs/catalog/accounts/registry). Null iff `funding_venue_project_id` is null.
`funding_evidence_edges`INT64First-contact edges behind the row.
`funding_distinct_venues`INT64Venues the wallet has edges with.
`funding_first_edge_at`TIMESTAMPTimestamp of the wallet's earliest funding edge.
`funding_jurisdiction`STRINGISO 3166-1 alpha-2 of the venue, from Venues. Null unless the venue passes the jurisdiction gate there.
`wallet_set_version`INT64Fingerprint of the venue's anchor set the row was computed under. Null iff `funding_venue_project_id` is null.
## Sample queries > [!WARNING] > > The table is clustered on `account_id`, one row per wallet. Filter on the account where you have it, or on `chain_id` otherwise; a query that filters on neither reads the whole table. **One wallet's funding tag** `account_id` is the address and the chain joined by a hyphen, and the column this table is clustered on, so filtering it is the cheapest lookup. ```sql theme={null} select funding_venue_project_id, funding_venue_type, funding_confidence, funding_jurisdiction, funding_first_edge_at from `facts_accounts.funding` where account_id = '0x7240234c7bf954cd7fc6323c38bbf6e6e4355e52-ethereum' ``` **Wallets by venue and confidence, on one chain** `chain_id` is not the cluster key, so bound the column list too: selecting only the columns a query needs keeps a chain-wide scan affordable. ```sql theme={null} select funding_venue_project_id, funding_confidence, count(*) as wallets from `facts_accounts.funding` where chain_id = 'ethereum' and funding_venue_project_id is not null group by funding_venue_project_id, funding_confidence order by wallets desc limit 20 ``` **High-confidence wallets by venue, with jurisdiction** `funding_venue_project_id` joins `dimensions.venues` for the venue's display name and jurisdiction. ```sql theme={null} select venues.name, venues.venue_type, venues.funding_jurisdiction, count(*) as wallets from `facts_accounts.funding` as funding join `dimensions.venues` as venues on funding.funding_venue_project_id = venues.venue_project_id where funding.chain_id = 'ethereum' and funding.funding_confidence = 'high' group by venues.name, venues.venue_type, venues.funding_jurisdiction order by wallets desc ``` # Funding coverage Source: https://tokenterminal.com/docs/catalog/accounts/funding-coverage The share of each chain's funded wallets that resolve to a venue, by confidence tier. One row per chain, over the whole of [Funding](/docs/catalog/accounts/funding). `resolved_share` is `wallets_resolved` divided by `wallets_with_edges`. ## Columns
Column Type Description
`chain_id`STRINGChain the wallets are on.
`wallets_with_edges`INT64Rows in [Funding](/docs/catalog/accounts/funding) for this chain.
`wallets_resolved`INT64Of those, `funding_venue_project_id` is not null.
`resolved_share`FLOAT64`wallets_resolved` divided by `wallets_with_edges`.
`wallets_high`INT64Resolved wallets at `high` confidence.
`wallets_medium`INT64Resolved wallets at `medium` confidence.
`wallets_low`INT64Resolved wallets at `low` confidence.
`wallets_curated_source`INT64Resolved wallets whose `funding_venue_source` is `curated`.
`wallets_detected_source`INT64Resolved wallets whose `funding_venue_source` is `detected`.
`wallets_with_jurisdiction`INT64Resolved wallets with a `funding_jurisdiction`.
`jurisdiction_share`FLOAT64`wallets_with_jurisdiction` divided by `wallets_resolved`.
`distinct_venues`INT64Distinct `funding_venue_project_id` values on this chain.
`first_edge_at`TIMESTAMPEarliest `funding_first_edge_at` on this chain.
`last_edge_at`TIMESTAMPLatest `funding_first_edge_at` on this chain.
## Sample queries **One chain's coverage** `resolved_share` and `jurisdiction_share` read together show how much of a chain's funded wallets resolve to a venue, and how much of that group also resolves to a country. ```sql theme={null} select wallets_with_edges, wallets_resolved, resolved_share, wallets_with_jurisdiction, jurisdiction_share from `reports_accounts.funding_coverage` where chain_id = 'ethereum' ``` **Every chain, ranked by resolved share** One row per covered chain, so ranking them needs no aggregation. ```sql theme={null} select chain_id, resolved_share, distinct_venues from `reports_accounts.funding_coverage` order by resolved_share desc ``` **Chain name alongside the coverage** `chain_id` joins `dimensions.chains` for the display name. ```sql theme={null} select chains.name, coverage.resolved_share, coverage.wallets_high, coverage.wallets_medium, coverage.wallets_low from `reports_accounts.funding_coverage` as coverage join `dimensions.chains` as chains using (chain_id) order by coverage.resolved_share desc ``` # Funding hit rate Source: https://tokenterminal.com/docs/catalog/accounts/funding-hit-rate Curated deposit anchors against detected deposit addresses, per venue and chain. One row per venue and chain, comparing its curated deposit anchors against the deposit addresses detected from wallet behavior. `curated_hit_rate` is `curated_also_detected` divided by `curated_deposit_wallets`, null where `curated_deposit_wallets` is zero. ## Columns
Column Type Description
`venue_project_id`STRINGVenue the wallets are compared for.
`chain_id`STRINGChain the wallets are on.
`curated_deposit_wallets`INT64Venue's curated deposit anchors on this chain.
`detected_deposit_addresses`INT64Distinct counterparty addresses this venue's edges detected as deposit addresses on this chain.
`curated_also_detected`INT64Curated deposit anchors that also appear as a detected counterparty.
`curated_hit_rate`FLOAT64`curated_also_detected` divided by `curated_deposit_wallets`. Null where `curated_deposit_wallets` is zero.
## Sample queries **One venue's hit rate by chain** A high `curated_hit_rate` on a chain means the detector is rediscovering the same anchors the registry already curated there. ```sql theme={null} select chain_id, curated_deposit_wallets, detected_deposit_addresses, curated_hit_rate from `reports_accounts.funding_hit_rate` where venue_project_id = 'coinbase' order by chain_id ``` **Every venue and chain, ranked by hit rate** Filtering `curated_deposit_wallets > 0` drops the pairs `curated_hit_rate` is null for. ```sql theme={null} select venue_project_id, chain_id, curated_deposit_wallets, curated_hit_rate from `reports_accounts.funding_hit_rate` where curated_deposit_wallets > 0 order by curated_hit_rate desc limit 50 ``` **Venue name alongside the hit rate** `venue_project_id` joins `dimensions.projects` for the display name. ```sql theme={null} select projects.name, rate.chain_id, rate.curated_deposit_wallets, rate.curated_hit_rate from `reports_accounts.funding_hit_rate` as rate join `dimensions.projects` as projects on rate.venue_project_id = projects.project_id where rate.curated_deposit_wallets > 0 order by rate.curated_hit_rate desc limit 50 ``` # Funding region agreement Source: https://tokenterminal.com/docs/catalog/accounts/funding-region-agreement How often a wallet's region of activity matches its funding venue's expected band. One row per funding venue, chain, funding confidence and region confidence, for wallets that venue funded. `hit_rate` is `hits` divided by `wallets_with_region`, null where the venue's expected band is not known. ## Columns
Column Type Description
`funding_venue_project_id`STRINGVenue that funded the wallets in this row.
`chain_id`STRINGChain the wallets are on.
`chain_family`STRINGChain family the chain belongs to, from `dimensions.chains`.
`funding_confidence`STRING`high`, `medium` or `low`, the wallets' funding confidence tier.
`region_confidence`STRING`high`, `medium` or `low`, or null where region has no signal.
`wallets`INT64Wallets funded by this venue, on this chain, at this funding confidence tier.
`wallets_with_region`INT64Of those, wallets with a non-null region.
`expected_band`STRINGRegion band this venue is expected to fall in. Null where the expectation is not known for this venue and chain family.
`hits`INT64Of `wallets_with_region`, wallets whose region matched `expected_band`.
`hit_rate`FLOAT64`hits` divided by `wallets_with_region`. Null where `expected_band` is null.
## Sample queries **One venue's hit rate by chain** `hit_rate` compares a venue's wallets against its own expected band, so filtering to one venue reads how consistent it is across chains and confidence tiers. ```sql theme={null} select chain_id, funding_confidence, region_confidence, wallets_with_region, hit_rate from `reports_accounts.funding_region_agreement` where funding_venue_project_id = 'coinbase' order by chain_id, funding_confidence ``` **Hit rate across every venue, at high confidence** Summing `hits` and `wallets_with_region` before dividing avoids averaging an average across venues of very different sizes. ```sql theme={null} select funding_venue_project_id, sum(hits) as hits, sum(wallets_with_region) as wallets_with_region, safe_divide(sum(hits), sum(wallets_with_region)) as hit_rate from `reports_accounts.funding_region_agreement` where funding_confidence = 'high' and expected_band is not null group by funding_venue_project_id order by hit_rate desc ``` **Venue name alongside the hit rate** `funding_venue_project_id` joins `dimensions.projects` for the display name. ```sql theme={null} select projects.name, agreement.chain_id, agreement.funding_confidence, agreement.hit_rate from `reports_accounts.funding_region_agreement` as agreement join `dimensions.projects` as projects on agreement.funding_venue_project_id = projects.project_id where agreement.expected_band is not null order by agreement.hit_rate desc limit 50 ``` # Funding venue distribution Source: https://tokenterminal.com/docs/catalog/accounts/funding-venue-distribution Funded wallets by venue and confidence tier, per chain. One row per chain, venue and confidence tier, including the null venue and null confidence row for wallets that resolve to no venue. `wallet_share` is `wallets` divided by the chain's total rows in [Funding](/docs/catalog/accounts/funding). ## Columns
Column Type Description
`chain_id`STRINGChain the wallets are on.
`funding_venue_project_id`STRINGVenue the wallets resolve to. Null for the unresolved row.
`funding_venue_type`STRING`cex` or `fiat-ramps`, from [Accounts ▸ Registry](/docs/catalog/accounts/registry)'s Venues tab. Null for the unresolved row.
`funding_jurisdiction`STRINGISO 3166-1 alpha-2 of the venue. Null unless the venue passes the jurisdiction gate.
`funding_confidence`STRING`high`, `medium` or `low`. Null for the unresolved row.
`wallets`INT64Wallets on this chain at this venue and confidence tier.
`wallet_share`FLOAT64`wallets` divided by the chain's total rows in [Funding](/docs/catalog/accounts/funding).
`first_edge_at`TIMESTAMPEarliest `funding_first_edge_at` in the group.
`last_edge_at`TIMESTAMPLatest `funding_first_edge_at` in the group.
## Sample queries **One chain's venue breakdown** The unresolved row has a null `funding_venue_project_id`, so `wallet_share` still sums to 1 across every row for the chain. ```sql theme={null} select funding_venue_project_id, funding_confidence, wallets, wallet_share from `reports_accounts.funding_venue_distribution` where chain_id = 'ethereum' order by wallets desc ``` **Top venues across every chain, at high confidence** Summing `wallets` before ranking avoids letting one chain's larger wallet count dominate the order. ```sql theme={null} select funding_venue_project_id, sum(wallets) as wallets from `reports_accounts.funding_venue_distribution` where funding_confidence = 'high' group by funding_venue_project_id order by wallets desc limit 20 ``` **Venue name alongside the distribution** `funding_venue_project_id` joins `dimensions.projects` for the display name. ```sql theme={null} select projects.name, dist.chain_id, dist.funding_confidence, dist.wallets from `reports_accounts.funding_venue_distribution` as dist join `dimensions.projects` as projects on dist.funding_venue_project_id = projects.project_id where dist.chain_id = 'ethereum' order by dist.wallets desc ``` # Accounts Source: https://tokenterminal.com/docs/catalog/accounts/index Addresses on chains: wallets and contracts, and where they appear. An account is an address on a chain, a wallet or a contract: * Uniswap's `Factory` on `ethereum`, `0x1f98431c8ad98523631ae4a59f267346ea31f984` * the `USDC-WETH pool` it deployed, `0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640` [Registry](/docs/catalog/accounts/registry) gives an address its type, its project and its label where somebody has attributed it, and the region, funding venue and attested country held for it. Addresses appear as columns on the other sections: `from_address` and `to_address` on [transfers](/docs/catalog/tokens/transfers), `account_address` in the [balance functions](/docs/catalog/tokens/balances), `sender_address` on the [sender table](/docs/catalog/assets/senders). Where an account is a contract, [Contracts](/docs/catalog/contracts/index) has its deployment, and the two registries join on `account_id`. ## Coverage Every chain we label accounts on. `alephzeroevm` `algorand` `aptos` `arbitrum` `avalanche` `base` `berachain` `bitcoin` `blast` `bob` `bobanetwork` `bsc` `cardano` `celo` `citrea` `ethereum` `fantom` `flow` `flowevm` `fraxtal` `gnosis` `gravityalpha` `hedera` `hederaevm` `hyperevm` `immutablezkevm` `injective` `injectiveevm` `ink` `iota` `iotex` `katananetwork` `linea` `manta` `mantraevm` `megaeth` `monad` `movement` `near` `opbnb` `optimism` `osmosis` `plasma` `polygon` `ripple` `robinhoodchain` `ronin` `rootstock` `scroll` `seievm` `solana` `sonic` `stacks` `starknet` `stellar` `sui` `tempo` `terra` `ton` `tron` `unichain` `viction` `worldchain` `xai` `xdc` `xlayer` `zksyncera` ## Tables [Registry](/docs/catalog/accounts/registry) holds the identity table: one row per attributed address, with the chain it sits on, the project behind it, its type and its label. [Activity hours](/docs/catalog/accounts/activity-hours) holds the transaction counts and native value behind `region`, by address, chain, date and hour. [Activity coverage](/docs/catalog/accounts/activity-coverage) holds the share of each chain's daily activity that is attributed and regioned, by sender, transaction and value. [Region distribution](/docs/catalog/accounts/region-distribution) holds region as a distribution, by chain, trailing 90-day window, region and confidence, across every sender on the chain, attributed or not: the only per-address-free view for region. [Region hit rate](/docs/catalog/accounts/region-hit-rate) holds how often the derived region matches the expected band for attributed accounts whose band is known in advance. Registry's Venues tab, [Funding](/docs/catalog/accounts/funding) and [Venue edges](/docs/catalog/accounts/venue-edges) hold the venue a wallet was funded from: the venue's identity and jurisdiction gate, the tag itself keyed on `account_id` regardless of attribution, and the funding edges the tag is built from. [Funding coverage](/docs/catalog/accounts/funding-coverage) and [funding venue distribution](/docs/catalog/accounts/funding-venue-distribution) hold the same shape for funding that region distribution holds for region: the share of each chain's wallets that resolve to a venue, and those wallets broken out by venue and confidence tier. [Funding region agreement](/docs/catalog/accounts/funding-region-agreement) holds how often a wallet's region of activity matches its funding venue's expected band, and [funding hit rate](/docs/catalog/accounts/funding-hit-rate) holds how often a venue's curated deposit anchors also appear as detected deposit addresses. [Attested country](/docs/catalog/accounts/attested-country) holds the country of residence Coinbase attested for a wallet, by address and chain family, for the holders who opted in. # Region distribution Source: https://tokenterminal.com/docs/catalog/accounts/region-distribution Senders by region and confidence, a trailing 90-day snapshot per chain. One row per chain, trailing 90-day window ending `window_end`, region and confidence tier. `senders` counts every address in that band over the window, including the region `null` at a null confidence. ## Columns
Column Type Description
`chain_id`STRINGChain the senders transacted on.
`window_end`DATELast UTC day of the trailing 90-day window the row summarizes. Partition column.
`region`STRINGOne of seven UTC-offset bands: `utc-11..-9`, `utc-8..-5`, `utc-4..-2`, `utc-1..+2`, `utc+3..+6`, `utc+7..+9`, `utc+10..+12`. Null when `region_confidence` is null.
`region_confidence`STRING`high`, `medium` or `low`, from the same thresholds as [Accounts ▸ Registry](/docs/catalog/accounts/registry)'s `region_confidence`, and null where `region` is null.
`senders`INT64Senders on that chain, in that window, region and confidence tier.
`tx_count`INT64Transactions those senders initiated over the window.
`sender_share`FLOAT64`senders` divided by the window's total senders on the chain, from `safe_divide`.
`tx_share`FLOAT64`tx_count` divided by the window's total transactions on the chain, from `safe_divide`.
## Sample queries **One chain's latest snapshot** Each row is one region and confidence pair for the window ending `window_end`; the `null` region at a null confidence is the share with no signal. ```sql theme={null} select region, region_confidence, senders, sender_share from `reports_accounts.region_distribution` where chain_id = 'ethereum' and window_end = date('2026-09-01') order by senders desc ``` **Regioned share of a chain's transactions** Summing `tx_share` across every non-null confidence tier gives the share of the chain's transactions from senders with any region signal, whether or not they are attributed to a project. ```sql theme={null} select chain_id, sum(tx_share) as regioned_tx_share from `reports_accounts.region_distribution` where window_end = date('2026-09-01') and region_confidence is not null group by chain_id order by regioned_tx_share desc ``` **Chain name alongside the distribution** `chain_id` joins `dimensions.chains` for the display name. ```sql theme={null} select chains.name, dist.region, dist.region_confidence, dist.senders from `reports_accounts.region_distribution` as dist join `dimensions.chains` as chains using (chain_id) where dist.window_end = date('2026-09-01') and dist.chain_id = 'solana' order by dist.senders desc ``` # Region hit rate Source: https://tokenterminal.com/docs/catalog/accounts/region-hit-rate Region accuracy for attributed accounts whose band is known in advance. One row per project, chain family, expected region and confidence tier. `hit_rate` is `hits` divided by `accounts`, the share of that project's accounts on that chain family whose derived `region` matched `expected_band`. Every combination is reported regardless of size, but the automated modal-band check behind this table only asserts on a (project, chain family) pair once it has at least five accounts with a resolved region band -- below that, the pair passes vacuously rather than being judged on too little evidence. ## Columns
Column Type Description
`project_id`STRINGProject the accounts are attributed to, such as an exchange running hot wallets.
`chain_family`STRING`evm` or `svm`; joins `dimensions.chains`.
`expected_band`STRINGRegion band the account is expected to fall in, known in advance rather than derived from activity. One of the same seven UTC-offset bands as [Accounts ▸ Registry](/docs/catalog/accounts/registry)'s `region`.
`region_confidence`STRING`high`, `medium` or `low`, or null when no tier was met, the confidence tier the row's accounts were measured at.
`accounts`INT64Attributed accounts for that project, chain family and confidence tier with a known expected band.
`hits`INT64Of those, the accounts whose derived `region` matched `expected_band`.
`hit_rate`FLOAT64`hits` divided by `accounts`, from `safe_divide`.
## Sample queries **One project's hit rate by confidence** Filtering to one `project_id` shows whether the hit rate rises with `region_confidence`, the pattern the tier thresholds are meant to produce. ```sql theme={null} select chain_family, region_confidence, accounts, hits, hit_rate from `reports_accounts.region_hit_rate` where project_id = 'coinbase' order by region_confidence ``` **Hit rate across every project, at high confidence** Summing `hits` and `accounts` before dividing avoids averaging an average across projects of very different sizes. ```sql theme={null} select project_id, sum(hits) as hits, sum(accounts) as accounts, safe_divide(sum(hits), sum(accounts)) as hit_rate from `reports_accounts.region_hit_rate` where region_confidence = 'high' group by project_id order by hit_rate desc ``` **Project name alongside the hit rate** `project_id` joins `dimensions.projects` for the display name. ```sql theme={null} select projects.name, rate.chain_family, rate.region_confidence, rate.hit_rate from `reports_accounts.region_hit_rate` as rate join `dimensions.projects` as projects using (project_id) where rate.region_confidence = 'high' order by rate.hit_rate desc limit 50 ``` # Registry Source: https://tokenterminal.com/docs/catalog/accounts/registry Address, type and label for every account. The identity table behind an address: the chain it sits on and, where somebody has attributed it, the project that runs it, its type and its label, next to the region, funding and attested country held for it. [Accounts](/docs/catalog/accounts/index) introduces the grain, and [Contracts](/docs/catalog/contracts/registry) has the deployment behind a contract account. We publish where a wallet is active, where it was funded and, for holders who opted in, the country Coinbase attested for it. Region of activity, unchanged from v1, is a UTC-offset band derived from public transaction timing. Funding source is new. Where we can trace a wallet's incoming transfers to an exchange, custodian, or fiat ramp, we publish which venue funded it, the venue's type, whether that venue address was curated by a person or detected from wallet behavior, a confidence tier of high, medium, or low, how many funding transactions back the tag, and when the funding relationship was first observed. Funding jurisdiction is the country the venue that funded the wallet is registered in and serves, published only where the venue serves a single country. A wallet funded through a regional or global exchange gets a null jurisdiction, because that value describes the venue, not the person who holds the wallet. Neither region nor funding reads a partner's KYC records, and no country is derived from how or when an address transacts, only from where the venue that funded it is registered. Attested country is different in kind: it is the country of residence Coinbase recorded when it verified the account holder, issued as an opt-in attestation the holder can revoke, and we republish it as issued without deriving anything from it. Region is a property of the address key across its whole `chain_family`, not of one chain, and its evidence comes only from the chains [activity hours](/docs/catalog/accounts/activity-hours) covers: `ethereum`, `base`, `robinhoodchain` and `solana`. No country is ever derived from region: a country comes only from a funding venue's registration, gated to venues that serve a single country, or from an attestation. Every confidence tier describes the strength of one signal, the address's daily rhythm. Region and funding are published per `account_id` for every row, attributed or not, and the [region distribution](/docs/catalog/accounts/region-distribution) report holds region as a distribution across every sender on the chain. `region` is derived from [activity hours](/docs/catalog/accounts/activity-hours): 1. Sum the address's hourly transaction counts over the trailing 90 complete UTC days, across every chain in its `chain_family`; `n` is the total. Addresses with `n` below 300 get a null `region_confidence`. 2. The trough is the 6-hour window with the smallest share of `n`; its centre hour is `t`. The UTC offset is `round(3.5 - t)`, wrapped to -11..+12, taking 03:30 as the local sleep centre. 3. The band is the one of seven that contains the offset. 4. Depth `d` = `1 - (trough share / 0.25)`; night share is the share in the 12 hours centred on the trough. 5. `high` needs `n >= 3000`, `d >= 0.70`, night `<= 0.25`; `medium` needs `n >= 1000`, `d >= 0.50`, night `<= 0.30`; `low` needs `n >= 300`, `d >= 0.30`, night `<= 0.35`; otherwise `region` and `region_confidence` are null. A second trough within 10% of the first caps confidence at `low`. An address has a `region` once its trailing activity clears the evidence floor. On a labelled row that describes where a venue or operator runs, and on an unlabelled wallet where that wallet is active. A global venue's wallets move on its users' hours across every band, so its `region` reflects where its users are, aggregated, and its `region_confidence` often stays null. The hit rate is read against venues whose operations sit in one band. [Activity coverage](/docs/catalog/accounts/activity-coverage) publishes the share of each day's active senders that are attributed. `funding_venue_project_id` on [Funding](/docs/catalog/accounts/funding) is derived from [venue edges](/docs/catalog/accounts/venue-edges): the venue is the earliest edge's venue, and a wallet whose edges split evenly across venues gets a null venue instead. Confidence is set by how many venues a wallet has edges with, and how those edges were found. `high` is one venue, funded through a curated deposit anchor. `medium` is one venue funded through a detected deposit address only, or two venues where the earliest edge was curated. `low` is two venues where the earliest edge was detected. Three or more venues, or two of comparable weight, get a null tier. `funding_jurisdiction` on Venues is set only where a venue clears three facts together: its `operating_scope` is `single_country`, its `onboarding_scope` is `residents_only`, and its licence countries and entity countries agree on that one country, with no licence row and no funding wallet left without a country. `gate_reason` on Venues names which of the three failed, or `qualifies`. ## Tables **Accounts** One row per address the label registry attributes or any accounts fact holds a row for. The label columns are null where nobody has attributed the address. Join on `account_id`, or on `address` and `chain_id`; `attested_country` fills on every EVM chain of an attested address.
Column Type Description
`account_id` `STRING` Account as one key: `{address}-{chain_id}`. The key that joins `dimensions.contracts` and `dimensions.tokens` directly.
`chain_id` `STRING` Chain the address is on. The same address on two chains is two different accounts, so an address identifies a row only with this beside it.
`address` `STRING` The address, spelled the way its chain spells it: lowercase on EVM and Starknet, base58 and case-sensitive on Solana and Tron. Lowercase an EVM address copied from an explorer before matching it here; the [balance functions](/docs/catalog/tokens/balances) lowercase the address they are handed.
`project_id` `STRING` Project the address is attributed to. Joins `dimensions.projects` for the name and market sector.
`contract_name` `STRING` Label for the address as the attributing project names it, such as `Factory` or `USDC-WETH pool`.
`account_type` `STRING` `eoa` or `smartcontract`, and null where nobody has determined it, so test it with `is null` rather than `= ''`. Says nothing about whether the owner holds the address custodially.
`parent_address` `STRING` For a factory-emitted address, the factory that emitted it.
`label_source` `STRING` `curated` for an attribution a person authored, `factory_derived` for an address a known factory emitted. Null where nobody has attributed the address. Of the attributed rows most are factory derived; filter to `curated` for the addresses someone has looked at.
`region` `STRING` One of seven UTC-offset bands: `utc-11..-9`, `utc-8..-5`, `utc-4..-2`, `utc-1..+2`, `utc+3..+6`, `utc+7..+9`, `utc+10..+12`. Null when `region_confidence` is null.
`region_confidence` `STRING` `high`, `medium` or `low`, from the thresholds behind `region`, and null where `region` is null.
`region_evidence_txs` `INT64` Transactions behind the band: `n`, the trailing 90-day total the `region` calculation summed across the address's chain family.
`funding_venue_project_id` `STRING` Venue that funded the account, from [Funding](/docs/catalog/accounts/funding). Null where the account has no funding edge, or where its edges split across venues.
`funding_venue_type` `STRING` `cex` or `fiat-ramps`, from the Venues tab above. Null iff `funding_venue_project_id` is null.
`funding_venue_source` `STRING` `curated` for an edge to a registry anchor, `detected` for an edge through a detected deposit address. Null iff `funding_venue_project_id` is null.
`funding_confidence` `STRING` `high`, `medium` or `low`, from the same tiers as [Funding](/docs/catalog/accounts/funding). Null iff `funding_venue_project_id` is null.
`funding_evidence_edges` `INT64` First-contact edges behind the tag. `0` where the account has no funding row, like `region_evidence_txs`.
`funding_first_edge_at` `TIMESTAMP` Earliest funding edge, from [Funding](/docs/catalog/accounts/funding). Null where the account has no funding row.
`funding_jurisdiction` `STRING` ISO 3166-1 alpha-2 of the funding venue, from the Venues tab above. Null unless the venue passes the jurisdiction gate.
`attested_country` `STRING` ISO 3166-1 alpha-2 country of residence Coinbase attested for the address, from [Attested country](/docs/catalog/accounts/attested-country). Filled on every row whose chain is EVM, since the attestation applies to the address on every EVM chain, and null elsewhere and where the holder has no live attestation.
`attested_at` `TIMESTAMP` Timestamp the attestation was issued. Null iff `attested_country` is null.
**Venues** One row per project tagged as a venue a wallet can be funded from: an exchange, a custodian or a fiat ramp. `funding_jurisdiction` is set only where the venue passes the jurisdiction gate above.
Column Type Description
`venue_project_id` `STRING` The venue, as a `dimensions.projects` key.
`name` `STRING` Venue's display name.
`venue_type` `STRING` `cex` or `fiat-ramps`, read from the venue's registry tags.
`legal_entity_name` `STRING` The venue's authored operating legal entity name.
`legal_domicile` `STRING` ISO 3166-1 alpha-2 of the legal entity's domicile, as authored.
`operating_scope` `STRING` The venue's authored operating footprint: `single_country`, `regional` or `global`. Null where the registry has not recorded it. `single_country` is one of the three facts the jurisdiction gate above requires.
`onboarding_scope` `STRING` Who the venue admits as a customer, as authored: `residents_only`, `open` or `fiat_rail_only`. Null where the registry has not recorded it. `residents_only` is one of the three facts the gate requires.
`service_jurisdictions` `ARRAY` Countries the venue is authored as actively serving.
`restricted_jurisdictions` `ARRAY` Countries the venue is authored as restricting.
`licence_count` `INT64` Count of the venue's licence rows.
`licences_without_country` `INT64` Of those, licence rows recorded with no country. The gate fails while this count is above zero.
`licence_countries` `ARRAY` Countries those licences are held in. The gate requires exactly one; more than one, or zero, fails it.
`licence_status` `STRING` Comma-joined distinct status values across the venue's licences.
`funding_wallet_count` `INT64` Funding wallets attributed to this venue.
`funding_wallets_without_country` `INT64` Of those, wallets whose registry row names no country. The gate fails while this count is above zero.
`entities` `ARRAY` Distinct legal entity names across the venue's funding wallets.
`entity_countries` `ARRAY` Distinct countries those entities resolve to. The gate requires exactly one, matching `licence_countries`' single country.
`funding_jurisdiction` `STRING` ISO 3166-1 alpha-2, set only where `gate_reason` reads `qualifies`. Null on every other venue.
`funding_jurisdiction_name` `STRING` Display name of `funding_jurisdiction`, on the same terms.
`gate_reason` `STRING` The first of the gate's checks this venue fails, in the order named above, or `qualifies` when none does: `operating_scope_not_single_country`, `onboarding_not_residents_only`, `licence_country_missing_or_multiple`, `entity_country_missing_or_mismatched`, `jurisdiction_unknown`, or `qualifies`.
## Sample queries **Look up an account** The table is clustered on `chain_id` and `address`, so filtering on both is the cheapest lookup. Lowercase an EVM address copied from an explorer before you paste it in. ```sql theme={null} select chain_id, address, project_id, contract_name, account_type, label_source from `dimensions.accounts` where chain_id = 'ethereum' and address = '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2' ``` **An account's attested country** The attested country sits on the account row, so the same `chain_id` and `address` lookup returns it beside the region and the funding venue. It is filled on every EVM chain of an attested address. ```sql theme={null} select chain_id, address, attested_country, attested_at, region, funding_venue_project_id from `dimensions.accounts` where chain_id = 'base' and address = '0x0000000000000000000000000000000000000001' ``` **What one project operates** `label_source` splits how an address was attributed: `curated` is the set a person authored, and the rest is factory output. A null `label_source` is an address nobody has attributed. ```sql theme={null} select chain_id, address, contract_name, account_type from `dimensions.accounts` where project_id = 'uniswap' and label_source = 'curated' order by chain_id, contract_name limit 100 ``` **Addresses per project on one chain** `project_id` joins `dimensions.projects` for the display name and the market sector, which is how a chain's labeled addresses group into sectors. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'ethereum' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **Venues with a funding jurisdiction** `gate_reason` reads `qualifies` only where the venue's operating scope, onboarding scope, and licence and entity countries all agree on one country. ```sql theme={null} select venue_project_id, name, venue_type, funding_jurisdiction from `dimensions.venues` where gate_reason = 'qualifies' order by name ``` # Venue edges Source: https://tokenterminal.com/docs/catalog/accounts/venue-edges Every first contact between a wallet and a venue, curated or detected. One row per wallet, venue and edge direction: the first contact between them, to the venue or from it. `first_transaction_hash` names the transaction the edge was first observed in. ## Columns
Column Type Description
`account_id`STRINGAccount as one key: `{address}-{chain_id}`.
`chain_id`STRINGChain the edge happened on.
`address`STRINGThe wallet: lowercase on EVM, verbatim base58 on Solana.
`venue_project_id`STRINGVenue on the other side of the edge, from [Accounts ▸ Registry](/docs/catalog/accounts/registry)'s Venues tab.
`edge_direction`STRING`to_venue` or `from_venue`.
`first_edge_at`TIMESTAMPTime of the first contact between the wallet and the venue in this direction.
`first_edge_date`DATEUTC date of `first_edge_at`. Partition column, by month.
`first_transaction_hash`STRINGTransaction that made the first contact.
`counterparty_address`STRINGVenue-side address the wallet first touched.
`counterparty_kind`STRING`anchor` for a registry-curated venue wallet, `deposit_address` for a detected one.
`counterparty_confidence`STRING`curated` or `detected`, matching `counterparty_kind`.
`funding_leg`STRING`erc20`, `spl` or `native`: the transfer leg the edge was observed on.
`wallet_set_version`INT64Fingerprint of the venue's anchor set the edge was matched under.
## Sample queries > [!WARNING] > > This table is large and split by month. Bound `first_edge_date` and filter `address` and `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One wallet's edges** `address` and `chain_id` together are the cluster key, so filtering both reads only this wallet's blocks; `first_edge_date` still bounds the months scanned. ```sql theme={null} select venue_project_id, edge_direction, first_edge_at, counterparty_kind from `facts_accounts.venue_edges` where address = '0x7240234c7bf954cd7fc6323c38bbf6e6e4355e52' and chain_id = 'ethereum' and first_edge_date >= date('2024-01-01') and first_edge_date < date('2025-06-01') order by first_edge_at ``` **New edges per chain, one month** `edge_direction` splits deposits into a venue from withdrawals out of it, so grouping on it alongside `chain_id` reads both directions apart. ```sql theme={null} select chain_id, edge_direction, count(*) as edges from `facts_accounts.venue_edges` where first_edge_date >= date('2026-08-01') and first_edge_date < date('2026-09-01') group by chain_id, edge_direction order by edges desc ``` **Curated versus detected edges, one venue** `venue_project_id` joins `dimensions.venues` for the display name; `counterparty_kind` is the same split `facts_accounts.funding`'s `funding_venue_source` reads off the earliest edge. ```sql theme={null} select venues.name, edges.counterparty_kind, count(*) as edge_count from `facts_accounts.venue_edges` as edges join `dimensions.venues` as venues on edges.venue_project_id = venues.venue_project_id where edges.chain_id = 'ethereum' and edges.first_edge_date >= date('2026-08-01') and edges.first_edge_date < date('2026-09-01') group by venues.name, edges.counterparty_kind order by edge_count desc ``` # Agent's manual Source: https://tokenterminal.com/docs/catalog/agents-manual Whole data catalog. One page. Caveman format. For model that write query. This page = whole catalog, one page, for model that write query. Nothing link out. Human? Read [Human's manual](/docs/catalog/humans-manual) instead. Page written in [caveman](https://github.com/juliusbrussee/caveman) format. Few token, same rule. No article, no auxiliary verb, no hedge, no transition. Identifier, type, number, negation stay exact. Only grammar go. Read once. Then build table name yourself. No lookup. Name tell you grain, keys, time column, value columns. Name never lie. ## Build table name Name = `dataset.table`. Dataset say what kind, what about. Table say rest. | Pattern | Rows | Key columns | Time column | | - | - | - | - | | `dimensions.` | One per thing | `_id` | none | | `facts_.` | One per event | `_id` + event keys | `block_timestamp` | | `metrics_._` | One per thing per period | `_id` | `timestamp` | | `reports_._` | One per thing per period | `_id` | `period_start` | | `screeners.` | One per thing, as of last complete day | `_id` | none (`as_of`) | | `functions.calculate_` | Table function, call with arguments | arguments | argument | | `.` | One per block, transaction, log or call | none | `block_timestamp` | Metrics table = ONE measure. Columns = level ids + `timestamp` + one value column. Value column name = table name minus period. Table Source = Ladder, projected? Table also has `provenance`: `ladder` or `projected`, the source of that row. `metrics_projects.fees_daily` → `project_id`, `timestamp`, `fees`. Done. No page needed. Do NOT select column the name not promise. Levels roll up: `apps_by_chain` → `apps` → `projects`. `asset_tokens` → `assets_by_chain` → `assets`. Use biggest level that answer question. Rollup already exist. Cheaper. Already correct. ## Rules. Break rule = wrong answer or big bill. All these seen for real. 1. **Bound time column. ALWAYS.** No bound = read whole table. You pay, not us. Facts use `block_timestamp`. Metrics use `timestamp`. Reports use `period_start`. Screener = one row per thing as of now, no time column. 2. **Time bound alone is NOT enough.** Not every table is partitioned, and a bound on an unpartitioned column prunes nothing. Every table is clustered, so also filter its cluster key: the entity id for a metrics table, `token_address` for token facts. Read the keys from `INFORMATION_SCHEMA.COLUMNS`: `is_partitioning_column` and `clustering_ordinal_position`. Filter the leading cluster column first, order matters. Empty result = the object is a VIEW, which reports no keys; take its contract from its page. 3. **Partition column naked on left.** `date(block_timestamp) >= x` = read every partition. Function hide column from pruner. Write `block_timestamp >= timestamp('2026-01-01')`. 4. **Bound BOTH sides of join.** Bound not travel across join. Two tables, two bounds. 5. **One token = filter `token_address` + `chain_id`. NOT `token_id`.** Same rows, but `token_address` is the cluster key and `chain_id` drops whole chains at plan time. `token_id` is derived, reaches no cluster key, and reads every chain: terabytes against megabytes. Keep `token_id` for join to `dimensions.tokens`. 6. **Set `maximum_bytes_billed` on EVERY job.** Over the cap, the query fails before it runs and bills nothing; the error names the bytes it needed. Wrong query costs you an error, not money. `bq query --maximum_bytes_billed=`, or `maximumBytesBilled` in the job config of any client library. Set it low, raise it when the failure tells you to. 7. **Bytes scanned is the bill, NOT rows returned.** [BigQuery on-demand](https://cloud.google.com/bigquery/pricing#analysis_pricing_models) charges per byte the query reads, at a rate per TiB, with a 10 MiB floor per table per query. `limit` changes NOTHING: `limit 10` reads the same bytes as no limit. Naming columns DOES cut the bill, because storage is columnar. Never `select *`. 8. **No recursive CTE. No unbounded self-join.** `with recursive` reads again every step and the bytes compound; a fan-out join multiplies rows before you see them. Size the join with a count first. A question that seems to need recursion wants a smaller question. 9. **Empty ≠ zero.** Empty = no figure exist for that measure, that thing, that day. Do NOT coalesce 0 then average or sum across. Do NOT call it decline. 10. **Get unit from `dimensions.metrics` BEFORE format.** Unit = `usd`, `count`, `ratio`, `pct`. Ratio = fraction: `apy` 0.05 = 5 percent, `off_peg` -0.02 = 2 percent under peg. NEVER assume dollar. 11. **Sum only how `dimensions.metrics` allow.** * *Additive* (fees, volume): sum across day, sum across thing. Both fine. * *Semi-additive* (TVL, supply, open interest): sum across thing. NEVER across day. Week = last day of week. * *Non-additive* (APY, active users, share, funding rate): sum NEITHER way. Week active users = count distinct address over week from fact table. Add 7 daily counts = count same person 7 time. Wrong. 12. **Address case matter.** EVM stored lowercase: wrap explorer address in `lower()`. Solana base58, case-sensitive, match verbatim. 13. **`amount_raw` = STRING.** `uint256` overflow every BigQuery number type. Cast `BIGNUMERIC`, divide by `pow(10, decimals)` from `dimensions.tokens`. 14. **Financial statements wide.** `reports_projects.financial_statements_*` = one row per project per period, one column per line. Flows summed over period. Balances (`treasury`, `tvl`, `price`, market caps, supplies) = value on last day of period with value: NEVER sum balance across periods. User counts (`daily_active_users`, `token_holders`) = average daily count. 15. **Screener column = `__`.** `screeners.` = one row per thing (`projects`, `chains`, `assets`, `assets_by_chain`, `asset_tokens`), every window ends `as_of`. Window `1d`, `7d`, `30d`, `90d`, `180d`, `365d`. `avg` = mean of window. `sum` = total of window, flows ONLY: distinct count (`daily_active_users`, `token_holders`, `*_active_addresses`, `tradeable_*_count`) has NO `_sum`. `change` and `trend` compare two aggregation. `change` = value on `as_of` vs value N day before, `(now - then) / abs(then)`; null if either end missing or base 0. `trend` = N-day avg vs avg of N day before it; null unless prior window has value ALL N day, null if prior avg 0. Null = unknown, NOT zero. `_max_latest` = value ON `as_of`, null if none: NOT last value before. Plus `_max_ath`, `_max_atl`. Which aggregation a measure get follows its `over_time` in `dimensions.metrics`: `sum` ONLY if `over_time` = `sum`; every measure get latest, `avg`, `change`, `trend`, ath, atl. Asset token and asset chain `sum` add up to the coarser level; holders, users, `change`, `trend` NOT. Rank or filter projects? Read screener. Do NOT rebuild windows from metrics tables. 16. **NEVER query table from *Not served yet* list.** Those are spec, not table. Tell user data not available. Do NOT write query that cannot run. ## Join keys Id = lowercase name. Combined id = parts joined with dash. Every table carry at least one. That is why catalog join. | Identifier | Shape | Example | | - | - | - | | `chain_id` | Chain name | `ethereum` | | `project_id` | Project name | `uniswap` | | `app_id` | Project name + version | `uniswap-v3` | | `asset_id` | Asset name | `usdc` | | `asset_chain_id` | `{asset_id}-{chain_id}` | `usdc-base` | | `token_id` | `{token_address}-{chain_id}` | `0xa0b8…eb48-ethereum` | | `asset_token_id` | `{asset_id}-{token_address}-{chain_id}` | `usdc-0xa0b8…eb48-ethereum` | Asset = one identity, all chains. Token = one contract, one chain. USDC = one row `dimensions.assets`, one row per chain `dimensions.assets_by_chain`, one row per contract `dimensions.asset_tokens`. ## Question → table Shortest correct path for common question. Prefer metrics table over sum facts table yourself: smaller, and additivity already settled. | Question | Table | | - | - | | Fees, revenue, TVL, users of a project | `metrics_projects._daily` | | Same, split by chain | `metrics_projects_by_chain._daily` | | Same, one version of a protocol | `metrics_apps._daily` (`app_id` = `uniswap-v3`) | | Project income statement | `reports_projects.financial_statements_quarterly` | | Rank projects: 30-day fees, 7-day TVL change, 365-day revenue | `screeners.projects` | | Rank chains: 30-day app fees, transactions | `screeners.chains` | | Rank assets, one chain's assets or one asset's tokens: market cap, mints, holders | `screeners.assets`, `screeners.assets_by_chain`, `screeners.asset_tokens` | | User retention by signup cohort | `reports_projects.user_retention_monthly` | | Stablecoin or fund supply | `metrics_assets.market_cap_circulating_native_daily` | | Same, one chain | `metrics_assets_by_chain.market_cap_circulating_native_daily` | | Same, one contract | `metrics_asset_tokens.market_cap_circulating_native_daily` | | Holders of asset | `metrics_assets.holders_native_daily` | | Issuer terms of asset: custodian, regulator, redemption, ISIN | `dimensions.asset_disclosures` | | Share behind tokenized stock or fund | `dimensions.underlying_securities` | | Who hold token right now | `functions.calculate_latest_token_balances` | | Who held token on past day | `functions.calculate_historical_eod_token_balances` | | Every transfer of token | `facts_tokens.transfers` | | Token price series | `metrics_tokens.price_daily`, `metrics_tokens.price_hourly` | | DEX volume, one pool | `metrics_dex_pools.trading_volume_daily` | | DEX volume, one traded pair | `metrics_dex_pools_by_pair.trading_volume_daily` | | Perp open interest, funding, liquidations | `metrics_perp_markets._daily` | | Spot or order-book market volume, fees | `metrics_order_book_markets._daily` | | Chain fees and revenue | `metrics_chains.fees_daily`, `metrics_chains.revenue_daily` | | What measure mean, unit, additivity | `dimensions.metrics` | | Which measures exist for one thing | `dimensions.metric_instances` | ## All tables Every table in catalog. Generated from pages, so complete at build time. ### Dimensions `dimensions.accounts`, `dimensions.apps`, `dimensions.asset_disclosure_fields`, `dimensions.asset_disclosures`, `dimensions.asset_token_fields`, `dimensions.asset_tokens`, `dimensions.assets`, `dimensions.assets_by_chain`, `dimensions.chains`, `dimensions.contracts`, `dimensions.dex_pools`, `dimensions.lending_market_reserves`, `dimensions.lending_markets`, `dimensions.metric_instances`, `dimensions.metrics`, `dimensions.order_book_markets`, `dimensions.perp_markets`, `dimensions.projects`, `dimensions.reference_assets`, `dimensions.tokens`, `dimensions.underlying_securities`, `dimensions.underlying_security_fields`, `dimensions.vaults`, `dimensions.venues` ### Facts | Table | Key columns | Status | | - | - | - | | `facts_accounts.activity_hours` | `address`, `chain_id` | served | | `facts_accounts.attested_country` | `address`, `chain_id` | served | | `facts_accounts.funding` | `address`, `chain_id` | served | | `facts_accounts.venue_edges` | `address`, `chain_id` | served | | `facts_asset_tokens.balance_changes_daily` | `token_id` | served | | `facts_asset_tokens.balances_latest` | `token_id`, `account_address` | served | | `facts_asset_tokens.senders` | `asset_token_id` | served | | `facts_asset_tokens.senders_hll` | `asset_token_id` | served | | `facts_bridge_tokens.transfers` | `bridge_id`, `token_id` | served | | `facts_dex_pools.trades` | `dex_pool_id` | served | | `facts_lending_market_reserves.configuration_updates` | `lending_market_reserve_id` | served | | `facts_lending_markets.borrows` | `lending_market_id` | served | | `facts_lending_markets.deposits` | `lending_market_id` | served | | `facts_lending_markets.interest_rates` | `lending_market_id` | served | | `facts_lending_markets.liquidations` | `lending_market_id` | served | | `facts_lending_markets.repayments` | `lending_market_id` | served | | `facts_lending_markets.withdrawals` | `lending_market_id` | served | | `facts_order_book_markets.trades` | `order_book_market_id` | served | | `facts_perp_markets.liquidations` | `perp_market_id` | served | | `facts_perp_markets.trades` | `perp_market_id` | served | | `facts_tokens.transfers` | `token_id` | served | ### Metrics | Dataset | Key columns | Periods | Measures | | - | - | - | - | | `metrics_apps_by_chain` | `app_id`, `chain_id` | daily | `active_loans`, `assets_staked`, `bridge_deposits`, `bridged_supply`, `buybacks`, `capital_deployed`, `cost_of_revenue`, `expenses`, `fees`, `fees_supply_side`, `flash_loan_volume`, `liquidation_volume`, `notional_trading_volume_exchange`, `notional_trading_volume_interface`, `open_interest`, `operating_expenses`, `outstanding_supply`, `revenue`, `token_incentives`, `trade_count`, `tradeable_asset_count`, `tradeable_pair_count`, `trading_volume`, `transaction_volume`, `transfer_volume_destination`, `transfer_volume_source`, `tvl` | | `metrics_apps` | `app_id` | daily | `active_loans`, `assets_staked`, `bridge_deposits`, `bridged_supply`, `buybacks`, `capital_deployed`, `collateral`, `cost_of_revenue`, `daily_active_users`, `expenses`, `fees`, `fees_supply_side`, `flash_loan_volume`, `liquidation_volume`, `monthly_active_users`, `notional_trading_volume_exchange`, `notional_trading_volume_interface`, `open_interest`, `operating_expenses`, `outstanding_supply`, `revenue`, `token_incentives`, `trade_count`, `tradeable_asset_count`, `tradeable_pair_count`, `trading_volume`, `transaction_volume`, `transfer_volume`, `tvl`, `weekly_active_users` | | `metrics_asset_tokens_by_app` | `asset_token_id`, `app_id` | daily | `app_trading_volume`, `app_tvl` | | `metrics_asset_tokens` | `asset_token_id` | daily | `app_trading_volume`, `app_tvl`, `apy`, `daily_active_users_agentic_bridged`, `daily_active_users_agentic_native`, `daily_active_users_bridged`, `daily_active_users_native`, `holders`, `holders_bridged`, `holders_native`, `market_cap_circulating`, `market_cap_circulating_bridged`, `market_cap_circulating_native`, `mints`, `mints_bridged`, `mints_native`, `monthly_active_users_agentic_bridged`, `monthly_active_users_agentic_native`, `monthly_active_users_bridged`, `monthly_active_users_native`, `redemptions`, `redemptions_bridged`, `redemptions_native`, `transfer_count`, `transfer_count_agentic`, `transfer_count_agentic_bridged`, `transfer_count_agentic_native`, `transfer_count_bridged`, `transfer_count_native`, `transfer_volume`, `transfer_volume_agentic`, `transfer_volume_agentic_bridged`, `transfer_volume_agentic_native`, `transfer_volume_bridged`, `transfer_volume_native`, `weekly_active_users_agentic_bridged`, `weekly_active_users_agentic_native`, `weekly_active_users_bridged`, `weekly_active_users_native` | | `metrics_assets_by_app` | `asset_id`, `app_id` | daily | `app_trading_volume`, `app_tvl` | | `metrics_assets_by_chain` | `asset_chain_id` | daily | `app_trading_volume`, `app_tvl`, `apy`, `daily_active_users`, `daily_active_users_agentic`, `holders`, `holders_bridged`, `holders_native`, `market_cap_circulating`, `market_cap_circulating_bridged`, `market_cap_circulating_native`, `mints`, `mints_bridged`, `mints_native`, `monthly_active_users`, `monthly_active_users_agentic`, `redemptions`, `redemptions_bridged`, `redemptions_native`, `transfer_count`, `transfer_count_agentic`, `transfer_count_agentic_bridged`, `transfer_count_agentic_native`, `transfer_count_bridged`, `transfer_count_native`, `transfer_volume`, `transfer_volume_agentic`, `transfer_volume_agentic_bridged`, `transfer_volume_agentic_native`, `transfer_volume_bridged`, `transfer_volume_native`, `weekly_active_users`, `weekly_active_users_agentic` | | `metrics_assets` | `asset_id` | daily | `app_trading_volume`, `app_tvl`, `apy`, `daily_active_users`, `daily_active_users_agentic`, `holders`, `holders_bridged`, `holders_native`, `market_cap_circulating`, `market_cap_circulating_bridged`, `market_cap_circulating_native`, `market_cap_circulating_offchain`, `mints`, `mints_bridged`, `mints_native`, `monthly_active_users`, `monthly_active_users_agentic`, `off_peg`, `price`, `redemptions`, `redemptions_bridged`, `redemptions_native`, `transfer_count`, `transfer_count_agentic`, `transfer_count_agentic_bridged`, `transfer_count_agentic_native`, `transfer_count_bridged`, `transfer_count_native`, `transfer_volume`, `transfer_volume_agentic`, `transfer_volume_agentic_bridged`, `transfer_volume_agentic_native`, `transfer_volume_bridged`, `transfer_volume_native`, `weekly_active_users`, `weekly_active_users_agentic` | | `metrics_bridge_tokens` | `bridge_id`, `token_id` | daily | `transfer_volume_destination`, `transfer_volume_source` | | `metrics_chains` | `chain_id` | daily | `app_active_loans`, `app_assets_staked`, `app_bridged_supply`, `app_fees`, `app_gas_used`, `app_monthly_active_addresses`, `app_monthly_active_users`, `app_outstanding_supply`, `app_trading_volume`, `app_transaction_count_contracts`, `app_tvl`, `block_time_average`, `bridge_deposits`, `contract_deployment_count`, `cost_of_revenue`, `daily_active_addresses`, `daily_contract_deployers`, `expenses`, `fees`, `fees_supply_side`, `monthly_active_addresses`, `revenue`, `staking_market_cap`, `token_incentives`, `transaction_count`, `transaction_fee_average`, `transaction_fee_median`, `transactions_per_second`, `validators`, `weekly_active_addresses` | | `metrics_dex_pools_by_pair` | `dex_pool_id`, `token_in_id`, `token_out_id` | daily | `trading_volume` | | `metrics_dex_pools` | `dex_pool_id` | daily | `fees`, `flash_loan_volume`, `trading_volume`, `tvl` | | `metrics_lending_market_reserves` | `lending_market_reserve_id` | daily | `active_loans`, `collateral`, `tvl` | | `metrics_lending_markets` | `lending_market_id` | daily | `active_loans`, `collateral`, `tvl` | | `metrics_order_book_markets_by_token` | `order_book_market_id`, `token_id` | daily | `fees`, `fees_supply_side`, `revenue`, `trading_volume` | | `metrics_order_book_markets` | `order_book_market_id` | daily | `fees`, `fees_supply_side`, `revenue`, `trading_volume` | | `metrics_perp_markets_by_token` | `perp_market_id`, `token_id` | daily | `fees`, `fees_supply_side`, `notional_trading_volume`, `notional_trading_volume_exchange`, `notional_trading_volume_interface`, `revenue` | | `metrics_perp_markets` | `perp_market_id` | daily | `daily_active_traders`, `daily_active_traders_long`, `daily_active_traders_short`, `fees`, `fees_supply_side`, `funding_rate`, `liquidation_volume_long`, `liquidation_volume_short`, `notional_trading_volume_exchange`, `notional_trading_volume_interface`, `open_interest`, `open_interest_long`, `open_interest_short`, `position_size_average_long`, `position_size_average_short`, `position_size_median_long`, `position_size_median_short`, `price`, `revenue`, `trade_count`, `trader_share_long_top10`, `trader_share_short_top10`, `volume_to_open_interest` | | `metrics_projects_by_chain` | `project_id`, `chain_id` | daily | `active_loans`, `assets_staked`, `bridge_deposits`, `bridged_supply`, `buybacks`, `capital_deployed`, `cost_of_revenue`, `daily_active_addresses`, `daily_active_users`, `expenses`, `fees`, `fees_supply_side`, `flash_loan_volume`, `gas_used`, `liquidation_volume`, `monthly_active_addresses`, `monthly_active_users`, `notional_trading_volume_exchange`, `notional_trading_volume_interface`, `open_interest`, `operating_expenses`, `outstanding_supply`, `revenue`, `token_holders`, `token_incentives`, `trade_count`, `tradeable_asset_count`, `tradeable_pair_count`, `trading_volume`, `transaction_count_contracts`, `transaction_volume`, `transfer_volume`, `transfer_volume_destination`, `transfer_volume_source`, `treasury`, `treasury_net`, `tvl`, `weekly_active_addresses`, `weekly_active_users` | | `metrics_projects` | `project_id` | daily | `active_loans`, `assets_staked`, `bridge_deposits`, `bridged_supply`, `buybacks`, `capital_deployed`, `code_commit_count`, `collateral`, `cost_of_revenue`, `daily_active_addresses`, `daily_active_users`, `earnings`, `expenses`, `fees`, `fees_per_daily_active_user`, `fees_supply_side`, `flash_loan_volume`, `gas_used`, `gross_profit`, `liquidation_volume`, `liquidity_turnover`, `market_cap_circulating`, `market_cap_fully_diluted`, `monthly_active_addresses`, `monthly_active_developers`, `monthly_active_users`, `notional_trading_volume_exchange`, `notional_trading_volume_interface`, `open_interest`, `operating_expenses`, `outstanding_supply`, `price`, `price_to_fees_circulating`, `price_to_fees_fully_diluted`, `price_to_revenue_circulating`, `price_to_revenue_fully_diluted`, `revenue`, `revenue_per_daily_active_user`, `staking_market_cap`, `take_rate`, `token_holders`, `token_incentives`, `token_supply_circulating`, `token_supply_maximum`, `token_trading_volume`, `token_turnover_circulating`, `token_turnover_fully_diluted`, `trade_count`, `trade_size_average`, `tradeable_asset_count`, `tradeable_pair_count`, `trading_volume`, `trading_volume_per_daily_active_user`, `transaction_count_contracts`, `transaction_volume`, `transfer_volume`, `treasury`, `treasury_net`, `tvl`, `weekly_active_addresses`, `weekly_active_users` | | `metrics_tokens` | `token_id` | daily, hourly | `price` | ### Reports | Dataset | Key columns | Periods | Reports | | - | - | - | - | | `reports_accounts` | `chain_id` | | `activity_coverage`, `funding_coverage`, `funding_hit_rate`, `funding_region_agreement`, `funding_venue_distribution`, `region_distribution`, `region_hit_rate` | | `reports_projects` | `project_id` | quarterly, yearly, monthly | `financial_statements`, `user_retention` | ### Screeners `screeners.asset_tokens`, `screeners.assets`, `screeners.assets_by_chain`, `screeners.chains`, `screeners.projects` ### Functions `functions.calculate_historical_eod_asset_token_balances`, `functions.calculate_historical_eod_token_balances`, `functions.calculate_latest_asset_token_balances`, `functions.calculate_latest_token_balances` ## Not served yet Name documented before table land. Page = spec. Table NOT exist. Query these = fail. `New` tag on page = opposite. Table served, landed recent. Query normal. ## Access Catalog = BigQuery share in caller own Google Cloud project. Caller pay compute. No public endpoint. No anonymous access. Missing dataset error = share not set up. Human must arrange. Say so. Do NOT retry. # Apps Source: https://tokenterminal.com/docs/catalog/apps/index Deployed protocol versions, the project behind each one, and their metrics per chain. An app is one deployed version of a protocol, such as `uniswap-v3`, `aave-v3` or `hyperliquid-perps`. It belongs to the [project](/docs/catalog/projects/index) that runs it, and it operates on one or more [chains](/docs/catalog/chains/index). An app's figures cover every chain it runs on, and the app-and-chain tables split the same figures by chain. ## Coverage A tab per grain. Each tab says what one row is, and a tick marks every app that reports the measure at that grain. **App** An app is one deployed version of a protocol, such as `uniswap-v3`. One row per app per day, across every chain it runs on.
App TVL Trading volume Fees Supply-side fees Revenue Token incentives Daily active users Weekly active users Monthly active users Trade count
`0x-app`✗✓✓✓✓✓✓✓✓✗
`1inch-aggregator`✗✓✓✓✓✓✓✓✓✓
`aave-chainlink-svr`✗✗✓✗✓✗✗✗✗✗
`aave-v2`✓✗✓✓✓✓✓✓✓✗
`aave-v3`✓✗✓✓✓✓✓✓✓✗
`aave-v4`✓✗✓✓✓✗✓✓✓✗
`abracadabra-app`✓✗✓✗✓✓✓✓✓✗
`acala-dex`✓✓✓✓✗✗✗✗✗✓
`acala-liquidstaking`✗✗✓✗✓✗✗✗✗✗
`across-bridge`✓✗✓✓✓✓✓✓✓✗
`aerodrome-slipstream`✓✓✓✗✓✗✓✓✓✓
`aerodrome-stable`✓✓✗✗✗✗✗✗✗✗
`aerodrome-volatile`✓✓✗✗✗✗✗✗✗✗
`aethir`✗✗✓✓✓✓✗✗✗✗
`airswap-app`✗✓✓✓✓✓✓✓✓✓
`ajuna-nft`✗✓✗✗✗✗✗✗✗✗
`allbridge`✗✗✓✓✓✓✓✓✓✗
`alongside-app`✓✗✓✗✓✓✗✗✗✗
`alphaq`✗✓✗✗✗✗✓✓✓✓
`angle-issuance`✓✗✓✗✓✓✗✗✗✗
`ankr-liquidstaking`✓✗✗✗✗✗✓✓✓✗
`aperture-swap-v1`✓✓✓✓✓✓✓✓✓✓
`apeswap-dex`✓✓✓✓✓✓✓✓✓✓
`apollox-perps`✓✗✓✓✓✓✓✓✓✗
`aragon-app`✗✗✓✗✓✓✗✗✗✗
`astar-staking`✓✗✗✗✗✗✗✗✗✗
`aurafinance-app`✗✗✓✓✓✓✓✓✓✗
`axie-app`✗✗✓✓✓✗✗✗✗✗
`axiomtrade-app`✗✓✓✓✓✗✓✓✓✗
`azuro-app`✗✓✗✗✗✗✓✓✓✗
`balancer-dex`✓✓✓✓✓✓✓✓✓✓
`bancor-dex`✓✓✓✓✓✓✓✓✓✓
`bankr-tradingbot`✗✓✓✓✓✗✓✓✓✓
`beethoven-dex`✓✓✓✓✓✓✓✓✓✓
`benddao-lending`✗✗✓✓✓✓✓✓✓✗
`benqi-lending`✗✗✓✓✓✓✓✓✓✗
`benqilsd-liquidstaking`✓✗✓✗✗✗✓✓✓✗
`betswirl-app`✗✓✓✓✓✓✓✓✓✗
`bifrostio-liquidstaking`✓✗✓✓✓✗✗✗✗✗
`bifrostio-stable-swaps`✓✓✗✗✗✗✗✗✗✓
`bisonfi`✗✓✗✗✗✗✗✗✗✗
`biswap-dex`✗✓✓✓✓✗✓✓✓✓
`blackhole-dex`✓✓✗✗✗✗✗✗✗✗
`bloomtradingbot`✗✗✓✓✓✗✓✓✓✗
`bloxroute-app`✗✗✓✓✓✗✓✓✓✗
`blur-app`✗✓✓✓✓✓✓✓✓✗
`bmx-basedmediax`✗✓✓✓✓✗✓✓✓✗
`bmx-classic`✓✗✓✓✓✗✓✓✓✗
`bmx-deliswap`✗✓✓✓✓✓✓✓✓✓
`bmx-freestyle`✓✗✓✓✓✗✓✓✓✗
`bonkbot-tradingbot`✗✗✓✓✓✗✓✓✓✗
`botto-app`✓✗✗✗✗✗✗✗✗✗
`bouncefinance-app`✗✓✓✗✓✗✓✓✓✗
`bufferfinance-app`✓✗✓✗✗✓✓✓✓✗
`bullx-tradingbot`✗✗✓✓✓✗✓✓✓✗
`byreal`✗✓✗✗✗✗✓✓✓✓
`calyx-app`✗✓✗✗✗✗✓✓✓✓
`camelot-dex`✓✓✓✓✓✓✓✓✓✓
`cap-perps`✗✗✓✓✓✓✓✓✓✗
`cbeth-app`✓✗✗✗✗✗✗✗✗✗
`chainflip-dex`✗✓✓✓✓✗✓✓✓✓
`chainflip-lending`✓✗✓✓✓✗✓✓✓✗
`chainlink-ccip`✗✗✓✗✓✗✓✓✓✗
`circle-cctp-v1`✗✗✗✗✗✗✗✗✗✗
`circle-cctp-v2`✗✗✓✗✓✗✗✗✗✗
`circle-stablefx`✗✓✓✓✓✗✓✓✓✓
`clipper-dex`✗✓✓✓✓✓✓✓✓✓
`coinshift-issuance`✓✗✓✓✓✓✓✓✓✗
`compound-lending`✓✗✓✓✓✓✓✓✓✗
`connext-bridge`✗✗✓✓✓✓✓✓✓✗
`convexfinance-app`✗✗✓✓✓✓✓✓✓✗
`cowswap-aggregator`✗✓✓✓✓✓✓✓✓✓
`cryptex-app`✗✗✓✓✓✓✓✓✓✗
`curve-dex`✓✓✓✓✓✗✓✓✓✗
`curve-llamalend`✓✗✗✗✗✗✗✗✗✗
`debridge-liquidity-network-dln`✗✗✓✓✓✓✓✓✓✗
`debridge-messaging`✗✗✓✓✓✓✓✓✓✗
`decentralgames-app`✗✗✗✗✗✓✗✗✗✗
`defisaver-app`✗✗✓✗✓✓✗✗✗✗
`deriprotocol-app`✗✗✓✓✓✓✓✓✓✗
`dexscreener-app`✗✗✓✓✓✗✗✗✗✗
`dfx-dex`✗✓✓✓✓✓✓✓✓✓
`dodo-dex`✗✓✓✓✓✓✓✓✓✓
`dolomite-lending`✓✓✓✓✓✓✓✓✓✗
`dopex-clamm-v2`✓✗✓✓✓✗✗✗✗✗
`dopex-ssov-v1`✓✗✓✓✓✗✗✗✗✗
`dreamcash-perps`✗✗✓✓✓✗✓✓✓✓
`driftprotocol-trade`✓✗✗✗✗✗✓✓✓✗
`dydx-v3`✓✗✓✗✓✓✗✗✗✗
`dydx-v4`✓✗✓✗✓✗✓✓✓✗
`edgex-bridge`✗✗✗✗✗✗✗✗✗✗
`edgex-perps`✗✗✓✓✓✗✗✗✗✗
`eigenlayer`✓✗✓✓✓✗✓✓✓✗
`ens-app`✗✗✗✗✗✗✓✓✓✗
`entropyio-perps`✗✗✗✗✗✗✗✗✗✗
`equalizer-dex`✓✓✓✓✓✗✗✓✓✓
`ethena-issuance`✓✗✓✓✓✗✓✓✓✗
`etherex-concentrated-liquidity`✗✓✓✓✓✓✓✓✓✗
`etherex-constant-product`✗✓✓✓✓✗✓✓✓✗
`etherfi-cash`✓✗✓✓✓✓✓✓✓✗
`etherfi-liquid`✓✗✓✓✓✗✓✓✓✗
`etherfi-stake`✓✗✓✓✓✓✓✓✓✗
`euler-lending`✗✗✓✓✓✗✓✓✓✗
`euler-swap`✗✓✓✗✓✗✓✓✓✓
`falconfinance-issuance`✓✗✓✓✓✗✓✓✓✗
`fathom-dex`✓✓✓✓✓✗✗✓✓✓
`fathom-lending`✓✗✓✓✓✗✗✓✓✗
`felix-perps`✗✗✓✓✓✗✓✓✓✓
`flashbots-app`✗✗✓✗✓✓✓✓✓✗
`flux-lending`✓✗✗✗✗✗✗✗✗✗
`flyingtulip-lend`✓✗✓✓✓✗✓✓✓✗
`flyingtulip-perpetual-put-marketplace`✗✗✓✗✓✗✓✓✓✗
`flyingtulip-yield`✗✗✓✗✓✗✗✗✗✗
`fomo-crosschain`✗✓✓✓✓✗✓✓✓✓
`fomo-perps`✗✗✓✓✓✗✓✓✓✓
`fomo-spot`✗✓✓✓✓✗✓✓✓✓
`foundation-app`✗✓✓✓✓✓✓✓✓✗
`frax-app`✓✗✓✓✓✗✓✓✓✗
`fraxlend-lending`✓✗✗✗✗✗✓✓✓✗
`friendtech-app`✓✓✓✓✓✓✓✓✓✗
`gammastrategies-app`✗✗✓✓✓✓✓✓✓✗
`gearbox-lending`✗✗✓✓✓✗✓✓✓✗
`gmgn-tradingbot`✗✗✓✓✓✗✓✓✓✗
`gmx-perps`✓✗✓✓✓✓✓✓✓✗
`goldfinch-lending`✗✗✓✓✓✓✓✓✓✗
`goonfi`✗✓✗✗✗✗✗✗✗✗
`goonfi-amm-v1`✗✓✗✗✗✗✗✗✗✗
`grove-allocator`✓✗✓✓✓✓✗✗✗✗
`grvt-perps`✓✗✗✗✗✗✗✗✗✗
`hegic-app`✓✗✓✓✓✓✓✓✓✗
`heliopay-app`✗✗✓✓✓✗✓✓✓✗
`helium-app`✗✗✓✗✓✗✗✗✗✗
`hmx-perps`✗✗✓✓✓✓✓✓✓✗
`holdstation-defutures-v1`✓✗✓✓✓✓✓✓✓✗
`holdstation-v1`✗✗✗✗✗✗✗✗✗✗
`honeypop-dex`✓✓✓✓✓✗✓✓✓✓
`hop-bridge`✗✗✓✓✓✓✓✓✓✗
`houdiniswap-app`✗✗✓✗✓✓✗✗✗✗
`hydradx-dex`✓✓✓✗✓✗✗✗✗✓
`hydradx-lending`✓✗✓✓✓✗✗✗✗✗
`hyena-perps`✗✗✓✓✓✗✓✓✓✓
`hyperbridge-app`✗✗✓✓✓✓✓✓✓✗
`hyperlend-lending`✓✗✓✓✓✗✓✓✓✗
`hyperliquid-outcome-markets`✗✓✓✓✓✗✓✓✓✗
`hyperliquid-perps`✗✗✓✓✓✗✓✓✓✗
`hyperliquid-spot`✗✓✓✓✓✗✓✓✓✗
`hyperliquid-usdc-reserve-income`✗✗✓✓✓✗✗✗✗✗
`idex-dex`✗✓✓✓✓✗✗✗✗✓
`idle-app`✗✗✗✗✗✓✗✗✗✗
`immutable-orderbook`✗✓✓✗✓✗✗✗✗✗
`impossible-app`✓✓✗✗✗✗✗✗✗✗
`indexcoop-app`✓✗✓✓✓✓✓✓✓✗
`instadapp-fluid`✓✗✗✓✓✗✗✗✗✗
`instadapp-fluid-dex`✗✓✓✓✓✓✓✓✓✓
`instadapp-fluid-dex-lite`✓✓✓✓✗✓✓✓✓✓
`instadapp-fluid-lite`✓✗✓✓✓✓✓✓✓✗
`instadapp-fluid-vault`✗✗✓✓✓✓✓✓✓✗
`instadapp-jupiter-lend`✓✗✓✓✓✓✗✗✗✗
`instadapp-venus-flux`✓✓✓✓✓✓✓✓✓✓
`integral-dex`✗✓✓✓✓✓✗✗✗✓
`ipor-app`✓✗✓✓✓✓✓✓✓✗
`jito-liquidstaking`✓✗✗✗✗✗✓✓✓✗
`jito-mev-tips`✗✗✓✓✓✗✓✓✓✗
`jupiter-apepro`✗✗✓✗✗✗✗✗✗✗
`jupiter-dca`✗✗✓✗✗✗✗✗✗✗
`jupiter-lend`✓✗✓✓✓✗✗✗✗✗
`jupiter-limitorder`✗✗✓✗✗✗✗✗✗✗
`jupiter-perps`✓✗✓✗✗✗✗✗✗✗
`jupiter-ultra`✗✗✓✗✗✗✗✗✗✗
`kamino-lend`✓✗✗✗✗✗✗✗✗✗
`kapitaldao-app`✗✗✓✓✓✓✗✗✗✗
`katana-dex`✓✓✓✓✓✓✓✓✓✓
`katananetwork-ausd-yield`✗✗✓✓✓✗✗✗✗✗
`katananetwork-perps`✓✗✓✓✓✗✓✓✓✓
`katananetwork-vault-bridge`✗✗✓✓✓✗✗✗✗✗
`kelpdao-app`✓✗✓✓✓✗✓✓✓✗
`kinetiq-perps`✗✗✗✗✗✗✓✓✓✓
`kleros-app`✗✗✓✓✓✓✗✗✗✗
`kwenta-perps`✗✗✓✓✓✓✓✓✓✗
`kyber-dex`✓✓✓✓✓✓✓✓✓✓
`layer3-app`✗✗✓✗✓✗✓✓✓✗
`layerzero-stargate`✗✗✓✓✗✗✓✓✓✗
`layerzero-v1`✗✗✓✓✓✗✓✓✓✗
`layerzero-v2`✗✗✓✓✓✗✓✓✓✗
`levelfinance-perps`✓✗✓✓✓✓✓✓✓✗
`lido-liquidstaking`✓✗✓✓✓✓✓✓✓✗
`lighter-app`✓✗✗✗✗✗✗✗✗✗
`liquidcollective-liquidstaking`✓✗✗✗✗✗✓✓✓✗
`liquity-issuance`✓✗✓✓✓✓✓✓✓✗
`livepeer-app`✗✗✓✓✓✓✗✗✗✗
`looksrare-app`✗✓✓✓✓✓✓✓✓✗
`lybra-issuance`✓✗✗✗✗✗✓✓✓✗
`maestro-tradingbot`✗✗✓✓✓✗✓✓✓✗
`maiar-dex`✗✓✓✓✓✗✗✗✗✗
`makerdao-issuance`✓✗✓✓✓✓✓✓✓✗
`mamo`✓✗✗✗✓✗✓✓✓✗
`manifoldxyz-app`✗✓✓✓✓✓✗✗✗✗
`mantra-dex`✓✓✓✓✓✗✓✓✓✓
`maple-institutional`✓✗✗✗✗✗✗✗✗✗
`maple-other-pools`✓✗✗✗✗✗✗✗✗✗
`marinade-liquid-staking`✓✗✓✓✓✗✓✓✓✗
`marinade-native`✓✗✓✓✓✗✓✓✓✗
`marinade-select`✓✗✓✓✗✗✓✓✓✗
`maverick-dex`✓✓✓✓✓✗✓✓✓✓
`meanfinance-dex`✗✓✓✓✓✓✗✗✗✓
`merkletrade-perps`✓✗✓✓✓✓✓✓✓✗
`metamask-wallet`✓✓✗✗✗✗✓✓✓✓
`metavault-perps`✓✗✓✓✓✓✓✓✓✗
`meteora-launchpad`✓✓✓✓✓✗✓✓✓✓
`meteora-liquidity-pools`✓✓✓✓✓✗✓✓✓✓
`metric-v1`✗✓✗✗✗✗✗✗✗✗
`metric-v2`✗✓✗✗✗✗✗✗✗✗
`moonshot-app`✗✗✓✓✓✗✗✗✗✗
`moonwell-lending`✓✗✓✓✓✓✓✓✓✗
`morpho-blue`✓✗✓✓✓✗✗✗✗✗
`morpho-midnight`✓✗✗✗✗✗✓✓✓✗
`morpho-optimizer`✓✗✓✓✓✓✗✗✗✗
`mummy-perps`✓✗✓✓✓✓✓✓✓✗
`mux-perps`✓✗✓✓✓✓✓✓✓✗
`mythos-dmarket`✗✓✓✗✓✗✓✓✓✗
`mythos-marketplace`✗✓✓✓✓✗✓✓✓✗
`native-relay`✓✓✓✓✓✗✓✓✓✗
`near-intents`✗✓✓✓✓✗✓✓✓✗
`nexusmutual-app`✗✗✓✓✓✗✓✓✓✗
`nftx-app`✗✓✓✓✓✓✓✓✓✗
`notional-lending`✓✓✓✓✓✓✓✓✓✗
`noxa-app`✓✗✗✗✗✗✗✗✗✗
`o1exchange-app`✓✓✓✓✓✗✓✓✓✗
`okutrade-dex`✓✓✓✓✓✗✓✓✓✓
`ondo-perps`✓✗✗✗✗✗✗✗✗✗
`openchat-app`✗✗✓✓✓✗✓✓✓✗
`opensea-app`✗✓✓✓✓✓✓✓✓✗
`opyn-app`✓✗✓✗✓✓✓✓✓✗
`orca-token-swap-v2`✓✓✓✓✓✗✓✓✓✓
`orca-whirlpools`✓✓✓✓✓✓✓✓✓✓
`origin-arm`✗✗✓✓✓✗✗✗✗✗
`origin-otoken`✓✗✓✓✓✗✗✗✗✗
`pancakeswap-v2`✓✓✓✓✓✗✓✓✓✓
`pancakeswap-v3`✓✓✓✓✓✗✓✓✓✓
`pangolin-dex`✓✓✓✓✓✗✓✓✓✓
`paragon-perps`✗✗✓✓✓✗✓✓✓✓
`pendle-amm`✗✗✓✓✓✗✓✓✓✗
`pendle-boros`✓✗✓✓✓✗✗✗✗✗
`pendle-limit-order`✗✗✓✓✓✗✗✗✗✗
`pendle-vependle`✗✗✓✓✓✗✗✗✗✗
`pendle-yield-tokenization`✓✗✓✓✓✗✗✗✗✗
`perpetualprotocol-perps`✓✗✓✓✓✓✓✓✓✗
`phantom-wallet`✗✗✓✓✓✗✓✓✓✗
`pharaoh-dex`✓✓✓✓✓✓✓✓✓✓
`photon`✗✓✓✓✓✗✓✓✓✗
`pikaprotocol-perps`✓✗✓✓✓✓✓✓✓✗
`polymarket-app`✓✓✓✓✓✓✓✓✓✗
`polynomial-perps`✗✗✓✓✓✓✓✓✓✗
`pooltogether-app`✗✗✓✓✓✓✓✓✓✗
`premia-app`✓✗✓✓✓✓✓✓✓✗
`primenumbers-primefi-lending`✓✗✓✓✓✓✓✓✓✗
`primenumbers-staking`✓✗✗✗✗✓✗✗✗✗
`prismafinance-lending`✓✗✗✗✗✗✓✓✓✗
`projectx`✗✓✗✗✗✗✓✓✓✓
`pumpfun-amm`✗✓✗✗✗✗✗✗✗✗
`pumpfun-launchpad`✗✓✓✓✓✗✓✓✓✗
`quickswap-v2`✓✓✓✓✓✗✓✓✓✓
`quickswap-v3`✓✓✓✓✓✗✓✓✓✓
`radiant-lending`✓✗✓✓✓✓✓✓✓✗
`ramses-dex`✓✓✓✓✓✓✓✓✓✓
`rarible-exchange`✗✓✓✓✓✓✓✓✓✗
`raybot-tradingbot`✗✗✓✓✓✗✗✗✗✗
`raydium-clmm`✓✓✓✓✓✗✓✓✓✗
`raydium-cpmm`✓✓✓✓✓✗✓✓✓✗
`raydium-launchlab`✓✓✓✓✓✗✓✓✓✗
`raydium-openbook`✓✓✓✓✓✗✓✓✓✗
`raydium-stable-swap`✓✓✓✓✓✗✓✓✓✗
`ren-bridge`✗✗✓✓✓✓✓✓✓✗
`reserve-index`✓✗✓✗✓✗✓✓✓✗
`reserve-rights`✓✗✓✗✓✗✓✓✓✗
`reserve-yield`✓✗✓✓✓✓✓✓✓✗
`ribbon-app`✓✗✓✓✓✓✓✓✓✗
`ringsprotocol-app`✓✗✓✓✓✓✓✓✓✗
`ripple-amm`✓✓✓✓✓✓✓✓✓✓
`ripple-clob`✗✓✗✗✗✗✓✓✓✓
`rocketpool-liquidstaking`✓✗✗✗✗✗✓✓✓✗
`sanctum-infinity`✓✗✗✗✗✗✗✗✗✗
`sanctum-lsts`✓✗✗✗✗✗✗✗✗✗
`sanctum-reserve`✓✗✗✗✗✗✗✗✗✗
`seamlessprotocol-ilms`✓✗✗✗✗✗✗✗✗✗
`seamlessprotocol-lending`✓✗✓✓✓✗✗✗✗✗
`seamlessprotocol-leverage-tokens`✓✗✓✗✗✗✗✗✗✗
`seamlessprotocol-vaults`✓✗✓✗✓✗✗✗✗✗
`shadowexchange-concentrated-liquidity`✗✓✓✓✓✓✗✓✓✗
`shadowexchange-constant-product`✗✓✓✓✓✓✗✓✓✗
`shoebill-lending`✓✗✓✓✓✓✓✓✓✗
`silo-lending`✓✗✓✓✓✓✓✓✓✗
`solidlizard-dex`✓✓✓✓✓✓✓✓✓✓
`soltradingbot`✗✗✓✓✓✗✓✓✓✗
`solv-app`✓✗✓✓✓✗✓✓✓✗
`sound-app`✗✓✓✓✓✓✓✓✓✗
`spark-lend`✓✗✓✓✓✗✓✓✓✗
`spark-liquidity`✓✗✓✓✓✗✗✗✗✗
`spark-savings`✓✗✓✓✓✗✓✓✓✗
`spookyswap-dex`✓✓✓✓✓✓✗✓✓✓
`stader-liquidstaking`✓✗✓✓✓✗✓✓✓✗
`stafi-liquidstaking`✓✗✗✗✗✗✓✓✓✗
`stakestone-v1`✓✗✗✗✗✗✓✓✓✗
`stakewise-poolstaking`✓✗✓✓✓✓✓✓✓✗
`stakewise-solostaking`✓✗✗✗✗✗✓✓✓✗
`steakhousefinancial-kaminovaults`✓✗✓✓✓✓✓✓✓✗
`steakhousefinancial-morphovaults`✓✗✓✓✓✓✓✓✓✗
`sudoswap-app`✗✓✓✓✓✓✓✓✓✗
`sunswap-v1`✗✓✗✗✗✗✓✓✓✓
`sunswap-v2`✗✓✗✗✗✗✓✓✓✓
`sunswap-v3`✗✓✗✗✗✗✓✓✓✓
`sunswap-v4`✗✓✗✗✗✗✓✓✓✓
`sushiswap-dex`✓✓✓✓✓✓✓✓✓✓
`swarm-app`✗✗✓✓✓✓✓✓✓✗
`swell-liquidstaking`✓✗✗✗✗✗✓✓✓✗
`symbiotic-app`✓✗✗✗✗✗✗✗✗✗
`synapse-bridge`✓✗✓✓✓✓✓✓✓✗
`syncswap-dex`✓✓✓✓✓✓✓✓✓✓
`synfutures-perps`✓✗✓✓✓✓✓✓✓✗
`synthetix-app`✗✗✓✓✓✓✓✓✓✗
`temple`✗✓✗✗✗✗✗✗✗✗
`tesserav`✗✓✗✗✗✗✗✗✗✗
`tether-issuance`✓✗✓✗✓✗✗✗✗✗
`thales-app`✗✗✓✓✓✓✓✓✓✗
`thegraph-app`✗✗✓✗✓✓✓✓✓✗
`thena-fusion`✓✓✓✓✓✓✓✓✓✓
`thena-integral`✓✓✓✓✓✓✓✓✓✓
`thena-v1`✓✓✓✓✓✗✓✓✓✓
`thetanuts-app`✓✗✓✓✓✓✓✓✓✗
`thruster-clamm`✗✓✓✓✓✗✓✓✓✓
`thruster-classic`✗✓✓✓✓✗✓✓✓✓
`tokemak-autopool`✓✗✓✓✓✓✗✗✗✗
`tokenlon-aggregator`✓✓✓✓✓✓✓✓✓✓
`tornadocash-app`✓✗✓✗✓✗✓✓✓✗
`toucan-app`✓✗✓✓✓✓✓✓✓✗
`traderjoe-dex`✓✓✓✓✓✓✓✓✓✓
`tradexyz-perps`✗✗✓✓✓✗✓✓✓✓
`trojan-tradingbot`✗✗✓✓✓✗✓✓✓✗
`truefi-lending`✗✗✓✓✓✓✓✓✓✗
`unipilot-app`✗✗✓✓✓✓✓✓✓✗
`uniquenetwork-nft`✗✓✗✗✗✗✗✗✗✗
`uniswap-v2`✓✓✓✓✓✓✗✓✓✓
`uniswap-v3`✓✓✓✓✓✗✗✓✓✓
`uniswap-v4`✓✓✓✓✓✗✗✓✓✓
`uniswaplabs-app`✗✓✓✓✓✓✓✓✓✗
`usdai-issuance`✓✗✗✗✗✗✗✗✗✗
`variational-omni`✓✗✓✓✓✗✓✓✓✗
`velodrome-dex`✓✓✓✓✓✓✓✓✓✓
`ventuals-perps`✗✗✓✓✓✗✓✓✓✓
`venus-flux`✓✗✓✓✓✗✗✗✗✗
`venus-lending`✓✗✓✓✓✗✗✗✗✗
`versedex-dex`✓✓✓✓✓✓✓✓✓✓
`vertex`✓✗✓✓✓✗✗✗✗✗
`vertex-blitz`✓✗✓✓✓✗✗✗✗✗
`vesta-app`✓✗✓✗✓✓✓✓✓✗
`virtualsprotocol-app`✗✗✓✓✓✗✗✗✗✗
`volmex-app`✗✗✓✓✓✓✓✓✓✗
`voltz-app`✗✗✓✓✓✓✓✓✓✗
`wombat-dex`✗✓✓✓✓✓✓✓✓✓
`x2y2-app`✗✓✓✓✓✓✓✓✓✗
`xoxno-app`✗✓✓✓✓✓✓✗✗✗
`xswap-dex`✓✓✓✓✓✗✓✓✓✓
`zerion-app`✗✓✓✗✓✓✓✓✓✗
`zerofi`✗✓✗✗✗✗✓✓✓✓
`zerolend-lending`✓✗✓✓✓✗✓✓✓✗
`zkswap-dex`✓✓✗✗✗✓✓✓✓✓
`zksyncerabridge`✓✗✓✗✓✗✓✓✓✗
`zyberswap-dex`✓✓✓✓✓✓✓✓✓✓
**App × chain** An app's figures split by the chain they were earned on, such as `uniswap-v3` on `arbitrum`. One row per app and chain per day.
App Trading volume
`aave-v3`✗
`aave-v4`✗
`aerodrome-slipstream`✓
`aerodrome-stable`✓
`aerodrome-volatile`✓
`alphaq`✓
`aperture-swap-v1`✓
`apeswap-dex`✓
`balancer-dex`✓
`bancor-dex`✓
`beethoven-dex`✓
`bisonfi`✓
`biswap-dex`✓
`blackhole-dex`✓
`byreal`✓
`camelot-dex`✓
`chainflip-dex`✓
`chainlink-ccip`✗
`circle-cctp-v1`✗
`circle-cctp-v2`✗
`circle-stablefx`✓
`curve-dex`✓
`dfx-dex`✓
`dodo-dex`✓
`dreamcash-perps`✗
`entropyio-perps`✗
`equalizer-dex`✓
`etherex-dex`✓
`euler-swap`✓
`fathom-dex`✓
`felix-perps`✗
`goonfi`✓
`honeypop-dex`✓
`hyena-perps`✗
`hyperliquid-outcome-markets`✓
`hyperliquid-perps`✗
`hyperliquid-spot`✓
`instadapp-fluid-dex`✓
`instadapp-fluid-dex-lite`✓
`integral-dex`✓
`kinetiq-perps`✗
`kyber-dex`✓
`layerzero-v1`✗
`layerzero-v2`✗
`maverick-dex`✓
`meteora-launchpad`✓
`meteora-liquidity-pools`✓
`metric-v1`✓
`metric-v2`✓
`okutrade-dex`✓
`orca-whirlpools`✓
`pancakeswap-v2`✓
`pancakeswap-v3`✓
`pangolin-dex`✓
`paragon-perps`✗
`pharaoh-dex`✓
`projectx`✓
`pumpfun-amm`✓
`pumpfun-launchpad`✓
`quickswap-v2`✓
`quickswap-v3`✓
`ramses-dex`✓
`raydium-clmm`✓
`raydium-cpmm`✓
`raydium-launchlab`✓
`raydium-openbook`✓
`raydium-stable-swap`✓
`shadowexchange-concentrated-liquidity`✓
`shadowexchange-constant-product`✓
`solidlizard-dex`✓
`spookyswap-dex`✓
`sunswap-v1`✓
`sunswap-v2`✓
`sunswap-v3`✓
`sunswap-v4`✓
`sushiswap-dex`✓
`syncswap-dex`✓
`temple`✓
`tesserav`✓
`thena-dex`✓
`thruster-clamm`✓
`thruster-classic`✓
`traderjoe-dex`✓
`tradexyz-perps`✗
`uniswap-v2`✓
`uniswap-v3`✓
`uniswap-v4`✓
`velodrome-dex`✓
`ventuals-perps`✗
`versedex-dex`✓
`wombat-dex`✓
`xswap-dex`✓
`zerofi`✓
`zkswap-dex`✓
`zyberswap-dex`✓
## Tables [Metrics](/docs/catalog/apps/metrics) holds the daily table schemas at app and app-and-chain grain, and example queries. [Registry](/docs/catalog/apps/registry) holds the identity table. # Metrics Source: https://tokenterminal.com/docs/catalog/apps/metrics TVL, Fees, Revenue, Token incentives, Active users and sector-specific volume per app and per app on one chain. TVL, trading volume, fees, revenue, token incentives and active users. One row per thing per day, at two grains: app, and app and chain. ## Tables > [!NOTE] > > Daily DEX pool trading volume, Hyperliquid trading contributions and bridge transfer volumes cover closed UTC days and follow the availability cutoff of each contributing chain. **App** One row per app per day. Where a table has a `provenance` column, `ladder` marks a figure summed from the app's own markets and pools and `projected` the project's series attributed to the app.
Table Value column What it holds
`metrics_apps.tvl_daily` `tvl` Total value locked in the app.
`metrics_apps.trading_volume_daily` `trading_volume` Value of trades executed by the app, measured on the quote leg at execution price.
`metrics_apps.active_loans_daily` `active_loans` USD value of open loans (outstanding borrows) across the app's lending markets.
`metrics_apps.assets_staked_daily` `assets_staked` USD value of assets staked with the app.
`metrics_apps.fees_daily` `fees` Fees paid by users of the app across every chain it runs on.
`metrics_apps.fees_supply_side_daily` `fees_supply_side` Fees the app passed through to builders and, on HIP-3 markets, to market deployers.
`metrics_apps.revenue_daily` `revenue` Fees the app retained across every chain it runs on.
`metrics_apps.token_incentives_daily` `token_incentives` Value of tokens the app distributed as incentives.
`metrics_apps.outstanding_supply_daily` `outstanding_supply` USD value of borrowed principal outstanding.
`metrics_apps.bridged_supply_daily` `bridged_supply` USD value of the app's stablecoins held outside the chain they were issued on.
`metrics_apps.buybacks_daily` `buybacks` USD value of the app's own tokens repurchased from the market.
`metrics_apps.bridge_deposits_daily` `bridge_deposits` USD value of assets held in the app's bridge contracts on the main chain.
`metrics_apps.transaction_volume_daily` `transaction_volume` USD value of transactions processed by the app.
`metrics_apps.open_interest_daily` `open_interest` USD notional value of all open positions on the app's derivatives markets.
`metrics_apps.trade_count_daily` `trade_count` Number of trades executed on the app.
`metrics_apps.cost_of_revenue_daily` `cost_of_revenue` Direct supply-side cost of the app's revenue.
`metrics_apps.capital_deployed_daily` `capital_deployed` USD value of user deposits the app has allocated into investments.
`metrics_apps.flash_loan_volume_daily` `flash_loan_volume` USD value of flash loans taken from the app.
`metrics_apps.expenses_daily` `expenses` What the app spent, in USD: cost of revenue, token incentives and operating expenses, wherever each is reported onchain.
`metrics_apps.operating_expenses_daily` `operating_expenses` Onchain operating expenses of the app, excluding token incentives.
`metrics_apps.liquidation_volume_daily` `liquidation_volume` USD value of debt covered in the app's liquidations.
`metrics_apps.tradeable_pair_count_daily` `tradeable_pair_count` Number of token pairs available for trading on the app.
`metrics_apps.tradeable_asset_count_daily` `tradeable_asset_count` Number of tokens tradeable on the app.
`metrics_apps.daily_active_users_daily` `daily_active_users` Distinct users active on the app per day.
`metrics_apps.weekly_active_users_daily` `weekly_active_users` Distinct users active on the app over a trailing week.
`metrics_apps.monthly_active_users_daily` `monthly_active_users` Distinct users active on the app over a trailing month.
**App × chain** One row per app and chain per day. Each figure sits on the chain it comes from. Where a table has a `provenance` column, `ladder` marks a figure summed from the app's own markets and pools on that chain and `projected` the project's series attributed to the app.
Table Value column What it holds
`metrics_apps_by_chain.tvl_daily` `tvl` Total value locked in the app.
`metrics_apps_by_chain.trading_volume_daily` `trading_volume` Value of trades executed by the app, measured on the quote leg at execution price.
`metrics_apps_by_chain.active_loans_daily` `active_loans` USD value of open loans (outstanding borrows) across the app's lending markets.
`metrics_apps_by_chain.fees_daily` `fees` Fees paid by users of the app across every chain it runs on.
`metrics_apps_by_chain.fees_supply_side_daily` `fees_supply_side` Fees the app passed through to builders and, on HIP-3 markets, to market deployers.
`metrics_apps_by_chain.revenue_daily` `revenue` Fees the app retained across every chain it runs on.
`metrics_apps_by_chain.token_incentives_daily` `token_incentives` Value of tokens the app distributed as incentives, on one chain.
`metrics_apps_by_chain.outstanding_supply_daily` `outstanding_supply` USD value of borrowed principal outstanding, on one chain.
`metrics_apps_by_chain.bridge_deposits_daily` `bridge_deposits` USD value of assets held in the app's bridge contracts on the main chain, on one chain.
`metrics_apps_by_chain.trade_count_daily` `trade_count` Number of trades executed on the app, on one chain.
`metrics_apps_by_chain.tradeable_asset_count_daily` `tradeable_asset_count` Number of tokens tradeable on the app, on one chain.
`metrics_apps_by_chain.tradeable_pair_count_daily` `tradeable_pair_count` Number of token pairs available for trading on the app, on one chain.
`metrics_apps_by_chain.cost_of_revenue_daily` `cost_of_revenue` Direct supply-side cost of the app's revenue, on one chain.
`metrics_apps_by_chain.capital_deployed_daily` `capital_deployed` USD value of user deposits the app has allocated into investments, on one chain.
`metrics_apps_by_chain.bridged_supply_daily` `bridged_supply` USD value of the app's stablecoins held outside the chain they were issued on, on one chain.
`metrics_apps_by_chain.assets_staked_daily` `assets_staked` USD value of assets staked with the app, on one chain.
`metrics_apps_by_chain.flash_loan_volume_daily` `flash_loan_volume` USD value of flash loans taken from the app, on one chain.
`metrics_apps_by_chain.open_interest_daily` `open_interest` USD notional value of all open positions on the app's derivatives markets, on one chain.
`metrics_apps_by_chain.expenses_daily` `expenses` What the app spent on the chain, in USD: cost of revenue, token incentives and operating expenses.
`metrics_apps_by_chain.operating_expenses_daily` `operating_expenses` Onchain operating expenses of the app, excluding token incentives, on one chain.
`metrics_apps_by_chain.transaction_volume_daily` `transaction_volume` USD value of transactions processed by the app, on one chain.
`metrics_apps_by_chain.buybacks_daily` `buybacks` USD value of the app's own tokens repurchased from the market, on one chain.
`metrics_apps_by_chain.liquidation_volume_daily` `liquidation_volume` USD value of debt covered in the app's liquidations, on one chain.
## Sample queries **App** Each measure is its own table, so a row with all three is a join on `app_id` and `timestamp`. A `full join` keeps a day that only one of the tables has a figure for. ```sql theme={null} with fees as ( select timestamp, fees from `metrics_apps.fees_daily` where app_id = 'uniswap-v3' and timestamp >= timestamp('2026-06-01') ), revenue as ( select timestamp, revenue from `metrics_apps.revenue_daily` where app_id = 'uniswap-v3' and timestamp >= timestamp('2026-06-01') ), tvl as ( select timestamp, tvl from `metrics_apps.tvl_daily` where app_id = 'uniswap-v3' and timestamp >= timestamp('2026-06-01') ) select timestamp, fees.fees, revenue.revenue, tvl.tvl from fees full join revenue using (timestamp) full join tvl using (timestamp) order by timestamp ``` **App × chain** An app's chain rows add back to its app row for the same day. `tvl` is a day-end balance, so read one day across chains rather than a range. ```sql theme={null} select chain_id, tvl from `metrics_apps_by_chain.tvl_daily` where app_id = 'aave-v3' and timestamp = timestamp('2026-08-01') order by tvl desc ``` **Apps of one project** The registry supplies the name and the daily table supplies the figure, joined on `app_id`. Filtering `project_id` on the daily table keeps the scan on one project. ```sql theme={null} select apps.app_id, apps.name, sum(daily.fees) as fees from `metrics_apps.fees_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.project_id = 'hyperliquid' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-08') group by apps.app_id, apps.name order by fees desc ``` **Balance rollup** `tvl` stands at day end, so the week's figure is the last day's value and the summed column counts the same locked value seven times. `daily_active_users` is a distinct count and behaves the same way: read the day you want, or read `weekly_active_users` for the week. ```sql theme={null} select array_agg(tvl order by timestamp desc limit 1)[offset(0)] as tvl, sum(tvl) as tvl_summed from `metrics_apps.tvl_daily` where app_id = 'aave-v3' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') ``` # Registry Source: https://tokenterminal.com/docs/catalog/apps/registry App names, the project that runs each one, and market sectors. The identity table behind every app figure. Every metric joins to it, and [Coverage](/docs/catalog/apps/index) introduces the grain. ## Columns
Column Type Description
`app_id` `STRING` Identifier of the app. Every table that mentions an app joins on this.
`project_id` `STRING` Project that runs the app. Joins `dimensions.projects`.
`name` `STRING` Display name.
`market_sectors` `ARRAY` Every market sector tag on the app.
`primary_market_sector` `STRING` The first element of `market_sectors`. One value per row.
`created_at` `TIMESTAMP` When the app was added to the registry.
## Sample queries **Apps of one project** `project_id` is the same key the daily tables use, and one project has several rows here. ```sql theme={null} select app_id, name, market_sectors, created_at from `dimensions.apps` where project_id = 'hyperliquid' order by app_id ``` **Apps by sector** `primary_market_sector` keeps one row per app however the tagging changes later. `market_sectors` is a list, so joining through `unnest(market_sectors)` yields one row per tag and any total taken off it comes out too high. ```sql theme={null} select primary_market_sector, count(*) as apps from `dimensions.apps` group by primary_market_sector order by apps desc ``` **Apps with their project** The app's name lives here and the project's in `dimensions.projects`, so a row naming both is a join on `project_id`. ```sql theme={null} select apps.app_id, apps.name, projects.name as project_name from `dimensions.apps` as apps join `dimensions.projects` as projects using (project_id) where apps.primary_market_sector = 'lending' order by project_name, apps.app_id ``` # Asset management Source: https://tokenterminal.com/docs/catalog/asset-management Every managed vault: deposits, value locked and returns, across every protocol. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An asset management protocol pools deposits into vaults that run a strategy. The vertical lands with a vault registry and daily value, flows and returns per vault. # Balance changes Source: https://tokenterminal.com/docs/catalog/assets/balance-changes Who holds a tokenized asset, day by day, and whether the numbers add up. Two tables sit behind every tokenized-asset cap table, and they are read together. `facts_asset_tokens.balance_changes_daily` records one row for each day, each deployment and each holding account whose balance moved, with that day's net change, in whole token units. [Balances](/docs/catalog/assets/balances) holds each account's balance as of the latest day. The [balance functions](/docs/catalog/tokens/balances) add these rows up at query time. ## Sparse, so a balance is an accumulation A day with no row means the balance did not move that day, not that it was zero. So a holder's balance on a date is the sum of every row at or before that date, never a lookup of that date. Ask for one day in isolation and you get that day's movement, which is rarely the question. The [functions](/docs/catalog/tokens/balances) exist so this is not something every reader has to get right. ## Read the coverage and attribution before the numbers One thing gates a cap table: whether a ledger summed from transfer legs can describe the deployment at all. Coverage answers that per deployment, and it answers about the mechanism rather than about activity. So a deployment with no rows here is one of two things, and they are not the same. Either coverage refuses it, in which case it names the reason, or coverage serves it and the deployment has simply never been transferred. An asset issued but never moved has an empty cap table, which is the correct answer rather than a missing one. The curated [functions](/docs/catalog/tokens/balances) read coverage and refuse with that reason instead of returning a figure they cannot stand behind. ## Tables **Balance changes** `facts_asset_tokens.balance_changes_daily` records one row per `(timestamp, chain_id, token_address, account_address)`.
Column Type Description
`timestamp` `TIMESTAMP` Day the balance moved. The partition column.
`chain_id` `STRING` Chain the deployment sits on.
`asset_id` `STRING` Asset the deployment belongs to.
`token_id` `STRING` Key of the deployment, formatted `{token_address}-{chain_id}`.
`token_address` `STRING` Contract address of the deployment. Filter this and `chain_id` together.
`account_address` `STRING` The chain's native holding account: a wallet on EVM chains, a token account on Solana.
`account_owner` `STRING` The holder. Equal to `account_address` where the chain does not distinguish them, and the wallet behind the token account where it does. Group by this for a cap table. Group by `account_address` instead and one wallet's several Solana token accounts each count as a separate holder.
`balance_delta` `BIGNUMERIC` Net balance movement that day, signed, in whole token units.
## What is not here, and why The families currently declared out, and absent from this table rather than approximated: * **Chains without a balance arm.** Every asset on them, whatever its mechanics. * **Assets whose balances revalue without moving.** A rebasing token grows every holder at once with no transfer to observe, so a ledger summed from transfer legs holds the value each transfer had and never revalues it. * **Assets hand-declared out with measured evidence.** Two cases are worth knowing about generally: a chain that migrated balances between token standards without emitting the credit, and a token whose confidential transfers hide the amount from the event that would record it. Two mechanisms are worth naming, because both are refused rather than approximated. A Solana **scaled UI amount** multiplies a raw balance by a multiplier the mint can change, and an **interest-bearing rate** accrues into the holder-facing amount with no transfer to observe. A Dinari dShare revalues the same way, through a multiplier the issuer writes. In every case the balance moves without a transfer, so a ledger summed from transfer legs cannot see it, and the deployment is declared out until a model can convert it. ## Notes * Filter `token_address` and `chain_id` together. They are the cluster keys; a filter on `token_id` alone reaches neither. * `balance_delta` is `BIGNUMERIC` throughout, deliberately. Float arithmetic leaves dust where a closed position should read exactly zero, and dust counts as a holder. # Balances Source: https://tokenterminal.com/docs/catalog/assets/balances Who holds a tokenized asset now, and what each holding is worth. One row per account holding a tokenized asset deployment, as of the latest day for that chain. `balance` is the holding in whole token units, over the same circulating holders as the circulating market cap. ## Columns
Column Type Description
`timestamp`TIMESTAMPDay the balance is as of: the latest day for the chain.
`chain_id`STRINGChain the deployment sits on.
`asset_id`STRINGAsset the deployment belongs to; joins `dimensions.assets`.
`token_id`STRINGKey of the deployment, formatted `{token_address}-{chain_id}`.
`token_address`STRINGContract address of the deployment. Cluster key with `chain_id`: filter both together to read one deployment.
`account_address`STRINGThe chain's native holding account: a wallet on EVM chains, a token account on Solana.
`account_owner`STRINGThe holder. Equal to `account_address` where the chain does not distinguish them, and the wallet behind the token account where it does. Group by this for a cap table.
`balance`BIGNUMERICEnd-of-day balance in whole token units.
`balance_usd`FLOAT64`balance` in USD at that day's price; null where the deployment has no price that day.
## Sample queries **Largest holders of one deployment** The filter on `chain_id` and `token_address` reads one deployment's rows and nothing else. A Solana wallet holds through several token accounts, so the query sums per `account_owner`. ```sql theme={null} select balances.account_owner, sum(balances.balance) as balance, sum(balances.balance_usd) as balance_usd from `facts_asset_tokens.balances_latest` as balances where balances.chain_id = 'ethereum' and balances.token_address = '0x7712c34205737192402172409a8f7ccef8aa2aec' group by balances.account_owner order by balance desc limit 25 ``` **One asset across its chains** `asset_id` groups every deployment of one asset. Each chain's rows are as of that chain's own `timestamp`. ```sql theme={null} select balances.chain_id, max(balances.timestamp) as as_of, count(distinct balances.account_owner) as holders, sum(balances.balance) as balance, sum(balances.balance_usd) as balance_usd from `facts_asset_tokens.balances_latest` as balances where balances.asset_id = 'buidl' group by balances.chain_id order by balance_usd desc ``` **Holdings by asset type** `asset_id` joins `dimensions.assets`, which has the asset type and issuer. `balance_usd` is null on unpriced holdings, and the sum skips them. ```sql theme={null} select assets.asset_type, count(distinct balances.asset_id) as asset_count, sum(balances.balance_usd) as balance_usd from `facts_asset_tokens.balances_latest` as balances inner join `dimensions.assets` as assets on assets.asset_id = balances.asset_id group by assets.asset_type order by balance_usd desc ``` # Assets Source: https://tokenterminal.com/docs/catalog/assets/index Assets, the chains each one is issued on, and what each one tracks. An asset is a financial instrument issued onchain: a stablecoin such as `usdc`, a tokenized money-market fund such as `buidl`, a tokenized commodity such as `paxg`. One asset covers every contract that represents it, on every chain it reaches, and the issuer behind it. One contract on one chain is a [token](/docs/catalog/tokens/index), and an asset groups every token that stands for the same instrument. [Stablecoins](/docs/catalog/stablecoins/index) and [Real-world assets](/docs/catalog/real-world-assets/index) read these tables, each for its own asset types. ## Coverage A tab per grain. Each tab says what one row is, and a tick marks every issuer that reports the measure at that grain. **Asset** An asset is a financial instrument issued onchain, such as `usdc`. One row per asset per day.
Issuer Price Circulating market cap Transfer volume Daily active users Weekly active users Monthly active users Holders Mints Off-peg deviation Redemptions Transfer count
`22xfund`✗✗✗✓✓✓✓✗✗✗✓
`3adao`✓✓✓✓✓✓✓✓✓✓✓
`3jane`✓✓✓✓✓✓✓✓✗✓✓
`a7a5`✓✓✓✓✓✓✓✓✗✓✓
`aave`✓✓✓✓✓✓✓✓✓✓✓
`abt`✓✓✓✓✓✓✓✓✗✓✓
`accountable`✓✓✓✓✓✓✓✓✗✓✓
`aegis`✗✗✗✓✓✓✗✗✗✗✗
`agant`✓✓✓✓✓✓✓✓✓✓✓
`agora`✓✓✓✓✓✓✓✓✓✓✓
`aktionariat`✗✗✗✓✓✓✓✗✗✗✓
`alchemix`✓✓✓✓✓✓✓✓✓✓✓
`alloyx`✗✗✗✓✓✓✓✗✗✗✓
`allunity`✓✓✓✓✓✓✓✓✓✓✓
`alphaledger`✗✗✗✓✓✓✓✗✗✗✓
`alphapartners`✓✓✓✓✓✓✓✓✓✓✓
`anchoragedigital`✓✓✓✓✓✓✓✓✓✓✓
`anchored`✓✓✓✓✓✓✓✓✗✓✓
`anchoredcoins`✓✓✓✓✓✓✓✓✓✓✓
`angle`✓✓✓✓✓✓✓✓✓✓✓
`anzen`✓✓✓✓✓✓✓✓✓✓✓
`anzens`✓✓✓✓✓✓✓✓✓✓✓
`apacx`✓✓✓✓✓✓✓✓✓✓✓
`apyx`✓✓✓✓✓✓✓✓✓✓✓
`archax`✗✗✗✓✓✓✗✗✗✗✓
`archblock`✓✓✓✓✓✓✓✓✓✓✓
`arcus`✓✓✓✓✓✓✓✓✓✓✓
`aryze`✓✓✓✓✓✓✓✓✓✓✓
`asseto`✗✗✗✓✓✓✓✗✗✗✓
`aster`✓✓✓✓✓✓✓✓✓✓✓
`astera`✓✓✓✓✓✓✓✓✓✓✓
`audx`✓✓✓✓✓✓✓✓✓✓✓
`aurus`✗✗✗✓✓✓✓✗✗✗✓
`australiandigitaldollar`✓✓✓✓✓✓✓✓✓✓✓
`auxite`✗✗✗✓✓✓✓✗✗✗✓
`avalonfinance`✗✗✗✓✓✓✗✗✗✗✗
`avantprotocol`✓✓✓✓✓✓✓✓✓✓✓
`backed`✓✓✓✓✓✓✓✓✗✓✓
`backpack`✓✓✓✓✓✓✓✓✗✓✓
`balancer`✗✗✗✓✓✓✗✗✗✗✗
`berachain`✓✓✓✓✓✓✓✓✓✓✓
`bilira`✓✓✓✓✓✓✓✓✓✓✓
`binance`✓✓✓✓✓✓✓✓✓✓✓
`bitbond`✓✓✓✓✓✓✓✓✗✗✓
`bitfi`✗✗✗✓✓✓✗✗✗✗✗
`bitgo`✓✓✓✓✓✓✓✓✗✓✓
`bitso`✓✓✓✓✓✓✓✓✓✓✓
`blox`✓✓✓✓✓✓✓✓✗✓✓
`bnymellon`✓✓✓✗✗✗✓✓✗✗✓
`bralexyz`✗✗✗✓✓✓✗✗✗✗✗
`braza`✓✓✓✓✓✓✓✓✓✓✓
`bridge`✓✓✓✓✓✓✓✓✓✓✓
`bucket`✓✓✓✓✓✓✓✓✓✓✓
`capapp`✓✓✓✓✓✓✓✓✓✓✓
`cashlink`✗✗✗✓✓✓✓✗✗✗✓
`centrifuge`✓✓✓✓✓✓✓✓✗✓✓
`cfxlabs`✓✓✓✓✓✓✓✓✓✓✓
`circle`✓✓✓✓✓✓✓✓✓✓✓
`cod3x`✓✓✓✓✓✓✓✓✓✓✓
`coinbase`✓✓✓✓✓✓✓✓✗✓✓
`coinshift`✓✓✓✓✓✓✓✓✗✓✓
`colbfinance`✗✗✗✓✓✓✗✗✗✗✗
`comtech`✓✓✓✓✓✓✓✓✗✓✓
`cosimo`✗✗✗✓✓✓✓✗✗✗✓
`creditagricole`✓✓✓✓✓✓✓✓✓✓✓
`cropto`✓✓✓✓✓✓✓✓✗✗✓
`crown`✓✓✓✓✓✓✓✓✓✓✓
`ctrlalt`✗✗✗✓✓✓✓✗✗✗✓
`curve`✓✓✓✓✓✓✓✓✓✓✓
`cygnusfinance`✓✓✓✓✓✓✓✓✓✓✓
`czodiac`✗✗✗✓✓✓✗✗✗✗✗
`defi`✗✗✗✓✓✓✗✗✗✗✗
`defifranc`✓✓✓✓✓✓✓✓✓✓✓
`deuro`✓✓✓✓✓✓✓✓✓✓✓
`digift`✓✓✓✓✓✓✓✓✗✓✓
`digishare`✓✓✓✓✓✓✓✓✗✗✓
`dinari`✓✓✓✓✓✓✓✓✗✓✓
`djed`✗✗✗✓✓✓✗✗✗✗✗
`dtrinity`✓✓✓✓✓✓✓✓✓✓✓
`ebisu`✓✓✓✓✓✓✓✓✓✓✓
`elixir`✗✗✗✓✓✓✗✗✗✗✗
`ethena`✓✓✓✓✓✓✓✓✓✓✓
`etherfi`✓✓✓✓✓✓✓✓✗✓✓
`etherfuse`✓✓✓✓✓✓✓✓✗✓✓
`evident`✓✓✓✓✓✓✓✓✗✓✓
`falconfinance`✓✓✓✓✓✓✓✓✓✓✓
`fathom`✓✓✓✓✓✓✓✓✓✓✓
`fd121limited`✓✓✓✓✓✓✓✓✓✓✓
`fei`✓✓✓✓✓✓✓✓✗✓✓
`felix`✓✓✓✓✓✓✓✓✓✓✓
`fidelity`✓✓✓✓✓✓✓✓✓✓✓
`figure`✗✗✗✓✓✓✗✗✗✗✗
`finest`✗✗✗✓✓✓✗✗✗✗✗
`fireblocks`✓✓✓✓✓✓✓✓✓✓✓
`floatprotocol`✓✓✓✓✓✓✓✓✗✓✓
`flow`✓✓✓✓✓✓✓✓✓✓✓
`flyingtulip`✓✓✓✓✓✓✓✓✓✓✓
`fortetechsolutions`✓✗✗✗✗✗✗✗✓✗✗
`frankencoin`✓✓✓✓✓✓✓✓✓✓✓
`franklintempleton`✓✓✓✓✓✓✓✓✗✓✓
`frax`✓✓✓✓✓✓✓✓✗✓✓
`fraxstablecoin`✓✓✓✓✓✓✓✓✓✓✓
`fxprotocol`✓✓✓✓✓✓✓✓✓✓✓
`gaib`✓✓✓✓✓✓✓✓✗✓✓
`galaxydigital`✗✗✗✓✓✓✓✗✗✗✓
`gateio`✗✗✗✓✓✓✗✗✗✗✗
`gauntlet`✓✓✓✓✓✓✓✓✗✓✓
`gemini`✓✓✓✓✓✓✓✓✓✓✓
`glodollar`✓✓✓✓✓✓✓✓✓✓✓
`gmotrust`✓✓✓✓✓✓✓✓✓✓✓
`goal3`✓✓✓✓✓✓✓✓✓✓✓
`goldfishgold`✓✓✓✓✓✓✓✓✗✓✓
`gravita`✓✓✓✓✓✓✓✓✓✓✓
`groma`✓✓✓✓✓✓✓✓✗✓✓
`gyroscope`✗✗✗✓✓✓✓✗✗✗✓
`hastra`✓✓✓✓✓✓✓✓✗✓✓
`homecoin`✗✗✗✓✓✓✗✗✗✗✗
`hydradx`✓✓✗✗✗✗✗✗✓✗✗
`hylo`✓✓✓✓✓✓✓✓✓✓✓
`hyperbeat`✓✓✓✓✓✓✓✓✗✓✓
`hyperstable`✓✓✓✓✓✓✓✓✓✓✓
`hyperwave`✓✓✓✓✓✓✓✓✗✓✓
`indigo`✓✓✓✓✓✓✓✓✓✓✓
`infinifi`✓✓✓✓✓✓✓✓✓✓✓
`interestprotocol`✗✗✗✓✓✓✗✗✗✗✗
`inversefinance`✓✓✓✓✓✓✓✓✓✓✓
`iotube`✓✓✓✓✓✓✓✓✗✓✓
`ironbank`✓✓✓✓✓✓✓✓✓✓✓
`isc`✓✓✓✓✓✓✓✓✗✓✓
`jpmorgan`✓✓✓✓✓✓✓✓✗✓✓
`jpycoin`✓✓✓✓✓✓✓✓✓✓✓
`jupiter`✓✓✓✓✓✓✓✓✓✓✓
`justoken`✓✓✓✓✓✓✓✓✗✓✓
`k3capital`✗✗✗✓✓✓✓✗✗✗✓
`kaio`✗✗✗✓✓✓✓✗✗✗✓
`kelpdao`✓✓✓✓✓✓✓✓✗✓✓
`kinesis`✓✓✓✓✓✓✓✓✗✗✓
`kinka`✓✓✓✓✓✓✓✓✗✓✓
`levelprotocol`✓✓✓✓✓✓✓✓✓✓✓
`libeara`✓✓✓✓✓✓✓✓✗✓✓
`lido`✓✓✓✓✓✓✓✓✗✓✓
`liquity`✓✓✓✓✓✓✓✓✓✓✓
`listadao`✓✓✓✓✓✓✓✓✓✓✓
`lybra`✓✓✓✓✓✓✓✓✗✓✓
`mainstreet`✓✓✓✓✓✓✓✓✓✓✓
`makerdao`✓✓✓✓✓✓✓✓✓✓✓
`mantle`✓✓✓✓✓✓✓✓✗✓✓
`maple`✓✓✓✓✓✓✓✓✗✓✓
`matrixdock`✓✓✓✓✓✓✓✓✗✓✓
`membranefinance`✓✓✓✓✓✓✓✓✓✓✓
`mento`✓✓✓✓✓✓✓✓✗✓✓
`mentolabs`✓✓✓✓✓✓✓✓✓✓✓
`mercadobitcoin`✗✗✗✓✓✓✓✗✗✗✓
`mesh`✓✓✓✓✓✓✓✗✗✗✓
`metamask`✓✓✓✓✓✓✓✓✓✓✓
`metawealth`✓✓✓✓✓✓✓✓✗✓✓
`metronome`✓✓✓✓✓✓✓✓✓✓✓
`mezo`✗✗✗✓✓✓✗✗✗✗✗
`midas`✓✓✓✓✓✓✓✓✗✓✓
`mimocapital`✓✓✓✓✓✓✓✓✓✓✓
`mnee`✓✓✓✓✓✓✓✓✓✓✓
`moet`✓✓✓✓✓✓✓✓✓✓✓
`monerium`✓✓✓✓✓✓✓✓✓✓✓
`moneta`✓✓✓✓✓✓✓✓✓✓✓
`moneyonchain`✓✓✓✓✓✓✓✓✓✓✓
`monolithmarket`✗✗✗✓✓✓✗✗✗✗✗
`moola`✓✓✓✓✓✓✓✓✗✓✓
`morpho`✓✓✓✓✓✓✓✓✗✓✓
`mountainprotocol`✓✓✓✓✓✓✓✓✗✓✓
`mstable`✗✗✗✓✓✓✓✗✗✗✓
`mudigital`✗✗✗✓✓✓✗✗✗✗✗
`multipli`✓✓✓✓✓✓✓✓✓✓✓
`mynth`✗✗✗✓✓✓✓✗✗✗✓
`mzero`✓✓✓✓✓✓✓✓✓✓✓
`nativemarkets`✓✓✓✓✓✓✓✓✓✓✓
`nereusfinance`✗✗✗✓✓✓✗✗✗✗✗
`nest`✓✓✓✓✓✓✓✓✗✓✓
`neutrl`✓✓✓✓✓✓✓✓✓✓✓
`newrails`✓✓✓✓✓✓✓✓✓✓✓
`noon`✓✓✓✓✓✓✓✓✓✓✓
`nyala`✓✓✓✓✓✓✓✓✗✗✓
`okx`✓✓✓✓✓✓✓✓✗✓✓
`ondo`✓✓✓✓✓✓✓✓✓✓✓
`onre`✓✓✓✓✓✓✓✓✗✓✓
`openedendigital`✓✓✓✓✓✓✓✓✗✓✓
`openstock`✗✗✗✓✓✓✓✗✗✗✓
`opentrade`✓✓✓✓✓✓✓✓✗✓✓
`origin`✓✓✓✓✓✓✓✓✗✓✓
`oro`✓✓✓✓✓✓✓✓✗✓✓
`palmusd`✓✓✓✓✓✓✓✓✓✓✓
`pareto`✓✓✓✓✓✓✓✓✓✓✓
`paxos`✓✓✓✓✓✓✓✓✓✓✓
`paytrie`✓✓✓✓✓✓✓✓✓✓✓
`perena`✓✓✓✓✓✓✓✓✓✓✓
`phantom`✓✓✓✓✓✓✓✓✓✓✓
`piku`✓✓✓✓✓✓✓✓✗✓✓
`pineapple`✗✓✗✓✓✓✓✗✗✗✓
`pleasinggold`✓✓✓✓✓✓✓✓✗✓✓
`plumenetwork`✗✗✗✓✓✓✗✗✗✗✗
`polymarket`✓✓✓✓✓✓✓✓✓✓✓
`prestocks`✓✓✓✓✓✓✓✓✗✓✓
`prismafinance`✓✓✓✓✓✓✓✓✓✓✓
`protos`✗✗✗✓✓✓✓✗✗✗✓
`quantoz`✓✓✓✓✓✓✓✓✓✓✓
`raac`✓✓✓✓✓✓✓✓✓✓✓
`raft`✗✗✗✓✓✓✗✗✗✗✗
`re`✓✓✓✓✓✓✓✓✗✓✓
`reality`✓✓✓✓✓✓✓✓✗✓✓
`realtyx`✓✓✓✓✓✓✓✓✗✗✓
`redswan`✓✗✗✗✗✗✗✗✗✗✗
`reental`✓✓✓✓✓✓✓✓✗✓✓
`reflexer`✓✓✓✓✓✓✓✓✗✓✓
`remora`✓✓✓✓✓✓✓✓✗✓✓
`republicnote`✓✓✓✓✓✓✓✓✗✗✓
`reserve`✓✓✓✓✓✓✓✓✓✓✓
`reservoirxyz`✓✓✓✓✓✓✓✓✓✓✓
`resolv`✓✓✓✓✓✓✓✓✗✓✓
`resupply`✓✓✓✓✓✓✓✓✓✓✓
`ribdigital`✓✓✓✓✓✓✓✓✓✓✓
`rif`✓✓✓✓✓✓✓✓✓✓✓
`ringsprotocol`✓✓✓✓✓✓✓✓✗✓✓
`ripio`✓✓✓✓✓✓✓✓✓✓✓
`ripplelabs`✓✓✓✓✓✓✓✓✓✓✓
`river`✓✓✓✓✓✓✓✓✓✓✓
`rivool`✓✓✓✓✓✓✓✗✗✗✓
`robinhood`✓✓✓✓✓✓✓✓✗✓✓
`rocketpool`✓✓✓✓✓✓✓✓✗✓✓
`saturn`✓✓✓✓✓✓✓✓✓✓✓
`sbishinseitrust`✓✓✓✓✓✓✓✓✓✓✓
`schumanfinancial`✓✓✓✓✓✓✓✓✓✓✓
`scienceblockchain`✗✗✗✓✓✓✓✗✗✗✓
`scroll`✓✓✓✓✓✓✓✓✓✓✓
`securitize`✓✓✓✓✓✓✓✓✗✓✓
`shift`✓✓✓✓✓✓✓✓✗✓✓
`sivo`✗✗✗✓✓✓✓✗✗✗✓
`smardex`✗✗✗✓✓✓✗✗✗✗✗
`societegenerale`✓✓✓✓✓✓✓✓✓✓✓
`sofi`✓✓✓✓✓✓✓✓✓✓✓
`solayer`✓✓✓✓✓✓✓✓✗✓✓
`solomonlabs`✓✓✓✓✓✓✓✓✓✓✓
`solstice`✓✓✓✓✓✓✓✓✓✓✓
`soulpeg`✓✓✓✓✓✓✓✓✓✓✓
`sovryn`✓✓✓✓✓✓✓✓✓✓✓
`spark`✓✓✓✓✓✓✓✓✗✓✓
`sperax`✓✓✓✓✓✓✓✓✓✓✓
`spicevc`✗✗✗✓✓✓✓✗✗✗✓
`spiko`✓✓✓✓✓✓✓✓✗✓✓
`st0x`✓✓✓✓✓✓✓✓✗✓✓
`stablecoin`✓✓✓✓✓✓✓✓✓✓✓
`stablecorp`✗✗✗✓✓✓✗✗✗✗✗
`stablemint`✗✗✗✓✓✓✗✗✗✗✗
`stableslabs`✗✗✗✓✓✓✗✗✗✗✗
`stablestock`✓✓✓✓✓✓✓✓✗✓✓
`stablr`✓✓✓✓✓✓✓✓✓✓✓
`stakewise`✓✓✓✓✓✓✓✓✗✓✓
`standx`✓✓✓✓✓✓✓✓✓✓✓
`stasis`✓✓✓✓✓✓✓✓✓✓✓
`straitsx`✓✓✓✓✓✓✓✓✓✓✓
`strata`✓✓✓✓✓✓✓✓✗✓✓
`stream`✗✗✗✓✓✓✗✗✗✗✗
`streamex`✓✓✓✓✓✓✓✓✗✓✓
`stusdt`✓✓✓✓✓✓✓✓✗✓✓
`superformlabs`✗✗✗✗✗✗✓✗✗✗✓
`superstate`✓✓✓✓✓✓✓✓✗✓✓
`swarmmarkets`✓✓✓✓✓✓✓✓✗✓✓
`swell`✓✓✓✓✓✓✓✓✗✓✓
`sygnum`✓✓✓✓✓✓✓✓✗✓✓
`synthetix`✓✓✓✓✓✓✓✓✓✓✓
`tangible`✗✗✗✓✓✓✓✗✗✗✓
`tempo`✓✓✓✓✓✓✓✓✓✓✓
`tenbinlabs`✓✓✓✓✓✓✓✓✓✓✓
`tessera`✓✓✓✓✓✓✓✓✗✓✓
`tether`✓✓✓✓✓✓✓✓✓✓✓
`textilecredit`✓✓✓✓✓✓✓✓✗✓✓
`theo`✓✓✓✓✓✓✓✓✗✓✓
`threshold`✗✗✗✓✓✓✗✗✗✗✗
`token`✓✓✓✓✓✓✓✓✓✓✓
`tokengate`✗✗✗✓✓✓✗✗✗✗✗
`tokenisedgbp`✓✓✓✓✓✓✓✓✓✓✓
`tokeny`✓✓✓✓✓✓✓✓✗✓✓
`torifinance`✓✓✓✓✓✓✓✓✓✓✓
`tradable`✓✓✓✓✓✓✓✓✗✓✓
`transfero`✓✓✓✓✓✓✓✓✓✓✓
`trize`✓✓✓✗✗✗✓✓✗✗✓
`tronusdd`✓✓✓✓✓✓✓✓✓✓✓
`trystable`✗✗✗✓✓✓✗✗✗✗✗
`ubs`✗✗✗✓✓✓✗✗✗✗✗
`unitas`✓✓✓✓✓✓✓✓✓✓✓
`unitedstables`✓✓✓✓✓✓✓✓✓✓✓
`unityusd`✓✓✓✓✓✓✓✓✓✓✓
`upshiftfinance`✓✓✓✓✓✓✓✓✗✓✓
`usdai`✓✓✓✓✓✓✓✓✓✓✓
`usdkg`✓✗✓✓✓✓✓✗✓✗✓
`usdm1`✓✓✓✓✓✓✓✓✓✓✓
`usdufinance`✓✓✓✓✓✓✓✓✓✓✓
`usual`✓✓✓✓✓✓✓✓✓✓✓
`venus`✓✓✓✓✓✓✓✓✓✓✓
`vnx`✓✓✓✓✓✓✓✓✓✓✓
`voltprotocol`✗✗✗✓✓✓✗✗✗✗✗
`wisdomtree`✓✓✓✓✓✓✓✓✗✓✓
`worldlibertyfinancial`✓✓✓✓✓✓✓✓✓✓✓
`wspn`✗✗✗✓✓✓✗✗✗✗✗
`wyoming`✓✓✓✓✓✓✓✓✓✓✓
`xstocks`✓✓✓✓✓✓✓✓✗✓✓
`xsy`✓✓✓✓✓✓✓✓✗✓✓
`yala`✗✗✗✓✓✓✗✗✗✗✗
`yamatoprotocol`✓✓✓✓✓✓✓✓✓✓✓
`yeti`✓✓✓✓✓✓✓✓✓✓✓
`yieldfi`✓✓✓✓✓✓✓✓✗✓✓
`yieldnest`✓✓✓✓✓✓✓✓✗✓✓
`yieldoptimizer`✓✓✓✓✓✓✓✓✗✓✓
`yuzu`✓✓✓✓✓✓✓✓✗✓✓
`yuzumoney`✓✓✓✓✓✓✓✓✓✓✓
`zeconomy`✓✓✓✗✗✗✓✓✗✗✓
`zunami`✗✗✗✓✓✓✗✗✗✗✗
**Deployment** A deployment is one asset's token contract on one chain, such as `usdc` on `base`. One row per deployment per day.
Issuer Circulating market cap Transfer volume Daily active users Weekly active users Monthly active users APY Holders Mints Redemptions Transfer count
`22xfund`✗✗✓✓✓✗✓✗✗✓
`3adao`✓✓✓✓✓✗✓✓✓✓
`3jane`✓✓✓✓✓✓✓✓✓✓
`a7a5`✓✓✓✓✓✗✓✓✓✓
`aave`✓✓✓✓✓✓✓✓✓✓
`abt`✓✓✓✓✓✗✓✓✓✓
`accountable`✓✓✓✓✓✓✓✓✓✓
`aegis`✗✗✓✓✓✗✗✗✗✗
`agant`✓✓✓✓✓✗✓✓✓✓
`agora`✓✓✓✓✓✗✓✓✓✓
`aktionariat`✗✗✓✓✓✗✓✗✗✓
`alchemix`✓✓✓✓✓✗✓✓✓✓
`alloyx`✗✗✓✓✓✗✓✗✗✓
`allunity`✓✓✓✓✓✗✓✓✓✓
`alphaledger`✗✗✓✓✓✗✓✗✗✓
`alphapartners`✓✓✓✓✓✗✓✓✓✓
`anchoragedigital`✓✓✓✓✓✗✓✓✓✓
`anchored`✓✓✓✓✓✗✓✓✓✓
`anchoredcoins`✓✓✓✓✓✗✓✓✓✓
`angle`✓✓✓✓✓✓✓✓✓✓
`anzen`✓✓✓✓✓✓✓✓✓✓
`anzens`✓✓✓✓✓✗✓✓✓✓
`apacx`✓✓✓✓✓✗✓✓✓✓
`apyx`✓✓✓✓✓✓✓✓✓✓
`archax`✗✗✓✓✓✗✗✗✗✓
`archblock`✓✓✓✓✓✗✓✓✓✓
`arcus`✓✓✓✓✓✗✓✓✓✓
`aryze`✓✓✓✓✓✗✓✓✓✓
`asseto`✗✗✓✓✓✗✓✗✗✓
`aster`✓✓✓✓✓✗✓✓✓✓
`astera`✓✓✓✓✓✗✓✓✓✓
`audx`✓✓✓✓✓✗✓✓✓✓
`aurus`✗✗✓✓✓✗✓✗✗✓
`australiandigitaldollar`✓✓✓✓✓✗✓✓✓✓
`auxite`✗✗✓✓✓✗✓✗✗✓
`avalonfinance`✗✗✓✓✓✗✗✗✗✗
`avantprotocol`✓✓✓✓✓✗✓✓✓✓
`backed`✓✓✓✓✓✗✓✓✓✓
`backpack`✓✓✓✓✓✗✓✓✓✓
`balancer`✗✗✓✓✓✗✗✗✗✗
`berachain`✓✓✓✓✓✗✓✓✓✓
`bilira`✓✓✓✓✓✗✓✓✓✓
`binance`✓✓✓✓✓✗✓✓✓✓
`bitbond`✓✓✓✓✓✗✓✓✗✓
`bitfi`✗✗✓✓✓✗✗✗✗✗
`bitgo`✓✓✓✓✓✗✓✓✓✓
`bitso`✓✓✓✓✓✗✓✓✓✓
`blox`✓✓✓✓✓✗✓✓✓✓
`bnymellon`✓✓✗✗✗✗✓✓✗✓
`bralexyz`✗✗✓✓✓✗✗✗✗✗
`braza`✓✓✓✓✓✗✓✓✓✓
`bridge`✓✓✓✓✓✗✓✓✓✓
`bucket`✓✓✓✓✓✗✓✓✓✓
`capapp`✓✓✓✓✓✓✓✓✓✓
`cashlink`✗✗✓✓✓✗✓✗✗✓
`centrifuge`✓✓✓✓✓✓✓✓✓✓
`cfxlabs`✓✓✓✓✓✗✓✓✓✓
`circle`✓✓✓✓✓✓✓✓✓✓
`cod3x`✓✓✓✓✓✗✓✓✓✓
`coinbase`✓✓✓✓✓✗✓✓✓✓
`coinshift`✓✓✓✓✓✓✓✓✓✓
`colbfinance`✗✗✓✓✓✗✗✗✗✗
`comtech`✓✓✓✓✓✗✓✓✓✓
`cosimo`✗✗✓✓✓✗✓✗✗✓
`creditagricole`✓✓✓✓✓✗✓✓✓✓
`cropto`✓✓✓✓✓✗✓✓✗✓
`crown`✓✓✓✓✓✗✓✓✓✓
`ctrlalt`✗✗✓✓✓✗✓✗✗✓
`curve`✓✓✓✓✓✓✓✓✓✓
`cygnusfinance`✓✓✓✓✓✗✓✓✓✓
`czodiac`✗✗✓✓✓✗✗✗✗✗
`defi`✗✗✓✓✓✗✗✗✗✗
`defifranc`✓✓✓✓✓✗✓✓✓✓
`deuro`✓✓✓✓✓✗✓✓✓✓
`digift`✓✓✓✓✓✗✓✓✓✓
`digishare`✓✓✓✓✓✗✓✓✗✓
`dinari`✓✓✓✓✓✗✓✓✓✓
`djed`✗✗✓✓✓✗✗✗✗✗
`dtrinity`✓✓✓✓✓✓✓✓✓✓
`ebisu`✓✓✓✓✓✗✓✓✓✓
`elixir`✗✗✓✓✓✗✗✗✗✗
`ethena`✓✓✓✓✓✓✓✓✓✓
`etherfi`✓✓✓✓✓✓✓✓✓✓
`etherfuse`✓✓✓✓✓✗✓✓✓✓
`evident`✓✓✓✓✓✗✓✓✓✓
`falconfinance`✓✓✓✓✓✓✓✓✓✓
`fathom`✓✓✓✓✓✗✓✓✓✓
`fd121limited`✓✓✓✓✓✗✓✓✓✓
`fei`✓✓✓✓✓✗✓✓✓✓
`felix`✓✓✓✓✓✗✓✓✓✓
`fidelity`✓✓✓✓✓✗✓✓✓✓
`figure`✗✗✓✓✓✗✗✗✗✗
`finest`✗✗✓✓✓✗✗✗✗✗
`fireblocks`✓✓✓✓✓✗✓✓✓✓
`floatprotocol`✓✓✓✓✓✗✓✓✓✓
`flow`✓✓✓✓✓✗✓✓✓✓
`flyingtulip`✓✓✓✓✓✗✓✓✓✓
`frankencoin`✓✓✓✓✓✗✓✓✓✓
`franklintempleton`✓✓✓✓✓✗✓✓✓✓
`frax`✓✓✓✓✓✗✓✓✓✓
`fraxstablecoin`✓✓✓✓✓✓✓✓✓✓
`fxprotocol`✓✓✓✓✓✓✓✓✓✓
`gaib`✓✓✓✓✓✗✓✓✓✓
`galaxydigital`✗✗✓✓✓✗✓✗✗✓
`gateio`✗✗✓✓✓✗✗✗✗✗
`gauntlet`✓✓✓✓✓✓✓✓✓✓
`gemini`✓✓✓✓✓✗✓✓✓✓
`glodollar`✓✓✓✓✓✗✓✓✓✓
`gmotrust`✓✓✓✓✓✗✓✓✓✓
`goal3`✓✓✓✓✓✗✓✓✓✓
`goldfishgold`✓✓✓✓✓✗✓✓✓✓
`gravita`✓✓✓✓✓✗✓✓✓✓
`groma`✓✓✓✓✓✗✓✓✓✓
`gyroscope`✗✗✓✓✓✓✓✗✗✓
`hastra`✓✓✓✓✓✓✓✓✓✓
`homecoin`✗✗✓✓✓✗✗✗✗✗
`hydradx`✓✗✗✗✗✗✗✗✗✗
`hylo`✓✓✓✓✓✗✓✓✓✓
`hyperbeat`✓✓✓✓✓✗✓✓✓✓
`hyperstable`✓✓✓✓✓✗✓✓✓✓
`hyperwave`✓✓✓✓✓✗✓✓✓✓
`indigo`✓✓✓✓✓✗✓✓✓✓
`infinifi`✓✓✓✓✓✗✓✓✓✓
`interestprotocol`✗✗✓✓✓✗✗✗✗✗
`inversefinance`✓✓✓✓✓✓✓✓✓✓
`iotube`✓✓✓✓✓✗✓✓✓✓
`ironbank`✓✓✓✓✓✗✓✓✓✓
`isc`✓✓✓✓✓✗✓✓✓✓
`jpmorgan`✓✓✓✓✓✗✓✓✓✓
`jpycoin`✓✓✓✓✓✗✓✓✓✓
`jupiter`✓✓✓✓✓✗✓✓✓✓
`justoken`✓✓✓✓✓✗✓✓✓✓
`k3capital`✗✗✓✓✓✓✓✗✗✓
`kaio`✗✗✓✓✓✗✓✗✗✓
`kelpdao`✓✓✓✓✓✓✓✓✓✓
`kinesis`✓✓✓✓✓✗✓✓✗✓
`kinka`✓✓✓✓✓✗✓✓✓✓
`levelprotocol`✓✓✓✓✓✗✓✓✓✓
`libeara`✓✓✓✓✓✗✓✓✓✓
`lido`✓✓✓✓✓✓✓✓✓✓
`liquity`✓✓✓✓✓✗✓✓✓✓
`listadao`✓✓✓✓✓✗✓✓✓✓
`lybra`✓✓✓✓✓✗✓✓✓✓
`mainstreet`✓✓✓✓✓✗✓✓✓✓
`makerdao`✓✓✓✓✓✓✓✓✓✓
`mantle`✓✓✓✓✓✓✓✓✓✓
`maple`✓✓✓✓✓✓✓✓✓✓
`matrixdock`✓✓✓✓✓✗✓✓✓✓
`membranefinance`✓✓✓✓✓✗✓✓✓✓
`mento`✓✓✓✓✓✗✓✓✓✓
`mentolabs`✓✓✓✓✓✗✓✓✓✓
`mercadobitcoin`✗✗✓✓✓✗✓✗✗✓
`mesh`✓✓✓✓✓✗✓✗✗✓
`metamask`✓✓✓✓✓✗✓✓✓✓
`metawealth`✓✓✓✓✓✗✓✓✓✓
`metronome`✓✓✓✓✓✗✓✓✓✓
`mezo`✗✗✓✓✓✗✗✗✗✗
`midas`✓✓✓✓✓✓✓✓✓✓
`mimocapital`✓✓✓✓✓✗✓✓✓✓
`mnee`✓✓✓✓✓✗✓✓✓✓
`moet`✓✓✓✓✓✗✓✓✓✓
`monerium`✓✓✓✓✓✗✓✓✓✓
`moneta`✓✓✓✓✓✗✓✓✓✓
`moneyonchain`✓✓✓✓✓✗✓✓✓✓
`monolithmarket`✗✗✓✓✓✗✗✗✗✗
`moola`✓✓✓✓✓✗✓✓✓✓
`morpho`✓✓✓✓✓✓✓✓✓✓
`mountainprotocol`✓✓✓✓✓✓✓✓✓✓
`mstable`✗✗✓✓✓✗✓✗✗✓
`mudigital`✗✗✓✓✓✗✗✗✗✗
`multipli`✓✓✓✓✓✗✓✓✓✓
`mynth`✗✗✓✓✓✗✓✗✗✓
`mzero`✓✓✓✓✓✗✓✓✓✓
`nativemarkets`✓✓✓✓✓✗✓✓✓✓
`nereusfinance`✗✗✓✓✓✗✗✗✗✗
`nest`✓✓✓✓✓✓✓✓✓✓
`neutrl`✓✓✓✓✓✓✓✓✓✓
`newrails`✓✓✓✓✓✗✓✓✓✓
`noon`✓✓✓✓✓✓✓✓✓✓
`nyala`✓✓✓✓✓✗✓✓✗✓
`okx`✓✓✓✓✓✗✓✓✓✓
`ondo`✓✓✓✓✓✓✓✓✓✓
`onre`✓✓✓✓✓✗✓✓✓✓
`openedendigital`✓✓✓✓✓✓✓✓✓✓
`openstock`✗✗✓✓✓✗✓✗✗✓
`opentrade`✓✓✓✓✓✓✓✓✓✓
`origin`✓✓✓✓✓✗✓✓✓✓
`oro`✓✓✓✓✓✗✓✓✓✓
`palmusd`✓✓✓✓✓✗✓✓✓✓
`pareto`✓✓✓✓✓✓✓✓✓✓
`paxos`✓✓✓✓✓✗✓✓✓✓
`paytrie`✓✓✓✓✓✗✓✓✓✓
`perena`✓✓✓✓✓✗✓✓✓✓
`phantom`✓✓✓✓✓✗✓✓✓✓
`piku`✓✓✓✓✓✗✓✓✓✓
`pineapple`✓✗✓✓✓✗✓✗✗✓
`pleasinggold`✓✓✓✓✓✗✓✓✓✓
`plumenetwork`✗✗✓✓✓✗✗✗✗✗
`polymarket`✓✓✓✓✓✗✓✓✓✓
`prestocks`✓✓✓✓✓✗✓✓✓✓
`prismafinance`✓✓✓✓✓✗✓✓✓✓
`protos`✗✗✓✓✓✗✓✗✗✓
`quantoz`✓✓✓✓✓✗✓✓✓✓
`raac`✓✓✓✓✓✗✓✓✓✓
`raft`✗✗✓✓✓✗✗✗✗✗
`re`✓✓✓✓✓✓✓✓✓✓
`reality`✓✓✓✓✓✗✓✓✓✓
`realtyx`✓✓✓✓✓✗✓✓✗✓
`reental`✓✓✓✓✓✗✓✓✓✓
`reflexer`✓✓✓✓✓✗✓✓✓✓
`remora`✓✓✓✓✓✗✓✓✓✓
`republicnote`✓✓✓✓✓✗✓✓✗✓
`reserve`✓✓✓✓✓✗✓✓✓✓
`reservoirxyz`✓✓✓✓✓✗✓✓✓✓
`resolv`✓✓✓✓✓✗✓✓✓✓
`resupply`✓✓✓✓✓✓✓✓✓✓
`ribdigital`✓✓✓✓✓✗✓✓✓✓
`rif`✓✓✓✓✓✗✓✓✓✓
`ringsprotocol`✓✓✓✓✓✗✓✓✓✓
`ripio`✓✓✓✓✓✗✓✓✓✓
`ripplelabs`✓✓✓✓✓✗✓✓✓✓
`river`✓✓✓✓✓✗✓✓✓✓
`rivool`✓✓✓✓✓✗✓✗✗✓
`robinhood`✓✓✓✓✓✗✓✓✓✓
`rocketpool`✓✓✓✓✓✓✓✓✓✓
`saturn`✓✓✓✓✓✓✓✓✓✓
`sbishinseitrust`✓✓✓✓✓✗✓✓✓✓
`schumanfinancial`✓✓✓✓✓✗✓✓✓✓
`scienceblockchain`✗✗✓✓✓✗✓✗✗✓
`scroll`✓✓✓✓✓✗✓✓✓✓
`securitize`✓✓✓✓✓✓✓✓✓✓
`shift`✓✓✓✓✓✗✓✓✓✓
`sivo`✗✗✓✓✓✓✓✗✗✓
`smardex`✗✗✓✓✓✗✗✗✗✗
`societegenerale`✓✓✓✓✓✗✓✓✓✓
`sofi`✓✓✓✓✓✗✓✓✓✓
`solayer`✓✓✓✓✓✗✓✓✓✓
`solomonlabs`✓✓✓✓✓✗✓✓✓✓
`solstice`✓✓✓✓✓✗✓✓✓✓
`soulpeg`✓✓✓✓✓✗✓✓✓✓
`sovryn`✓✓✓✓✓✗✓✓✓✓
`spark`✓✓✓✓✓✓✓✓✓✓
`sperax`✓✓✓✓✓✗✓✓✓✓
`spicevc`✗✗✓✓✓✗✓✗✗✓
`spiko`✓✓✓✓✓✓✓✓✓✓
`st0x`✓✓✓✓✓✓✓✓✓✓
`stablecoin`✓✓✓✓✓✗✓✓✓✓
`stablecorp`✗✗✓✓✓✗✗✗✗✗
`stablemint`✗✗✓✓✓✗✗✗✗✗
`stableslabs`✗✗✓✓✓✗✗✗✗✗
`stablestock`✓✓✓✓✓✗✓✓✓✓
`stablr`✓✓✓✓✓✗✓✓✓✓
`stakewise`✓✓✓✓✓✓✓✓✓✓
`standx`✓✓✓✓✓✗✓✓✓✓
`stasis`✓✓✓✓✓✗✓✓✓✓
`straitsx`✓✓✓✓✓✗✓✓✓✓
`strata`✓✓✓✓✓✓✓✓✓✓
`stream`✗✗✓✓✓✗✗✗✗✗
`streamex`✓✓✓✓✓✗✓✓✓✓
`stusdt`✓✓✓✓✓✗✓✓✓✓
`superformlabs`✗✗✗✗✗✗✓✗✗✓
`superstate`✓✓✓✓✓✓✓✓✓✓
`swarmmarkets`✓✓✓✓✓✗✓✓✓✓
`swell`✓✓✓✓✓✓✓✓✓✓
`sygnum`✓✓✓✓✓✗✓✓✓✓
`synthetix`✓✓✓✓✓✗✓✓✓✓
`tangible`✗✗✓✓✓✗✓✗✗✓
`tempo`✓✓✓✓✓✗✓✓✓✓
`tenbinlabs`✓✓✓✓✓✓✓✓✓✓
`tessera`✓✓✓✓✓✗✓✓✓✓
`tether`✓✓✓✓✓✗✓✓✓✓
`textilecredit`✓✓✓✓✓✓✓✓✓✓
`theo`✓✓✓✓✓✓✓✓✓✓
`threshold`✗✗✓✓✓✗✗✗✗✗
`token`✓✓✓✓✓✗✓✓✓✓
`tokengate`✗✗✓✓✓✗✗✗✗✗
`tokenisedgbp`✓✓✓✓✓✗✓✓✓✓
`tokeny`✓✓✓✓✓✗✓✓✓✓
`torifinance`✓✓✓✓✓✗✓✓✓✓
`tradable`✓✓✓✓✓✗✓✓✓✓
`transfero`✓✓✓✓✓✗✓✓✓✓
`trize`✓✓✗✗✗✗✓✓✗✓
`tronusdd`✓✓✓✓✓✓✓✓✓✓
`trystable`✗✗✓✓✓✗✗✗✗✗
`ubs`✗✗✓✓✓✗✗✗✗✗
`unitas`✓✓✓✓✓✗✓✓✓✓
`unitedstables`✓✓✓✓✓✗✓✓✓✓
`unityusd`✓✓✓✓✓✗✓✓✓✓
`upshiftfinance`✓✓✓✓✓✓✓✓✓✓
`usdai`✓✓✓✓✓✓✓✓✓✓
`usdkg`✗✓✓✓✓✗✓✗✗✓
`usdm1`✓✓✓✓✓✗✓✓✓✓
`usdufinance`✓✓✓✓✓✗✓✓✓✓
`usual`✓✓✓✓✓✓✓✓✓✓
`venus`✓✓✓✓✓✗✓✓✓✓
`vnx`✓✓✓✓✓✗✓✓✓✓
`voltprotocol`✗✗✓✓✓✗✗✗✗✗
`wisdomtree`✓✓✓✓✓✗✓✓✓✓
`worldlibertyfinancial`✓✓✓✓✓✗✓✓✓✓
`wspn`✗✗✓✓✓✗✗✗✗✗
`wyoming`✓✓✓✓✓✗✓✓✓✓
`xstocks`✓✓✓✓✓✗✓✓✓✓
`xsy`✓✓✓✓✓✓✓✓✓✓
`yala`✗✗✓✓✓✗✗✗✗✗
`yamatoprotocol`✓✓✓✓✓✗✓✓✓✓
`yeti`✓✓✓✓✓✗✓✓✓✓
`yieldfi`✓✓✓✓✓✓✓✓✓✓
`yieldnest`✓✓✓✓✓✓✓✓✓✓
`yieldoptimizer`✓✓✓✓✓✓✓✓✓✓
`yuzu`✓✓✓✓✓✓✓✓✓✓
`yuzumoney`✓✓✓✓✓✗✓✓✓✓
`zeconomy`✓✓✗✗✗✗✓✓✗✓
`zunami`✗✗✓✓✓✗✗✗✗✗
## Tables [Metrics](/docs/catalog/assets/metrics) holds the daily table schemas at asset and deployment grain, and example queries. [Registry](/docs/catalog/assets/registry) holds the identity tables: the asset, its onchain deployments, and the thing each asset tracks. [Screener](/docs/catalog/assets/screener) holds one row per asset, per asset and chain, and per token as of the last complete day. [Senders](/docs/catalog/assets/senders) holds the sending addresses behind every active-user figure, one row per address per day and a sketch of the same set. [Balances](/docs/catalog/assets/balances) holds every account's current holding of each deployment, with its USD value. # Metrics Source: https://tokenterminal.com/docs/catalog/assets/metrics Daily asset tables: supply, holders, transfers, price, yield, DeFi TVL and the gap from peg. Supply, holders, transfer activity, price, yield, DeFi TVL and the gap from peg. One row per thing per day, at five grains: asset, asset and chain, deployment, asset and app, and deployment and app. Each measure is its own table. An asset table holds `timestamp`, `asset_id` and one value column; an asset-and-chain table holds `timestamp`, `asset_chain_id` and one value column; a deployment table holds `timestamp`, `asset_token_id` and one value column. Symbol, chain, token address and issuance status come from [`dimensions.assets`](/docs/catalog/assets/registry), [`dimensions.assets_by_chain`](/docs/catalog/assets/registry) and [`dimensions.asset_tokens`](/docs/catalog/assets/registry). A deployment is one token contract on one chain, so supply of USDC is a question about the asset, supply of USDC on Base a question about the asset and the chain, and supply of one USDC contract on Base a question about one deployment. The two app grains answer a different question: where the asset is deposited, split by the app holding it. A row appears for each day a measure produced a figure, so a gap in the series is an unknown. A zero in the value column is a measured zero. Several measures are labelled *agentic*. Those count payments made under the x402 standard, which lets software pay for something on its own. They are a subset of ordinary transfer activity. ## Tables **Asset** One row per asset per day. Keyed on `asset_id` and `timestamp`. Price, yield and the gap from peg belong to the asset itself, and every other measure is its deployments added together.
Table Value column What it holds
`metrics_assets.price_daily``price`The asset's price in USD, one figure per asset per day. Where more than one source has a price, we take them in a fixed order of preference. The table also has a `price_source` column, which labels the figure rather than measuring anything.
`metrics_assets.off_peg_daily``off_peg`How far the asset's price sits from its peg, as a fraction: `(price - reference) / reference`. `-0.02` means two percent below peg. The peg is the asset's `reference_asset_id`: the dollar's rate is 1 and every other currency takes its end-of-day FX rate, listed on [Stablecoins ▸ Metrics](/docs/catalog/stablecoins/metrics).
`metrics_assets.apy_daily``apy`The asset's yield over the past year, written as a fraction: `0.05` means five percent. Measured once per asset per day, and never added up.
`metrics_assets.app_tvl_daily``app_tvl`DeFi TVL: value of the asset deposited into the apps we cover, USD, summed across them and across chains. The app tabs split the same figure by app and by deployment.
`metrics_assets.app_trading_volume_daily``app_trading_volume`DEX trading volume: value of spot trades involving the asset on onchain venues (DEX pools and onchain order books), USD, summed across them and across chains. Every trade counts on both of its tokens, so this does not add up across assets. The app tabs split the same figure by app and by deployment.
`metrics_assets.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of the asset's natively-issued supply, USD. This is the measure that answers how much of the asset exists. It includes anything the issuer reports as held off-chain, which is why the asset figure runs above its deployment rows added together, by exactly that amount.
`metrics_assets.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of the asset's bridged deployments, USD. A bridged deployment is a wrapper standing in for supply issued natively on another chain.
`metrics_assets.market_cap_circulating_daily``market_cap_circulating`Circulating market cap across every form of the asset, USD: native issuance plus bridged wrappers. Counts tokens outstanding rather than economic value, because a bridged wrapper stands in for native supply that the same figure already counts.
`metrics_assets.market_cap_circulating_offchain_daily``market_cap_circulating_offchain`The part of circulating market cap an issuer reports as held off-chain, USD. Part of the native figure, published on its own as well, so the gap between the asset figure and its deployment rows is always explainable. Only issuers who report one appear here.
`metrics_assets.holders_daily``holders`Addresses holding a non-zero balance, summed across every deployment of the asset. A sum of per-deployment counts, so an address holding the asset on two chains counts twice.
`metrics_assets.holders_native_daily``holders_native`Addresses holding a non-zero balance, summed across the asset's natively-issued deployments.
`metrics_assets.holders_bridged_daily``holders_bridged`Addresses holding a non-zero balance, summed across the asset's bridged deployments.
`metrics_assets.mints_native_daily``mints_native`Value minted on the day, USD, summed across the asset's natively-issued deployments.
`metrics_assets.mints_bridged_daily``mints_bridged`Value minted on the day, USD, summed across the asset's bridged deployments.
`metrics_assets.mints_daily``mints`Value minted on the day, USD, summed across every deployment. A genuine total: minting on a bridged deployment is its own event, not a second view of a native one.
`metrics_assets.redemptions_native_daily``redemptions_native`Value redeemed on the day, USD, summed across the asset's natively-issued deployments.
`metrics_assets.redemptions_bridged_daily``redemptions_bridged`Value redeemed on the day, USD, summed across the asset's bridged deployments.
`metrics_assets.redemptions_daily``redemptions`Value redeemed on the day, USD, summed across every deployment. A genuine total.
`metrics_assets.transfer_count_native_daily``transfer_count_native`Number of transfers on the day, summed across the asset's natively-issued deployments.
`metrics_assets.transfer_count_bridged_daily``transfer_count_bridged`Number of transfers on the day, summed across the asset's bridged deployments.
`metrics_assets.transfer_count_daily``transfer_count`Number of transfers on the day, summed across every deployment. A genuine total.
`metrics_assets.transfer_volume_native_daily``transfer_volume_native`Value transferred on the day, USD, summed across the asset's natively-issued deployments.
`metrics_assets.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on the day, USD, summed across the asset's bridged deployments.
`metrics_assets.transfer_volume_daily``transfer_volume`Value transferred on the day, USD, summed across every deployment. A genuine total.
`metrics_assets.transfer_count_agentic_native_daily``transfer_count_agentic_native`Number of agentic (x402) transfers on the day, summed across the asset's natively-issued deployments.
`metrics_assets.transfer_count_agentic_bridged_daily``transfer_count_agentic_bridged`Number of agentic (x402) transfers on the day, summed across the asset's bridged deployments.
`metrics_assets.transfer_count_agentic_daily``transfer_count_agentic`Number of agentic (x402) transfers on the day, summed across every deployment. A genuine total.
`metrics_assets.transfer_volume_agentic_native_daily``transfer_volume_agentic_native`Value transferred by agentic (x402) flows on the day, USD, summed across the asset's natively-issued deployments.
`metrics_assets.transfer_volume_agentic_bridged_daily``transfer_volume_agentic_bridged`Value transferred by agentic (x402) flows on the day, USD, summed across the asset's bridged deployments.
`metrics_assets.transfer_volume_agentic_daily``transfer_volume_agentic`Value transferred by agentic (x402) flows on the day, USD, summed across every deployment. A genuine total.
`metrics_assets.daily_active_users_daily``daily_active_users`Distinct addresses sending the asset on the day, counted across every deployment in one pass. The deployment tables split the same count native from bridged, and [Senders](/docs/catalog/assets/senders) holds the addresses themselves for any wider figure.
`metrics_assets.weekly_active_users_daily``weekly_active_users`Distinct addresses sending the asset over the trailing week, across every deployment.
`metrics_assets.monthly_active_users_daily``monthly_active_users`Distinct addresses sending the asset over the trailing month, across every deployment.
`metrics_assets.daily_active_users_agentic_daily``daily_active_users_agentic`Distinct addresses making agentic (x402) payments in the asset on the day, across every deployment.
`metrics_assets.weekly_active_users_agentic_daily``weekly_active_users_agentic`Distinct addresses making agentic (x402) payments in the asset over the trailing week, across every deployment.
`metrics_assets.monthly_active_users_agentic_daily``monthly_active_users_agentic`Distinct addresses making agentic (x402) payments in the asset over the trailing month, across every deployment.
**Asset and chain** One row per asset per chain per day. Keyed on `asset_chain_id` and `timestamp`, which is written `{asset_id}-{chain_id}` and joins `dimensions.assets_by_chain`. Every measure rolls up the asset's deployments on that chain. Price, the gap from peg and supply an issuer reports off-chain belong to the asset alone, and stay on the Asset tab.
Table Value column What it holds
`metrics_assets_by_chain.apy_daily``apy`The asset's yield over the past year on the chain, written as a fraction: `0.05` means five percent. Averaged across its deployments there, and never added up.
`metrics_assets_by_chain.app_tvl_daily``app_tvl`DeFi TVL: value of the asset on the chain deposited into the apps we cover, USD, summed across them and across its deployments there.
`metrics_assets_by_chain.app_trading_volume_daily``app_trading_volume`DEX trading volume: value of spot trades involving the asset on the chain on onchain venues (DEX pools and onchain order books), USD, summed across them and across its deployments there. Every trade counts on both of its tokens, so this does not add up across assets.
`metrics_assets_by_chain.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of the asset's natively-issued deployments on the chain, USD, summed across them.
`metrics_assets_by_chain.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of the asset's bridged deployments on the chain, USD, summed across them.
`metrics_assets_by_chain.market_cap_circulating_daily``market_cap_circulating`Circulating market cap of the asset on the chain, USD, summed across every deployment there, native and bridged.
`metrics_assets_by_chain.holders_daily``holders`Addresses holding a non-zero balance, summed across the asset's deployments on the chain. A sum of per-deployment counts: an address holding two of them counts twice, which only moves chains with more than one deployment of the asset.
`metrics_assets_by_chain.holders_native_daily``holders_native`Addresses holding a non-zero balance, summed across the asset's natively-issued deployments on the chain.
`metrics_assets_by_chain.holders_bridged_daily``holders_bridged`Addresses holding a non-zero balance, summed across the asset's bridged deployments on the chain.
`metrics_assets_by_chain.mints_native_daily``mints_native`Value minted on the day, USD, summed across the asset's natively-issued deployments on the chain.
`metrics_assets_by_chain.mints_bridged_daily``mints_bridged`Value minted on the day, USD, summed across the asset's bridged deployments on the chain.
`metrics_assets_by_chain.mints_daily``mints`Value minted on the day, USD, summed across every deployment on the chain.
`metrics_assets_by_chain.redemptions_native_daily``redemptions_native`Value redeemed on the day, USD, summed across the asset's natively-issued deployments on the chain.
`metrics_assets_by_chain.redemptions_bridged_daily``redemptions_bridged`Value redeemed on the day, USD, summed across the asset's bridged deployments on the chain.
`metrics_assets_by_chain.redemptions_daily``redemptions`Value redeemed on the day, USD, summed across every deployment on the chain.
`metrics_assets_by_chain.transfer_count_native_daily``transfer_count_native`Number of transfers on the day, summed across the asset's natively-issued deployments on the chain.
`metrics_assets_by_chain.transfer_count_bridged_daily``transfer_count_bridged`Number of transfers on the day, summed across the asset's bridged deployments on the chain.
`metrics_assets_by_chain.transfer_count_daily``transfer_count`Number of transfers on the day, summed across every deployment on the chain.
`metrics_assets_by_chain.transfer_volume_native_daily``transfer_volume_native`Value transferred on the day, USD, summed across the asset's natively-issued deployments on the chain.
`metrics_assets_by_chain.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on the day, USD, summed across the asset's bridged deployments on the chain.
`metrics_assets_by_chain.transfer_volume_daily``transfer_volume`Value transferred on the day, USD, summed across every deployment on the chain.
`metrics_assets_by_chain.transfer_count_agentic_native_daily``transfer_count_agentic_native`Number of agentic (x402) transfers on the day, summed across the asset's natively-issued deployments on the chain.
`metrics_assets_by_chain.transfer_count_agentic_bridged_daily``transfer_count_agentic_bridged`Number of agentic (x402) transfers on the day, summed across the asset's bridged deployments on the chain.
`metrics_assets_by_chain.transfer_count_agentic_daily``transfer_count_agentic`Number of agentic (x402) transfers on the day, summed across every deployment on the chain.
`metrics_assets_by_chain.transfer_volume_agentic_native_daily``transfer_volume_agentic_native`Value transferred by agentic (x402) flows on the day, USD, summed across the asset's natively-issued deployments on the chain.
`metrics_assets_by_chain.transfer_volume_agentic_bridged_daily``transfer_volume_agentic_bridged`Value transferred by agentic (x402) flows on the day, USD, summed across the asset's bridged deployments on the chain.
`metrics_assets_by_chain.transfer_volume_agentic_daily``transfer_volume_agentic`Value transferred by agentic (x402) flows on the day, USD, summed across every deployment on the chain.
`metrics_assets_by_chain.daily_active_users_daily``daily_active_users`Distinct addresses sending the asset on the chain on the day, summed across its deployments there. An address sending two of them counts twice, which only moves chains with more than one deployment of the asset.
`metrics_assets_by_chain.weekly_active_users_daily``weekly_active_users`Distinct addresses sending the asset on the chain over the trailing week, summed across its deployments there.
`metrics_assets_by_chain.monthly_active_users_daily``monthly_active_users`Distinct addresses sending the asset on the chain over the trailing month, summed across its deployments there.
`metrics_assets_by_chain.daily_active_users_agentic_daily``daily_active_users_agentic`Distinct addresses making agentic (x402) payments in the asset on the chain on the day, summed across its deployments there.
`metrics_assets_by_chain.weekly_active_users_agentic_daily``weekly_active_users_agentic`Distinct addresses making agentic (x402) payments in the asset on the chain over the trailing week, summed across its deployments there.
`metrics_assets_by_chain.monthly_active_users_agentic_daily``monthly_active_users_agentic`Distinct addresses making agentic (x402) payments in the asset on the chain over the trailing month, summed across its deployments there.
**Deployment** One row per deployment per day. Keyed on `asset_token_id` and `timestamp`, which is written `{asset_id}-{token_address}-{chain_id}` and joins `dimensions.asset_tokens`. Every deployment is issued natively or bridged in from elsewhere, so it appears in the `_native` tables or the `_bridged` tables.
Table Value column What it holds
`metrics_asset_tokens.apy_daily``apy`Yield over the past year, written as a fraction and kept within `(0, 0.50]`. Measured once per asset, on the deployment with the largest circulating market cap, then copied onto the asset's other deployments. Every deployment row for an asset holds the same value, so adding them multiplies the rate.
`metrics_asset_tokens.app_tvl_daily``app_tvl`DeFi TVL: value of the deployment deposited into the apps we cover, USD, summed across them.
`metrics_asset_tokens.app_trading_volume_daily``app_trading_volume`DEX trading volume: value of spot trades involving the deployment on onchain venues (DEX pools and onchain order books), USD, summed across them. Every trade counts on both of its tokens, so this does not add up across assets.
`metrics_asset_tokens.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of the deployment, USD. Natively-issued deployments only.
`metrics_asset_tokens.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of the deployment, USD. Bridged deployments only.
`metrics_asset_tokens.market_cap_circulating_daily``market_cap_circulating`Circulating market cap of the deployment, USD, whichever side it sits on. Not a sum: a deployment is one or the other, so this is simply its value.
`metrics_asset_tokens.holders_daily``holders`Addresses holding a non-zero balance of the deployment, whichever side it sits on.
`metrics_asset_tokens.holders_native_daily``holders_native`Addresses holding a non-zero balance of the deployment. Natively-issued deployments only.
`metrics_asset_tokens.holders_bridged_daily``holders_bridged`Addresses holding a non-zero balance of the deployment. Bridged deployments only.
`metrics_asset_tokens.mints_native_daily``mints_native`Value minted on the deployment on the day, USD. Natively-issued deployments only.
`metrics_asset_tokens.mints_bridged_daily``mints_bridged`Value minted on the deployment on the day, USD. Bridged deployments only.
`metrics_asset_tokens.mints_daily``mints`Value minted on the deployment on the day, USD, whichever side it sits on.
`metrics_asset_tokens.redemptions_native_daily``redemptions_native`Value redeemed on the deployment on the day, USD. Natively-issued deployments only.
`metrics_asset_tokens.redemptions_bridged_daily``redemptions_bridged`Value redeemed on the deployment on the day, USD. Bridged deployments only.
`metrics_asset_tokens.redemptions_daily``redemptions`Value redeemed on the deployment on the day, USD, whichever side it sits on.
`metrics_asset_tokens.transfer_count_native_daily``transfer_count_native`Number of transfers on the deployment on the day. Natively-issued deployments only.
`metrics_asset_tokens.transfer_count_bridged_daily``transfer_count_bridged`Number of transfers on the deployment on the day. Bridged deployments only.
`metrics_asset_tokens.transfer_count_daily``transfer_count`Number of transfers on the deployment on the day, whichever side it sits on.
`metrics_asset_tokens.transfer_volume_native_daily``transfer_volume_native`Value transferred on the deployment on the day, USD. Natively-issued deployments only.
`metrics_asset_tokens.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on the deployment on the day, USD. Bridged deployments only.
`metrics_asset_tokens.transfer_volume_daily``transfer_volume`Value transferred on the deployment on the day, USD, whichever side it sits on.
`metrics_asset_tokens.transfer_count_agentic_native_daily``transfer_count_agentic_native`Number of agentic (x402) transfers on the deployment on the day. Natively-issued deployments only.
`metrics_asset_tokens.transfer_count_agentic_bridged_daily``transfer_count_agentic_bridged`Number of agentic (x402) transfers on the deployment on the day. Bridged deployments only.
`metrics_asset_tokens.transfer_count_agentic_daily``transfer_count_agentic`Number of agentic (x402) transfers on the deployment on the day, whichever side it sits on.
`metrics_asset_tokens.transfer_volume_agentic_native_daily``transfer_volume_agentic_native`Value transferred by agentic (x402) flows on the deployment on the day, USD. Natively-issued deployments only.
`metrics_asset_tokens.transfer_volume_agentic_bridged_daily``transfer_volume_agentic_bridged`Value transferred by agentic (x402) flows on the deployment on the day, USD. Bridged deployments only.
`metrics_asset_tokens.transfer_volume_agentic_daily``transfer_volume_agentic`Value transferred by agentic (x402) flows on the deployment on the day, USD, whichever side it sits on.
`metrics_asset_tokens.daily_active_users_native_daily``daily_active_users_native`Distinct addresses sending the deployment on the day. Natively-issued deployments only.
`metrics_asset_tokens.daily_active_users_bridged_daily``daily_active_users_bridged`Distinct addresses sending the deployment on the day. Bridged deployments only.
`metrics_asset_tokens.weekly_active_users_native_daily``weekly_active_users_native`Distinct addresses sending the deployment over the trailing week. Natively-issued deployments only.
`metrics_asset_tokens.weekly_active_users_bridged_daily``weekly_active_users_bridged`Distinct addresses sending the deployment over the trailing week. Bridged deployments only.
`metrics_asset_tokens.monthly_active_users_native_daily``monthly_active_users_native`Distinct addresses sending the deployment over the trailing month. Natively-issued deployments only.
`metrics_asset_tokens.monthly_active_users_bridged_daily``monthly_active_users_bridged`Distinct addresses sending the deployment over the trailing month. Bridged deployments only.
`metrics_asset_tokens.daily_active_users_agentic_native_daily``daily_active_users_agentic_native`Distinct addresses making agentic (x402) payments in the deployment on the day. Natively-issued deployments only.
`metrics_asset_tokens.daily_active_users_agentic_bridged_daily``daily_active_users_agentic_bridged`Distinct addresses making agentic (x402) payments in the deployment on the day. Bridged deployments only.
`metrics_asset_tokens.weekly_active_users_agentic_native_daily``weekly_active_users_agentic_native`Distinct addresses making agentic (x402) payments in the deployment over the trailing week. Natively-issued deployments only.
`metrics_asset_tokens.weekly_active_users_agentic_bridged_daily``weekly_active_users_agentic_bridged`Distinct addresses making agentic (x402) payments in the deployment over the trailing week. Bridged deployments only.
`metrics_asset_tokens.monthly_active_users_agentic_native_daily``monthly_active_users_agentic_native`Distinct addresses making agentic (x402) payments in the deployment over the trailing month. Natively-issued deployments only.
`metrics_asset_tokens.monthly_active_users_agentic_bridged_daily``monthly_active_users_agentic_bridged`Distinct addresses making agentic (x402) payments in the deployment over the trailing month. Bridged deployments only.
**Asset and app** One row per asset per app per day. Keyed on `asset_id`, `app_id` and `timestamp`. Which apps hold an asset, and how much of it each one holds, added up across every chain the app runs on. Join [`dimensions.apps`](/docs/catalog/apps/registry) on `app_id` for the app's name and market sector. Each position is counted once, against the token supplied rather than the receipt token issued for it: USDC deposited into a lending market appears as USDC, never also as the receipt token minted against it. So the rows for an asset add up to its figure in `metrics_assets.app_tvl_daily`, exactly. Summed across venues, this can exceed the asset's circulating supply, and that is not an error. Lending markets report what was supplied to them, and the same token can be supplied more than once: a user deposits, someone borrows it, and it is deposited again. Aave's own dashboard shows the same thing. Two smaller reasons add to it. A protocol that wraps another protocol's receipt token reports the underlying, so the position is counted at both layers, and a venue can hold tokens the issuer has excluded from circulating supply. Read a large total as leverage in the system, not as double counting. The apps here are the ones whose deposits we model, so this tells you where an asset sits among them.
Table Value column What it holds
`metrics_assets_by_app.app_tvl_daily``app_tvl`DeFi TVL: value of the asset deposited into the app at day end, USD, across every chain the app runs on.
`metrics_assets_by_app.app_trading_volume_daily``app_trading_volume`DEX trading volume: value of spot trades involving the asset executed on the app, USD, across every chain the app runs on. A trade is valued on the cheaper of its two legs.
**Deployment and app** One row per deployment per app per day. Keyed on `asset_token_id`, `app_id` and `timestamp`. The finest grain of DeFi TVL: which contract on which chain sits in which app. Read it from either end: where one deployment's value has gone, or which deployments make up an app's holding of an asset. The rows for an asset and app add up to that pair's figure in `metrics_assets_by_app.app_tvl_daily`, exactly. The table has a `chain_id` column, so a split by chain needs no join.
Table Value column What it holds
`metrics_asset_tokens_by_app.app_tvl_daily``app_tvl`DeFi TVL: value of one deployment of the asset deposited into the app at day end, USD.
`metrics_asset_tokens_by_app.app_trading_volume_daily``app_trading_volume`DEX trading volume: value of spot trades involving one deployment of the asset executed on the app, USD.
## Sample queries **Asset daily read** Each measure is its own table, so a row with all three is a join on `asset_id` and `timestamp`. A `full join` keeps a day that has supply and no price, and bounding the day range on every side stops the unbounded side reading its whole table. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ), price as ( select timestamp, price from `metrics_assets.price_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ), peg as ( select timestamp, off_peg from `metrics_assets.off_peg_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ) select timestamp, supply.market_cap_circulating_native, price.price, peg.off_peg from supply full join price using (timestamp) full join peg using (timestamp) order by timestamp ``` **Tokenized stocks ranking** `asset_type` lives on the registry, so the ranking joins it. How much is filled in varies from measure to measure, so a thinly reported measure ranks its own reporters rather than the whole type. ```sql theme={null} select assets.asset_id, assets.symbol, daily.market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` as daily join `dimensions.assets` as assets using (asset_id) where daily.timestamp = timestamp('2026-08-01') and assets.asset_type = 'tokenized-stocks' order by daily.market_cap_circulating_native desc limit 25 ``` **Native against bridged supply** Native is the chain that issued the asset and bridged is every other chain it reached. The total column already sums the two, so it is the one figure to read for the asset as a whole. ```sql theme={null} with native as ( select timestamp, market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ), bridged as ( select timestamp, market_cap_circulating_bridged from `metrics_assets.market_cap_circulating_bridged_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ), total as ( select timestamp, market_cap_circulating from `metrics_assets.market_cap_circulating_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ) select timestamp, native.market_cap_circulating_native, bridged.market_cap_circulating_bridged, total.market_cap_circulating from native full join bridged using (timestamp) full join total using (timestamp) order by timestamp ``` **One asset by chain** The asset-and-chain tables key on `asset_chain_id`, and `dimensions.assets_by_chain` has the chain and the deployment count behind it. `bridged_status` reads `mixed` on a chain with both a native and a bridged deployment. ```sql theme={null} select chains.chain_id, chains.bridged_status, chains.token_count, daily.market_cap_circulating from `metrics_assets_by_chain.market_cap_circulating_daily` as daily join `dimensions.assets_by_chain` as chains using (asset_chain_id) where daily.timestamp = timestamp('2026-08-01') and chains.asset_id = 'usdc' order by daily.market_cap_circulating desc ``` **Deployment breakdown** The deployment tables have `asset_token_id` alone, so the chain and the native-or-bridged split come from the registry. ```sql theme={null} select deployments.chain_id, deployments.bridged_status, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) where daily.timestamp = timestamp('2026-08-01') and deployments.asset_id = 'usdc' order by daily.market_cap_circulating desc ``` **One deployment's series** Both tables key on `asset_token_id`, so the join needs `timestamp` alone. A `full join` keeps a day that has supply and no transfers. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-06-01') ), transfers as ( select timestamp, transfer_volume_native from `metrics_asset_tokens.transfer_volume_native_daily` where asset_token_id = 'usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-06-01') ) select timestamp, supply.market_cap_circulating_native, transfers.transfer_volume_native from supply full join transfers using (timestamp) order by timestamp ``` # Registry Source: https://tokenterminal.com/docs/catalog/assets/registry Asset names, where each is issued, and what each one tracks. The identity tables behind every asset figure. Every fact and metric joins to them, and [Coverage](/docs/catalog/assets) introduces the grain. ## Tables **Assets** One row per curated asset: its name, what kind of instrument it is, and what it tracks. The row belongs to no particular chain, and the per-chain contracts live in `dimensions.asset_tokens`.
Column Type Description
`asset_id` `STRING` Identifier of the asset, for example `usdc`. Every table that mentions an asset joins on this.
`reference_asset_id` `STRING` What the asset tracks or wraps. Joins `dimensions.reference_assets`.
`name` `STRING` Display name of the asset.
`symbol` `STRING` Ticker symbol of the asset.
`asset_type` `STRING` What kind of instrument it is: `stablecoin`, `tokenized-stocks`, `tokenized-funds`, `lending-token`, `tokenized-commodities`, `liquid-staking-token`, `tokenized-cryptoasset` or `wrapped_native`. One value per asset.
`coingecko_id` `STRING` Identifier of the same asset in the CoinGecko catalogue, for joining our record to a public one.
`coinmarketcap_id` `STRING` Identifier of the same asset in the CoinMarketCap catalogue, for the same purpose.
`description` `STRING` Short description of the asset.
`yahoo_ticker` `STRING` Ticker the underlying trades under on Yahoo Finance, where it is listed.
`custom_price_fx_peg` `STRUCT` A fixed rate the asset is priced at rather than a market quote, in `currency`, `multiplier` and `priority`. Set only where the asset declares one, and `priority` says whether the rate overrides the market price or only fills in where there is none.
`created_at` `TIMESTAMP` When the asset entered the registry.
`metrics_verified_at` `TIMESTAMP` When the asset's published metrics were last verified. Null while unverified.
`mica_marker` `STRING` Which MiCA category the peg implies: `emt_by_peg` for single-currency stablecoins, `art_by_peg` for other stablecoins, `other_crypto_asset` or `out_of_scope_financial_instrument` for everything else. A marker read off the peg.
`mica_authorization_status` `STRING` Whether the token is authorized under MiCA according to the official register: `emt_authorized`, `art_authorized`, `not_authorized`, `application_withdrawn`, `out_of_scope_mifid`, `other_crypto_asset` or `not_checked`. A sourced regulatory fact, where `mica_marker` is read off the peg.
`regulatory_supervised` `STRING` What the issuer discloses about its own supervision: `true`, `false` or `unknown`. A disclosure, taken as given.
`regulator` `STRING` The authority the issuer names as its supervisor, such as `NYDFS/FinCEN`. Filled in where the issuer names one.
`reserves_source` `STRING` Where the reserve figure comes from: `attestation` for an issuer-published report, `onchain` where the backing addresses are identified and the balance computed here, `none` where the issuer publishes nothing.
`reserves_attestor` `STRING` The firm signing the attestation, filled in where `reserves_source` is `attestation`.
`return_treatment` `STRING` How the token treats the income the underlying pays: `total_return`, `price_return`, `price_return_with_distribution` or `not_applicable`. Keyed on the token rather than on what it tracks, so two tokenizations of one share can differ.
`issuer_legal_name` `STRING` The issuing entity as a government register spells it, which is routinely different from the brand.
`issuer_domicile` `STRING` ISO 3166-1 alpha-2 country code of where the issuing entity is registered, such as `US`. Resolved from the issuing project, so it is filled in where that project has a domicile on file.
`issuer_lei` `STRING` Legal Entity Identifier of the issuing entity.
`issuer_cik` `STRING` SEC Central Index Key of the issuing entity.
`issuer_regulatory_framework` `ARRAY` Regimes the issuing entity operates under. An array because an entity can sit under several at once.
`issuer_legal_source_url` `STRING` The filing or register the legal fields above were read from, with `issuer_legal_retrieved_at` recording when.
`issuer_legal_retrieved_at` `STRING` When `issuer_legal_source_url` was last read.
`use_of_income` `STRING` What the issuer says it does with the income the underlying pays, in its own words. `return_treatment` is the coded answer to the same question.
`isin` `STRING` International Securities Identification Number of the instrument, where it has one.
`cusip` `STRING` CUSIP of the instrument, where it has one.
`peg_currency` `STRING` ISO currency code of the peg, set where the asset tracks a national currency. A fund strategy, a share or a commodity is tracked without a peg, and leaves this empty.
`project_relations` `ARRAY` Every project linked to the asset, one element per `(project_id, relation)`. `relation` is `issuer`, `asset_manager`, `risk_curator` or `manager`. Most assets link to one project; a few link to several, such as an issuer alongside a separate manager.
`issuer_project_id` `STRING` The project whose relation is `issuer`, when exactly one project holds that relation. Read `project_relations` for the full set, which is what this column resolves.
**Asset chains** One row per curated asset per chain it is deployed on: the asset's deployments on that chain, taken together. The asset-and-chain tables in `metrics_assets_by_chain` and `screeners.assets_by_chain` key on its `asset_chain_id`.
Column Type Description
`asset_chain_id` `STRING` Identifier of the asset on the chain, formatted `{asset_id}-{chain_id}`.
`asset_id` `STRING` Asset the row belongs to. Joins `dimensions.assets`.
`chain_id` `STRING` Chain the asset is deployed on. Joins `dimensions.chains`.
`bridged_status` `STRING` `native` or `bridged` where every deployment of the asset on the chain is one or the other, `mixed` where the chain has both.
`token_count` `INT64` Registered deployments of the asset on the chain.
`asset_token_ids` `ARRAY` Those deployments, in `asset_token_id` order; each joins `dimensions.asset_tokens`.
`first_issued_onchain` `DATE` The earliest `first_issued_onchain` among those deployments.
**Deployments** One row per onchain deployment of a curated asset, which is one token contract on one chain. A deployment is what every supply, holder and transfer measure is counted per.
Column Type Description
`asset_token_id` `STRING` Identifier of the deployment, formatted `{asset_id}-{token_address}-{chain_id}`.
`asset_id` `STRING` Asset the deployment belongs to. Joins `dimensions.assets`.
`token_id` `STRING` Key of the deployment in `dimensions.tokens`, formatted `{token_address}-{chain_id}`. This table keeps every deployment that exists, so a `token_id` resolves to a row in `dimensions.tokens` where the price feed reaches that contract.
`chain_id` `STRING` Chain the contract is deployed on.
`token_address` `STRING` Address of the token contract.
`is_bridged` `BOOL` Raw registry flag: bridged in rather than issued natively. Always present, so `false` means native or unstated. Filter on `bridged_status` instead.
`bridged_status` `STRING` The classification supply measures split on, and the column to filter supply by: `native`, `bridged` or `unclassified`. A stated registry flag is taken as given; an unstated one reads `native` where the asset has no confirmed bridged deployment anywhere, and `unclassified` where it has one.
**Reference assets** One row per thing an instrument can track or wrap: national currencies, stocks, commodities, funds and cryptoassets. `type` classifies the reference; `dimensions.assets.asset_type` classifies the instrument that tracks or wraps it.
Column Type Description
`reference_asset_id` `STRING` Identifier of the thing being tracked.
`linked_asset_id` `STRING` Its own tokenized asset in `dimensions.assets`, where one exists.
`name` `STRING` Display name.
`symbol` `STRING` Ticker symbol.
`type` `STRING` What kind of thing it is: `stock`, `crypto`, `fiat`, `pendle_pt`, `etf`, `commodity`, `fund_strategy`, `bond` or `other`. A `fiat` row is what makes an asset pointing at it a currency-pegged one, and what fills `peg_currency` on `dimensions.assets`.
`currency_code` `STRING` ISO currency code, filled in on the `fiat` rows.
`unit` `STRING` The physical unit a commodity is quoted in, for example `troy ounce` or `barrel`. Filled in on the `commodity` rows.
`aliases` `ARRAY` Other names it is known by.
`yahoo_ticker` `STRING` Ticker it trades under on Yahoo Finance, where it is listed.
## Sample queries **Assets by type** `asset_type` holds one value per asset, so these counts add up to the whole registry. ```sql theme={null} select asset_type, count(*) as assets from `dimensions.assets` group by asset_type order by assets desc ``` **Deployments of one asset** `bridged_status` says whether each contract was issued natively on its chain or bridged in from another, and it is the column the supply measures split on. ```sql theme={null} select asset_token_id, chain_id, token_address, bridged_status from `dimensions.asset_tokens` where asset_id = 'usdc' order by chain_id ``` **Chains of one asset** One row per chain, with `token_count` deployments behind it. `mixed` marks a chain where the asset's contracts differ in `bridged_status`. ```sql theme={null} select chain_id, bridged_status, token_count, first_issued_onchain from `dimensions.assets_by_chain` where asset_id = 'usdc' order by token_count desc, chain_id ``` **What an asset tracks** Tracking a national currency is what makes an asset a currency-pegged stablecoin, and `assets.peg_currency` comes from it. The inner join keeps the assets whose `reference_asset_id` resolves to a row. ```sql theme={null} select assets.asset_id, reference_assets.reference_asset_id, reference_assets.type, reference_assets.currency_code from `dimensions.assets` as assets join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where assets.asset_id in ('usdc', 'usdt', 'dai') order by assets.asset_id ``` **Assets linked to a project** One asset can name several projects, so `unnest(project_relations)` yields one row per relation and a count taken over it counts an asset once per relation. Filter inside the `unnest`, or use `exists` where only presence matters. ```sql theme={null} select assets.asset_id, assets.name, relation.relation from `dimensions.assets` as assets cross join unnest(assets.project_relations) as relation where relation.project_id = 'securitize' order by assets.asset_id ``` # Screener Source: https://tokenterminal.com/docs/catalog/assets/screener Latest figures for every asset, asset chain and asset token, with averages, totals and changes over six windows. One row per asset in `screeners.assets`, per asset per chain in `screeners.assets_by_chain` and per asset token in `screeners.asset_tokens`, every figure as of `as_of`, the last complete day. Each measure has a column per window and aggregation, named `__`: `market_cap_circulating_max_latest` is the latest circulating market cap, and `mints_30d_sum` the value minted over the 30 days ending on `as_of`. ## Columns **Keys** Each table has `as_of` and its key, then one FLOAT64 column per measure, window and aggregation. Every row is an asset in `dimensions.assets`, an asset chain in `dimensions.assets_by_chain` or an asset token in `dimensions.asset_tokens`, so the join on the key always matches.
Column Type Description
`as_of`TIMESTAMPThe last complete day, the same on every row of every table. Every window ends on it.
`asset_id`STRINGAsset the row belongs to in `screeners.assets`, such as `usdc`; joins `dimensions.assets`.
`asset_chain_id`STRINGAsset chain the row belongs to in `screeners.assets_by_chain`: one asset's deployments on one chain, formatted `{asset_id}-{chain_id}`. Joins `dimensions.assets_by_chain`.
`asset_token_id`STRINGAsset token the row belongs to in `screeners.asset_tokens`: one asset's token contract on one chain, formatted `{asset_id}-{token_address}-{chain_id}`. Joins `dimensions.asset_tokens`.
**Aggregations** A window is `1d`, `7d`, `30d`, `90d`, `180d` or `365d`, and spans that many days ending on `as_of`, while the `max_` columns read the whole history. Which aggregations a measure has follows its `over_time` in [Metric definitions](/docs/catalog/metric-definitions): only a measure whose `over_time` is `sum` has `sum`.
Column What it holds
`__avg`Mean of the daily values over the window.
`__sum`Total of the daily values over the window. Flows only: the measures ticked under Sum.
`__change`A comparison of two aggregations: the value on `as_of` against the value one window earlier, as `(now - then) / abs(then)`. Null when either value is missing or the earlier one is 0.
`__trend`A comparison of two aggregations: the window's average against the average of the window before it, as `(avg - prior) / abs(prior)`. Null unless the window before has a value on every one of its days, and null when its average is 0.
`_max_latest`The value on `as_of`. Null when there is none.
`_max_ath`The highest daily value over the whole history.
`_max_atl`The lowest daily value over the whole history.
**Asset measures** One row per asset, in `screeners.assets`. Every measure has the `avg`, `change`, `trend` and `max_` columns, and the flows also have `sum`.
Measure Sum What it holds
`daily_active_users_agentic`✗Distinct addresses making agentic (x402) payments in the asset on the day, across every deployment.
`monthly_active_users_agentic`✗Distinct addresses making agentic (x402) payments in the asset over the trailing month, across every deployment.
`weekly_active_users_agentic`✗Distinct addresses making agentic (x402) payments in the asset over the trailing week, across every deployment.
`app_trading_volume`✓DEX trading volume: value of spot trades involving the asset on onchain venues (DEX pools and onchain order books), USD, summed across them and across chains. Every trade counts on both of its tokens, so this does not add up across assets. The app tabs split the same figure by app and by deployment.
`app_tvl`✗DeFi TVL: value of the asset deposited into the apps we cover, USD, summed across them and across chains. The app tabs split the same figure by app and by deployment.
`apy`✗The asset's yield over the past year, written as a fraction: `0.05` means five percent. Measured once per asset per day, and never added up.
`holders`✗Addresses holding a non-zero balance, summed across every deployment of the asset. A sum of per-deployment counts, so an address holding the asset on two chains counts twice.
`holders_bridged`✗Addresses holding a non-zero balance, summed across the asset's bridged deployments.
`holders_native`✗Addresses holding a non-zero balance, summed across the asset's natively-issued deployments.
`market_cap_circulating`✗Circulating market cap across every form of the asset, USD: native issuance plus bridged wrappers. Counts tokens outstanding rather than economic value, because a bridged wrapper stands in for native supply that the same figure already counts.
`market_cap_circulating_bridged`✗Circulating market cap of the asset's bridged deployments, USD. A bridged deployment is a wrapper standing in for supply issued natively on another chain.
`market_cap_circulating_native`✗Circulating market cap of the asset's natively-issued supply, USD. This is the measure that answers how much of the asset exists. It includes anything the issuer reports as held off-chain, which is why the asset figure runs above its deployment rows added together, by exactly that amount.
`mints`✓Value minted on the day, USD, summed across every deployment. A genuine total: minting on a bridged deployment is its own event, not a second view of a native one.
`mints_bridged`✓Value minted on the day, USD, summed across the asset's bridged deployments.
`mints_native`✓Value minted on the day, USD, summed across the asset's natively-issued deployments.
`off_peg`✗How far the asset's price sits from its peg, as a fraction: `(price - reference) / reference`. `-0.02` means two percent below peg. The peg is the asset's `reference_asset_id`: the dollar's rate is 1 and every other currency takes its end-of-day FX rate, listed on [Stablecoins ▸ Metrics](/docs/catalog/stablecoins/metrics).
`price`✗The asset's price in USD, one figure per asset per day. Where more than one source has a price, we take them in a fixed order of preference. The label of the source is on `metrics_assets.price_daily`, not in the screener.
`redemptions`✓Value redeemed on the day, USD, summed across every deployment. A genuine total.
`redemptions_bridged`✓Value redeemed on the day, USD, summed across the asset's bridged deployments.
`redemptions_native`✓Value redeemed on the day, USD, summed across the asset's natively-issued deployments.
`transfer_count`✓Number of transfers on the day, summed across every deployment. A genuine total.
`transfer_count_agentic`✓Number of agentic (x402) transfers on the day, summed across every deployment. A genuine total.
`transfer_count_agentic_bridged`✓Number of agentic (x402) transfers on the day, summed across the asset's bridged deployments.
`transfer_count_agentic_native`✓Number of agentic (x402) transfers on the day, summed across the asset's natively-issued deployments.
`transfer_count_bridged`✓Number of transfers on the day, summed across the asset's bridged deployments.
`transfer_count_native`✓Number of transfers on the day, summed across the asset's natively-issued deployments.
`transfer_volume`✓Value transferred on the day, USD, summed across every deployment. A genuine total.
`transfer_volume_agentic`✓Value transferred by agentic (x402) flows on the day, USD, summed across every deployment. A genuine total.
`transfer_volume_agentic_bridged`✓Value transferred by agentic (x402) flows on the day, USD, summed across the asset's bridged deployments.
`transfer_volume_agentic_native`✓Value transferred by agentic (x402) flows on the day, USD, summed across the asset's natively-issued deployments.
`transfer_volume_bridged`✓Value transferred on the day, USD, summed across the asset's bridged deployments.
`transfer_volume_native`✓Value transferred on the day, USD, summed across the asset's natively-issued deployments.
`daily_active_users`✗Distinct addresses sending the asset on the day, counted across every deployment in one pass. The deployment tables split the same count native from bridged, and [Senders](/docs/catalog/assets/senders) holds the addresses themselves for any wider figure.
`monthly_active_users`✗Distinct addresses sending the asset over the trailing month, across every deployment.
`weekly_active_users`✗Distinct addresses sending the asset over the trailing week, across every deployment.
**Asset chain measures** One row per asset per chain, in `screeners.assets_by_chain`. A flow's `sum` adds up across an asset's chains to the asset's figure; a holder or user count, a `change` and a `trend` each describe one chain alone.
Measure Sum What it holds
`daily_active_users_agentic`✗Distinct addresses making agentic (x402) payments in the asset on the chain on the day, summed across its deployments there.
`monthly_active_users_agentic`✗Distinct addresses making agentic (x402) payments in the asset on the chain over the trailing month, summed across its deployments there.
`weekly_active_users_agentic`✗Distinct addresses making agentic (x402) payments in the asset on the chain over the trailing week, summed across its deployments there.
`app_trading_volume`✓DEX trading volume: value of spot trades involving the asset on the chain on onchain venues (DEX pools and onchain order books), USD, summed across them and across its deployments there. Every trade counts on both of its tokens, so this does not add up across assets.
`app_tvl`✗DeFi TVL: value of the asset on the chain deposited into the apps we cover, USD, summed across them and across its deployments there.
`apy`✗The asset's yield over the past year on the chain, written as a fraction: `0.05` means five percent. Averaged across its deployments there, and never added up.
`holders`✗Addresses holding a non-zero balance, summed across the asset's deployments on the chain. A sum of per-deployment counts: an address holding two of them counts twice, which only moves chains with more than one deployment of the asset.
`holders_bridged`✗Addresses holding a non-zero balance, summed across the asset's bridged deployments on the chain.
`holders_native`✗Addresses holding a non-zero balance, summed across the asset's natively-issued deployments on the chain.
`market_cap_circulating`✗Circulating market cap of the asset on the chain, USD, summed across every deployment there, native and bridged.
`market_cap_circulating_bridged`✗Circulating market cap of the asset's bridged deployments on the chain, USD, summed across them.
`market_cap_circulating_native`✗Circulating market cap of the asset's natively-issued deployments on the chain, USD, summed across them.
`mints`✓Value minted on the day, USD, summed across every deployment on the chain.
`mints_bridged`✓Value minted on the day, USD, summed across the asset's bridged deployments on the chain.
`mints_native`✓Value minted on the day, USD, summed across the asset's natively-issued deployments on the chain.
`redemptions`✓Value redeemed on the day, USD, summed across every deployment on the chain.
`redemptions_bridged`✓Value redeemed on the day, USD, summed across the asset's bridged deployments on the chain.
`redemptions_native`✓Value redeemed on the day, USD, summed across the asset's natively-issued deployments on the chain.
`transfer_count`✓Number of transfers on the day, summed across every deployment on the chain.
`transfer_count_agentic`✓Number of agentic (x402) transfers on the day, summed across every deployment on the chain.
`transfer_count_agentic_bridged`✓Number of agentic (x402) transfers on the day, summed across the asset's bridged deployments on the chain.
`transfer_count_agentic_native`✓Number of agentic (x402) transfers on the day, summed across the asset's natively-issued deployments on the chain.
`transfer_count_bridged`✓Number of transfers on the day, summed across the asset's bridged deployments on the chain.
`transfer_count_native`✓Number of transfers on the day, summed across the asset's natively-issued deployments on the chain.
`transfer_volume`✓Value transferred on the day, USD, summed across every deployment on the chain.
`transfer_volume_agentic`✓Value transferred by agentic (x402) flows on the day, USD, summed across every deployment on the chain.
`transfer_volume_agentic_bridged`✓Value transferred by agentic (x402) flows on the day, USD, summed across the asset's bridged deployments on the chain.
`transfer_volume_agentic_native`✓Value transferred by agentic (x402) flows on the day, USD, summed across the asset's natively-issued deployments on the chain.
`transfer_volume_bridged`✓Value transferred on the day, USD, summed across the asset's bridged deployments on the chain.
`transfer_volume_native`✓Value transferred on the day, USD, summed across the asset's natively-issued deployments on the chain.
`daily_active_users`✗Distinct addresses sending the asset on the chain on the day, summed across its deployments there. An address sending two of them counts twice, which only moves chains with more than one deployment of the asset.
`monthly_active_users`✗Distinct addresses sending the asset on the chain over the trailing month, summed across its deployments there.
`weekly_active_users`✗Distinct addresses sending the asset on the chain over the trailing week, summed across its deployments there.
**Asset token measures** One row per asset token, in `screeners.asset_tokens`. A flow's `sum` adds up across an asset's tokens to the asset's figure; a holder or user count, a `change` and a `trend` each describe one token alone.
Measure Sum What it holds
`daily_active_users_agentic_bridged`✗Distinct addresses making agentic (x402) payments in the deployment on the day. Bridged deployments only.
`daily_active_users_agentic_native`✗Distinct addresses making agentic (x402) payments in the deployment on the day. Natively-issued deployments only.
`monthly_active_users_agentic_bridged`✗Distinct addresses making agentic (x402) payments in the deployment over the trailing month. Bridged deployments only.
`monthly_active_users_agentic_native`✗Distinct addresses making agentic (x402) payments in the deployment over the trailing month. Natively-issued deployments only.
`weekly_active_users_agentic_bridged`✗Distinct addresses making agentic (x402) payments in the deployment over the trailing week. Bridged deployments only.
`weekly_active_users_agentic_native`✗Distinct addresses making agentic (x402) payments in the deployment over the trailing week. Natively-issued deployments only.
`app_trading_volume`✓DEX trading volume: value of spot trades involving the deployment on onchain venues (DEX pools and onchain order books), USD, summed across them. Every trade counts on both of its tokens, so this does not add up across assets.
`app_tvl`✗DeFi TVL: value of the deployment deposited into the apps we cover, USD, summed across them.
`apy`✗Yield over the past year, written as a fraction and kept within `(0, 0.50]`. Measured once per asset, on the deployment with the largest circulating market cap, then copied onto the asset's other deployments. Every deployment row for an asset holds the same value, so adding them multiplies the rate.
`holders`✗Addresses holding a non-zero balance of the deployment, whichever side it sits on.
`holders_bridged`✗Addresses holding a non-zero balance of the deployment. Bridged deployments only.
`holders_native`✗Addresses holding a non-zero balance of the deployment. Natively-issued deployments only.
`market_cap_circulating`✗Circulating market cap of the deployment, USD, whichever side it sits on. Not a sum: a deployment is one or the other, so this is simply its value.
`market_cap_circulating_bridged`✗Circulating market cap of the deployment, USD. Bridged deployments only.
`market_cap_circulating_native`✗Circulating market cap of the deployment, USD. Natively-issued deployments only.
`mints`✓Value minted on the deployment on the day, USD, whichever side it sits on.
`mints_bridged`✓Value minted on the deployment on the day, USD. Bridged deployments only.
`mints_native`✓Value minted on the deployment on the day, USD. Natively-issued deployments only.
`redemptions`✓Value redeemed on the deployment on the day, USD, whichever side it sits on.
`redemptions_bridged`✓Value redeemed on the deployment on the day, USD. Bridged deployments only.
`redemptions_native`✓Value redeemed on the deployment on the day, USD. Natively-issued deployments only.
`transfer_count`✓Number of transfers on the deployment on the day, whichever side it sits on.
`transfer_count_agentic`✓Number of agentic (x402) transfers on the deployment on the day, whichever side it sits on.
`transfer_count_agentic_bridged`✓Number of agentic (x402) transfers on the deployment on the day. Bridged deployments only.
`transfer_count_agentic_native`✓Number of agentic (x402) transfers on the deployment on the day. Natively-issued deployments only.
`transfer_count_bridged`✓Number of transfers on the deployment on the day. Bridged deployments only.
`transfer_count_native`✓Number of transfers on the deployment on the day. Natively-issued deployments only.
`transfer_volume`✓Value transferred on the deployment on the day, USD, whichever side it sits on.
`transfer_volume_agentic`✓Value transferred by agentic (x402) flows on the deployment on the day, USD, whichever side it sits on.
`transfer_volume_agentic_bridged`✓Value transferred by agentic (x402) flows on the deployment on the day, USD. Bridged deployments only.
`transfer_volume_agentic_native`✓Value transferred by agentic (x402) flows on the deployment on the day, USD. Natively-issued deployments only.
`transfer_volume_bridged`✓Value transferred on the deployment on the day, USD. Bridged deployments only.
`transfer_volume_native`✓Value transferred on the deployment on the day, USD. Natively-issued deployments only.
`daily_active_users_bridged`✗Distinct addresses sending the deployment on the day. Bridged deployments only.
`daily_active_users_native`✗Distinct addresses sending the deployment on the day. Natively-issued deployments only.
`monthly_active_users_bridged`✗Distinct addresses sending the deployment over the trailing month. Bridged deployments only.
`monthly_active_users_native`✗Distinct addresses sending the deployment over the trailing month. Natively-issued deployments only.
`weekly_active_users_bridged`✗Distinct addresses sending the deployment over the trailing week. Bridged deployments only.
`weekly_active_users_native`✗Distinct addresses sending the deployment over the trailing week. Natively-issued deployments only.
## Sample queries **One asset** Every column of one row shares the same `as_of`, so the figures read together. `market_cap_circulating_30d_change` compares the market cap on `as_of` with 30 days earlier. ```sql theme={null} select as_of, market_cap_circulating_max_latest, market_cap_circulating_30d_change, holders_max_latest, mints_30d_sum, redemptions_30d_sum from `screeners.assets` where asset_id = 'usdc' ``` **Top 25 by market cap** `market_cap_circulating_max_latest` is each asset's latest circulating market cap, and `mints_30d_sum` the value minted over the 30 days ending on `as_of`. The join to `dimensions.assets` on `asset_id` adds the name and symbol. ```sql theme={null} select assets.name, assets.symbol, screener.market_cap_circulating_max_latest, screener.mints_30d_sum, screener.redemptions_30d_sum from `screeners.assets` as screener join `dimensions.assets` as assets using (asset_id) where screener.market_cap_circulating_max_latest is not null order by screener.market_cap_circulating_max_latest desc limit 25 ``` **One chain's assets by market cap** `dimensions.assets_by_chain` gives each row's asset and chain, so the filter on `chain_id` picks one chain's assets. `market_cap_circulating_max_latest` is the asset's circulating market cap on that chain on `as_of`, and `mints_30d_sum` the value minted there over the 30 days ending on it. ```sql theme={null} select chains.asset_id, chains.bridged_status, screener.market_cap_circulating_max_latest, screener.mints_30d_sum from `screeners.assets_by_chain` as screener join `dimensions.assets_by_chain` as chains using (asset_chain_id) where chains.chain_id = 'base' and screener.market_cap_circulating_max_latest is not null order by screener.market_cap_circulating_max_latest desc limit 25 ``` **One asset's tokens by holders** `dimensions.asset_tokens` gives each token's asset, chain and address, so the filter on `asset_id` picks one asset's tokens. Holder counts describe one token each, which makes them a ranking key across an asset's tokens. ```sql theme={null} select tokens.chain_id, tokens.token_address, screener.holders_max_latest, screener.market_cap_circulating_max_latest, screener.transfer_volume_30d_sum from `screeners.asset_tokens` as screener join `dimensions.asset_tokens` as tokens using (asset_token_id) where tokens.asset_id = 'usdc' order by screener.holders_max_latest desc ``` # Senders Source: https://tokenterminal.com/docs/catalog/assets/senders Every sending address behind every active-user count. Every active-user figure in the [daily asset tables](/docs/catalog/assets/metrics) is worked out from these two tables. `facts_asset_tokens.senders` records one row for each day, each deployment and each address that sent it; `facts_asset_tokens.senders_hll` summarizes the same addresses as one sketch per day per deployment. Counts of distinct addresses behave differently from amounts. If 100 addresses sent USDC on Monday and 100 sent it on Tuesday, the figure over the two days sits somewhere between 100 and 200, and the counts alone leave the answer open; the same holds across chains, deployments and assets. So a daily `*_active_users` column describes the day it is stamped with, and a wider figure comes from the addresses or from the sketches. A sketch is a small summary of a set of addresses, a few kilobytes however large the set, and two sketches combine into one before anything is counted. Combine the sketches for a stretch of days, a group of chains or a basket of assets and count once, and every address counts once. The technique is called HyperLogLog++, hence the `_hll` in the table name, and a count off a sketch is an estimate that agrees with the `*_active_users` figures published in the daily tables. ## Tables **Senders** One row per `(timestamp, asset_token_id, sender_address)`. The addresses themselves answer questions of identity: how far two assets' users overlap, or whether the addresses that showed up in March are still active in June.
Column Type Description
`timestamp` `TIMESTAMP` Day the address sent the deployment. The partition column.
`asset_token_id` `STRING` Deployment the address sent, formatted `{asset_id}-{token_address}-{chain_id}`.
`asset_id` `STRING` Asset the deployment belongs to.
`token_id` `STRING` Key of the deployment in `dimensions.tokens`.
`chain_id` `STRING` Chain the deployment lives on.
`symbol` `STRING` Ticker symbol of the asset.
`asset_type` `STRING` Classification of the asset.
`bridged_status` `STRING` Issuance classification of the deployment: `native`, `bridged` or `unclassified`.
`token_address` `STRING` Address of the token contract.
`sender_address` `STRING` Address that sent the token that day.
**Senders HLL** One row per `(timestamp, asset_token_id)`, the sketch of that day's senders. The key columns match the address table exactly, so any filter that works there works here, over a fraction of the data.
Column Type Description
`timestamp` `TIMESTAMP` Day the sketch summarizes. The partition column.
`asset_token_id` `STRING` Deployment the sketch summarizes, formatted `{asset_id}-{token_address}-{chain_id}`.
`asset_id` `STRING` Asset the deployment belongs to.
`token_id` `STRING` Key of the deployment in `dimensions.tokens`.
`chain_id` `STRING` Chain the deployment lives on.
`symbol` `STRING` Ticker symbol of the asset.
`asset_type` `STRING` Classification of the asset.
`bridged_status` `STRING` Issuance classification of the deployment: `native`, `bridged` or `unclassified`.
`token_address` `STRING` Address of the token contract.
`senders_hll` `BYTES` Compact summary of the day's sending addresses, built at precision 15. Combine these with `hll_count.merge`, which lands within a fraction of a percent of the exact count. The raw bytes mean nothing read directly.
## Sample queries **One deployment, one day** `count(distinct sender_address)` over the addresses is exact, and over one deployment and one day it reads a single partition. Widen either bound and it reads every row in the range. ```sql theme={null} select count(distinct sender_address) as senders from `facts_asset_tokens.senders` where asset_token_id = 'usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-02') ``` **Monthly active senders** `hll_count.merge` combines the sketches first and counts once, so an address active on three chains counts as one. The answer is an estimate, taken off a fraction of the data the address table holds. ```sql theme={null} select hll_count.merge(senders_hll) as monthly_active_senders from `facts_asset_tokens.senders_hll` where asset_id = 'usdc' and timestamp >= timestamp('2026-07-01') and timestamp < timestamp('2026-08-01') ``` **Weekly senders by chain** Combining within each group keeps every group's count correct, at any level the group-by asks for. Summing the per-chain figures counts an address once per chain it was active on. ```sql theme={null} select chain_id, hll_count.merge(senders_hll) as weekly_active_senders from `facts_asset_tokens.senders_hll` where asset_id = 'usdc' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') group by chain_id order by weekly_active_senders desc ``` # Bridges Source: https://tokenterminal.com/docs/catalog/bridges/index Every cross-chain transfer: matched legs, USD value and daily volume, across every bridge. Cross-chain transfer volume, fees and revenue for every bridge Token Terminal tracks, from the project down to the individual token moving through it. ## Coverage A tab per grain, then the events and the chains. Each tab says what one row is, and a tick marks every app that reports it. **Project** A project is the business behind the bridge, such as `layerzero`. One row per project per day, every version and chain together.
App Project Transfer volume Fees Revenue
`chainlink-ccip``chainlink`✓✓✓
`circle-cctp-v1``circle`✓✓✓
`circle-cctp-v2``circle`✓✓✓
`debridge-liquidity-network-dln``debridge`✗✓✓
`edgex-bridge``edgex`✗✓✓
`katananetwork-vault-bridge``katananetwork`✗✓✓
`layerzero-v1``layerzero`✓✓✓
`layerzero-v2``layerzero`✓✓✓
**App** An app is one deployed version of a bridge, such as `layerzero-v2`. One row per app per day, across every chain it runs on.
App Project Transfer volume Fees Revenue
`chainlink-ccip``chainlink`✓✓✓
`circle-cctp-v1``circle`✓✗✗
`circle-cctp-v2``circle`✓✓✓
`debridge-liquidity-network-dln``debridge`✗✓✓
`katananetwork-vault-bridge``katananetwork`✗✓✓
`layerzero-v1``layerzero`✓✓✓
`layerzero-v2``layerzero`✓✓✓
**Bridge token** A bridge token is one token moving through one bridge, such as `USDC` through `circle-cctp-v2`. One row per token and app per day.
App Project Source transfer volume Destination transfer volume
`chainlink-ccip``chainlink`✓✓
`circle-cctp-v1``circle`✓✓
`circle-cctp-v2``circle`✓✓
`layerzero-v1``layerzero`✓✓
`layerzero-v2``layerzero`✓✓
**Events** One row per cross-chain transfer, at the moment it happened onchain. Amounts are in the token's own units and in USD, both valued before publication.
App Project Transfers
`chainlink-ccip``chainlink`✓
`circle-cctp-v1``circle`✓
`circle-cctp-v2``circle`✓
`layerzero-v1``layerzero`✓
`layerzero-v2``layerzero`✓
**Chains** Every chain the section covers.
Chain Apps
`arbitrum``chainlink-ccip`, `circle-cctp-v1`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`avalanche``chainlink-ccip`, `circle-cctp-v1`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`base``chainlink-ccip`, `circle-cctp-v1`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`berachain``chainlink-ccip`, `layerzero-v1`, `layerzero-v2`
`bob``layerzero-v2`
`bsc``chainlink-ccip`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`celo``layerzero-v1`, `layerzero-v2`
`ethereum``chainlink-ccip`, `circle-cctp-v1`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`flowevm``layerzero-v2`
`gnosis``chainlink-ccip`, `layerzero-v1`, `layerzero-v2`
`gravityalpha``layerzero-v2`
`hederaevm``chainlink-ccip`
`hyperevm``chainlink-ccip`, `circle-cctp-v2`, `layerzero-v2`
`injectiveevm``circle-cctp-v2`
`ink``circle-cctp-v2`, `layerzero-v2`
`katananetwork``chainlink-ccip`, `layerzero-v2`
`linea``chainlink-ccip`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`manta``layerzero-v1`, `layerzero-v2`
`megaeth``chainlink-ccip`, `layerzero-v2`
`monad``chainlink-ccip`, `circle-cctp-v2`, `layerzero-v2`
`opbnb``layerzero-v1`, `layerzero-v2`
`optimism``chainlink-ccip`, `circle-cctp-v1`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`plasma``chainlink-ccip`, `layerzero-v1`, `layerzero-v2`
`polygon``chainlink-ccip`, `circle-cctp-v1`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`robinhoodchain``chainlink-ccip`
`rootstock``layerzero-v2`
`scroll``layerzero-v2`
`seievm``chainlink-ccip`, `circle-cctp-v2`, `layerzero-v2`
`solana``chainlink-ccip`
`sonic``chainlink-ccip`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`tempo``chainlink-ccip`
`unichain``chainlink-ccip`, `circle-cctp-v1`, `circle-cctp-v2`, `layerzero-v1`, `layerzero-v2`
`viction``layerzero-v1`, `layerzero-v2`
`worldchain``circle-cctp-v2`
`xdc``circle-cctp-v2`, `layerzero-v2`
`xlayer``chainlink-ccip`
`zksyncera``layerzero-v1`, `layerzero-v2`
## Tables [Metrics](/docs/catalog/bridges/metrics) holds the daily table schemas at each grain and example queries. [Registry](/docs/catalog/bridges/registry) holds the identity tables. Each event has its own page and its own table: [Transfers](/docs/catalog/bridges/transfers). # Metrics Source: https://tokenterminal.com/docs/catalog/bridges/metrics Daily bridge figures per project, app and bridge token. Transfer volume, fees and revenue, in USD. One row per thing per day, at five grains: project, project and chain, app, app and chain, and bridge token. ## Tables > [!NOTE] > > Daily bridge transfer volumes cover closed UTC days and follow the availability cutoff of the chain for each transfer leg. Canonical volume uses the source chain when a source timestamp is available, otherwise the destination chain. A tab per grain. [Coverage](/docs/catalog/bridges) shows which apps report which measure. **Project** One row per project per day.
Table Value column What it holds
`metrics_projects.transfer_volume_daily``transfer_volume`USD value of assets moved through the project's bridge transfers, counted once per transfer.
`metrics_projects.fees_daily``fees`Total fees paid by users.
`metrics_projects.revenue_daily``revenue`Fees retained by the protocol.
**Project × chain** One row per project and chain per day. The two directional columns read one set of transfers from opposite ends, so `transfer_volume` is the one that counts each transfer once.
Table Value column What it holds
`metrics_projects_by_chain.transfer_volume_daily``transfer_volume`USD value of assets moved through the project's bridge transfers, counted once per transfer.
`metrics_projects_by_chain.transfer_volume_source_daily``transfer_volume_source`USD value sent out through the project's bridge transfers, measured on the source chain leg.
`metrics_projects_by_chain.transfer_volume_destination_daily``transfer_volume_destination`USD value received through the project's bridge transfers, measured on the destination chain leg.
`metrics_projects_by_chain.fees_daily``fees`Total fees paid by users.
`metrics_projects_by_chain.revenue_daily``revenue`Fees retained by the protocol.
**App** One row per app per day.
Table Value column What it holds
`metrics_apps.transfer_volume_daily``transfer_volume`USD value of assets moved through the app's bridge transfers, counted once per transfer.
`metrics_apps.fees_daily``fees`Fees paid by users of the app across every chain it runs on.
`metrics_apps.revenue_daily``revenue`Fees the app retained across every chain it runs on.
**App × chain** One row per app and chain per day. A chain figure takes a direction, and the app's counted-once total sits one grain up on `metrics_apps.transfer_volume_daily`.
Table Value column What it holds
`metrics_apps_by_chain.transfer_volume_source_daily``transfer_volume_source`USD value sent out through the app's bridge transfers, measured on the source chain leg.
`metrics_apps_by_chain.transfer_volume_destination_daily``transfer_volume_destination`USD value received through the app's bridge transfers, measured on the destination chain leg.
**Bridge token** One row per token and app per day. `token_id` is the key from `dimensions.tokens`, and `chain_id` names the chain the leg was measured on.
Table Value column What it holds
`metrics_bridge_tokens.transfer_volume_source_daily``transfer_volume_source`USD value of the token sent out through a bridge, measured on the source chain leg.
`metrics_bridge_tokens.transfer_volume_destination_daily``transfer_volume_destination`USD value of the token received through a bridge, measured on the destination chain leg.
## Sample queries **Projects by volume** `transfer_volume` is in USD and counts each transfer once, whichever pair of chains it crossed, so one project's figure compares with another's. `dimensions.projects` supplies the display name on `project_id`. ```sql theme={null} select daily.project_id, projects.name, daily.transfer_volume from `metrics_projects.transfer_volume_daily` as daily left join `dimensions.projects` as projects using (project_id) where daily.timestamp = timestamp('2026-08-01') order by daily.transfer_volume desc limit 25 ``` **One project's chain split** The counted-once figure and the two directional legs are three tables, joined on `chain_id` and `timestamp` and bounded on each side. `full join` keeps a chain that only received on a day it sent nothing. ```sql theme={null} with counted_once as ( select timestamp, chain_id, transfer_volume from `metrics_projects_by_chain.transfer_volume_daily` where project_id = 'layerzero' and timestamp >= timestamp('2026-08-01') ), leaving as ( select timestamp, chain_id, transfer_volume_source from `metrics_projects_by_chain.transfer_volume_source_daily` where project_id = 'layerzero' and timestamp >= timestamp('2026-08-01') ), arriving as ( select timestamp, chain_id, transfer_volume_destination from `metrics_projects_by_chain.transfer_volume_destination_daily` where project_id = 'layerzero' and timestamp >= timestamp('2026-08-01') ) select coalesce(counted_once.timestamp, leaving.timestamp, arriving.timestamp) as timestamp, coalesce(counted_once.chain_id, leaving.chain_id, arriving.chain_id) as chain_id, counted_once.transfer_volume, leaving.transfer_volume_source, arriving.transfer_volume_destination from counted_once full join leaving using (timestamp, chain_id) full join arriving using (timestamp, chain_id) order by timestamp, chain_id ``` **Apps by volume** The app grain splits a project into its bridge versions, so `layerzero-v1` and `layerzero-v2` rank as two rows. `dimensions.apps` has the display name and the project each version belongs to. ```sql theme={null} select daily.app_id, apps.name, apps.project_id, daily.transfer_volume from `metrics_apps.transfer_volume_daily` as daily left join `dimensions.apps` as apps using (app_id) where daily.timestamp = timestamp('2026-08-01') order by daily.transfer_volume desc limit 25 ``` **One app, by chain** Each direction is its own table, so one row per chain with both is a join on `chain_id` and `timestamp`. A chain reads high on `transfer_volume_source` when it is where value leaves from, and high on `transfer_volume_destination` when it is where value lands. ```sql theme={null} with leaving as ( select timestamp, chain_id, transfer_volume_source from `metrics_apps_by_chain.transfer_volume_source_daily` where app_id = 'layerzero-v2' and timestamp >= timestamp('2026-08-01') ), arriving as ( select timestamp, chain_id, transfer_volume_destination from `metrics_apps_by_chain.transfer_volume_destination_daily` where app_id = 'layerzero-v2' and timestamp >= timestamp('2026-08-01') ) select coalesce(leaving.timestamp, arriving.timestamp) as timestamp, coalesce(leaving.chain_id, arriving.chain_id) as chain_id, leaving.transfer_volume_source, arriving.transfer_volume_destination from leaving full join arriving using (timestamp, chain_id) order by timestamp, chain_id ``` **One token, both directions** `token_id` names the token on one chain, so USDC on Ethereum and USDC on Base are two keys and this reads the Ethereum one. The two directions join on `token_id` and `timestamp`, bounded on each side. ```sql theme={null} with leaving as ( select timestamp, transfer_volume_source from `metrics_bridge_tokens.transfer_volume_source_daily` where token_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-08-01') ), arriving as ( select timestamp, transfer_volume_destination from `metrics_bridge_tokens.transfer_volume_destination_daily` where token_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-08-01') ) select coalesce(leaving.timestamp, arriving.timestamp) as timestamp, leaving.transfer_volume_source, arriving.transfer_volume_destination from leaving full join arriving using (timestamp) order by timestamp ``` **Tokens leaving one chain** The token grain has `app_id`, so one token bridged by two apps is two rows and a token total is a group by on `token_id`. `dimensions.tokens` supplies the symbol. ```sql theme={null} select daily.token_id, tokens.symbol, sum(daily.transfer_volume_source) as transfer_volume_source from `metrics_bridge_tokens.transfer_volume_source_daily` as daily left join `dimensions.tokens` as tokens using (token_id) where daily.timestamp = timestamp('2026-08-01') and daily.chain_id = 'ethereum' group by daily.token_id, tokens.symbol order by transfer_volume_source desc limit 25 ``` # Registry Source: https://tokenterminal.com/docs/catalog/bridges/registry Bridge identity: the projects, the deployed versions, and the tokens they move. The identity tables behind every bridge figure. Every fact and metric joins to one of them, and [Coverage](/docs/catalog/bridges) introduces each grain. ## Tables **Projects** One row per project in the catalog.
Column Type Description
`project_id`STRINGThe project, such as `aave`.
`slug`STRINGThe project's key in Token Terminal page URLs. It differs from `project_id` where the page URL is hyphenated (`redstone-chain` for `redstonechain`).
`url`STRINGThe project's page on the Token Terminal Explorer.
`name`STRINGDisplay name.
`symbol`STRINGTicker of the project's token, where it has one.
`logo`STRINGPublic URL of the project logo, a PNG. Its `?logo_hash=` suffix changes whenever the image does. Null for a project whose image was never uploaded.
`description`STRUCTThe project copy: `what` the project is, `who` it serves and `how` it works.
`links`ARRAY\The project's links as `type` and `url` pairs (website, x, docs, github). `type` is the label as written, so `twitter` and `x` both occur.
`market_sectors`ARRAY\Every market sector the project belongs to, as tag ids, primary first. Unnesting it yields one row per sector.
`primary_market_sector`STRINGThe market sector the project is listed under: the first element of `market_sectors`. One value per row.
`listing_date`TIMESTAMPWhen the project was listed on Token Terminal.
`coingecko_id`STRINGThe project token's CoinGecko id.
`coinmarketcap_id`STRINGThe project token's CoinMarketCap id.
**Apps** One row per app in the catalog.
Column Type Description
`app_id`STRINGThe app, such as `aave-v3`.
`project_id`STRINGThe project operating it.
`name`STRINGDisplay name.
`market_sectors`ARRAY\Every sector the app is tagged with.
`primary_market_sector`STRINGThe first of those, for grouping.
`created_at`TIMESTAMPWhen the app was added.
**Bridge tokens** One row per token in the catalog, in `dimensions.tokens`. `token_id` is the key the bridge token grain is built on.
Column Type Description
`token_id` `STRING` Token identifier: `{token_address}-{chain_id}`.
`asset_id` `STRING` The curated asset this token is a deployment of. Empty where no one has matched it.
`chain_id` `STRING` Chain the contract is deployed on.
`token_address` `STRING` Contract address, lowercase.
`symbol` `STRING` Symbol read from the contract, unverified.
`name` `STRING` Name read from the contract, unverified.
`decimals` `INT64` How many decimal places to move to turn a raw amount into a token amount.
`created_at` `TIMESTAMP` When the token launched onchain.
`bridged` `BOOL` Whether the deployment is a bridged wrapper. Empty where the token has not been matched to an asset.
`coingecko_id` `STRING` Identifier of the same token in the CoinGecko catalogue, for joining our record to a public one.
## Sample queries **Bridge apps** `market_sectors` is an array, so the section filter reads `'bridges' in unnest(market_sectors)`. An app tagged with several sectors returns one row. ```sql theme={null} select app_id, project_id, name from `dimensions.apps` order by project_id, app_id ``` **Projects behind the bridges** A project can run several bridge versions, and this returns the project once. `primary_market_sector` is the sector the Explorer lists the project under. ```sql theme={null} select project_id, name, symbol, market_sectors from `dimensions.projects` where primary_market_sector = 'bridges' order by project_id ``` **Tokens one bridge moves** The token grain is where a bridge's assets are named, and `token_id` joins `dimensions.tokens` for the symbol and the decimals. Bound `timestamp` on the metrics side: this reads one day. ```sql theme={null} select distinct daily.token_id, tokens.symbol, tokens.decimals, daily.chain_id from `metrics_bridge_tokens.transfer_volume_source_daily` as daily join `dimensions.tokens` as tokens using (token_id) where daily.app_id = 'circle-cctp-v2' and daily.timestamp = timestamp('2026-08-01') order by tokens.symbol, daily.chain_id ``` **Chains a bridge connects** The chain pairs a bridge serves are read off the transfers themselves, on `source_chain_id` and `destination_chain_id`. Bound `block_timestamp`: the fact is partitioned on it. ```sql theme={null} select source_chain_id, destination_chain_id, count(*) as transfers from `facts_bridge_tokens.transfers` where app_id = 'layerzero-v2' and block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') group by source_chain_id, destination_chain_id order by transfers desc limit 25 ``` # Transfers Source: https://tokenterminal.com/docs/catalog/bridges/transfers Cross-chain bridge transfers, with the sending and arriving sides matched. One row per cross-chain transfer, with the sending and arriving legs matched onto the same row. `transfer_amount_usd` holds the transfer valued once in USD, taken from whichever leg the row is anchored on. ## Columns
Column Type Description
`block_timestamp` `TIMESTAMP` Time of the block the row is anchored on: the sending leg's block, or the arriving leg's on a row anchored there. Partition column.
`project_id` `STRING` Project operating the bridge.
`product_id` `STRING` Version of the bridge within that project.
`app_id` `STRING` Bridge app the transfer went through: `chainlink-ccip`, `circle-cctp-v1`, `circle-cctp-v2`, `layerzero-v1` or `layerzero-v2`.
`match_key` `STRING` Identifier the two legs are paired on, published by the bridge itself, such as LayerZero's GUID or CCIP's message id.
`match_method` `STRING` How the two legs were paired. Reads `exact` on a row with both legs.
`latency_seconds` `INT64` Seconds the transfer took: the arriving block's time minus the sending block's. Populated on a row with both legs.
`unmatched_reason` `STRING` Why a row has a single leg. On a row anchored on its sending leg it reads `source_key_missing`, `destination_chain_not_indexed`, `destination_leg_not_decoded` or `destination_pending_or_failed`; on one anchored on its arriving leg, `destination_key_missing`, `source_chain_not_indexed`, `source_leg_not_decoded` or `source_leg_missing`.
`intermediary_address` `STRING` Address of the relayer that relayed the message, on bridges that name one.
`source_chain_id` `STRING` Chain the transfer left. Clustering column.
`source_transaction_hash` `STRING` Hash of the transaction the sending leg was in.
`source_log_index` `INT64` Position of the sending event within its block.
`source_sub_log_index` `INT64` Which token inside a sending event that moved more than one, counting up from zero. CCIP sending legs are the ones that move more than one.
`source_block_timestamp` `TIMESTAMP` Time of the block the transfer left in.
`source_block_number` `INT64` Number of that block.
`source_sender_address` `STRING` Address that sent the transfer.
`source_recipient_address` `STRING` Address the sending leg names as the recipient.
`source_token_address` `STRING` Token contract on the chain the transfer left.
`source_token_id` `STRING` That token's key in [`dimensions.tokens`](/docs/catalog/tokens/registry).
`source_bridge_contract_address` `STRING` Bridge contract the sending event came from.
`source_amount_raw` `BIGNUMERIC` Amount leaving, in the token's smallest units, before decimals are applied.
`destination_chain_id` `STRING` Chain the transfer arrived on. Clustering column.
`destination_transaction_hash` `STRING` Hash of the transaction the arriving leg was in.
`destination_log_index` `INT64` Position of the arriving event within its block.
`destination_block_timestamp` `TIMESTAMP` Time of the block the transfer arrived in.
`destination_block_number` `INT64` Number of that block.
`destination_sender_address` `STRING` Sender named on the arriving leg.
`destination_recipient_address` `STRING` Address that received the transfer.
`destination_token_address` `STRING` Token contract on the chain the transfer arrived on.
`destination_token_id` `STRING` That token's key in [`dimensions.tokens`](/docs/catalog/tokens/registry).
`destination_bridge_contract_address` `STRING` Bridge contract the arriving event came from.
`destination_amount_raw` `BIGNUMERIC` Amount arriving, in the token's smallest units, before decimals are applied.
`source_transfer_amount` `FLOAT64` Amount leaving, in whole token units.
`source_transfer_amount_usd` `FLOAT64` Amount leaving, in USD, measured on the sending leg.
`destination_transfer_amount` `FLOAT64` Amount arriving, in whole token units. On bridges whose arrival event omits the amount, such as CCIP, this takes the sending leg's amount.
`destination_transfer_amount_usd` `FLOAT64` Amount arriving, in USD, measured on the arriving leg, with the same fallback.
`transfer_amount` `FLOAT64` The transfer counted once, in whole token units: the sending leg's amount, or the arriving leg's on a row anchored there.
`transfer_amount_usd` `FLOAT64` The transfer counted once, in USD. Sum this column for total volume; the two directional columns describe the same value from opposite ends.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `source_chain_id` on every query, or you read the whole table and the whole table is billed to you. **One day, one chain** `source_chain_id` is a clustering column alongside the partition, so a single chain over one day reads a fraction of that day. Amounts here are the sending leg's own, in the token's units and in USD. ```sql theme={null} select transfers.block_timestamp, transfers.app_id, transfers.source_transaction_hash, transfers.destination_chain_id, transfers.source_token_id, transfers.source_transfer_amount, transfers.source_transfer_amount_usd from `facts_bridge_tokens.transfers` as transfers where transfers.source_chain_id = 'ethereum' and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') order by transfers.source_transfer_amount_usd desc limit 100 ``` **Daily volume by app** `transfer_amount_usd` takes the sending leg's value, or the arriving leg's on a row anchored there, so each transfer contributes once to the total. Both bounds on `block_timestamp` are what hold the scan to the window. ```sql theme={null} select timestamp_trunc(transfers.block_timestamp, day) as day, transfers.app_id, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers where transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') group by day, transfers.app_id order by day, volume_usd desc ``` **Routes by volume** A route is the pair `source_chain_id` and `destination_chain_id`, both filled in on a row with two legs, and both are clustering columns. Ranking on `transfer_amount_usd` keeps each transfer to one route. ```sql theme={null} select transfers.source_chain_id, transfers.destination_chain_id, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers where transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') and transfers.destination_chain_id is not null group by transfers.source_chain_id, transfers.destination_chain_id order by volume_usd desc limit 25 ``` **Latency by app** `latency_seconds` is filled in on a row with both legs, so the average runs over the transfers whose arrival was found. The median is the more useful figure here: a long tail of slow arrivals pulls the mean up. ```sql theme={null} select transfers.app_id, round(avg(transfers.latency_seconds)) as mean_seconds, approx_quantiles(transfers.latency_seconds, 100)[offset(50)] as median_seconds from `facts_bridge_tokens.transfers` as transfers where transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-02') and transfers.latency_seconds is not null group by transfers.app_id order by median_seconds ``` # Cosmos ecosystem Source: https://tokenterminal.com/docs/catalog/chain-verticals/archived/cosmos The archived Cosmos chains, and the months each raw table covers. The tables are the ones each chain had in the family, so the set varies by chain. Each tab is one chain, and its tables are named for the dataset that holds them. Both dates are final: the chain has stopped, so nothing is added after the latest month. **MANTRA**
Table Earliest Latest
`mantra.block_events` 2024-10 2026-04
`mantra.blocks` 2024-10 2026-04
`mantra.message_events` 2024-10 2026-04
`mantra.transaction_messages` 2024-10 2026-04
`mantra.transactions` 2024-10 2026-04
**Noble**
Table Earliest Latest
`noble.block_events` 2024-03 2026-06
`noble.blocks` 2023-03 2026-06
`noble.message_events` 2023-03 2026-06
`noble.transaction_messages` 2023-03 2026-06
`noble.transactions` 2023-03 2026-06
**Osmosis**
Table Earliest Latest
`osmosis.block_events` 2021-06 2026-06
`osmosis.blocks` 2021-06 2026-06
`osmosis.message_events` 2021-06 2026-06
`osmosis.transaction_messages` 2021-06 2026-06
`osmosis.transactions` 2021-06 2026-06
**Sei**
Table Earliest Latest
`sei.block_events` 2023-05 2025-07
`sei.blocks` 2023-05 2025-07
`sei.transactions` 2023-05 2025-07
**Sei Cosmos**
Table Earliest Latest
`sei_cosmos.message_events` 2023-05 2025-07
**Terra**
Table Earliest Latest
`terra.blocks` 2022-05 2024-10
`terra.event_attributes` 2022-05 2024-10
`terra.message_event_attributes` 2022-05 2024-10
`terra.transaction_messages` 2022-05 2024-10
`terra.transactions` 2022-05 2024-10
# EVM ecosystem Source: https://tokenterminal.com/docs/catalog/chain-verticals/archived/evm The archived EVM chains, and the months each raw table covers. The tables are the ones each chain had in the family, so the set varies by chain. Each tab is one chain, and its tables are named for the dataset that holds them. Both dates are final: the chain has stopped, so nothing is added after the latest month. **Aleph Zero EVM**
Table Earliest Latest
`alephzeroevm.blocks` 2024-07 2025-09
`alephzeroevm.logs` 2024-07 2025-09
`alephzeroevm.traces` 2024-07 2025-09
`alephzeroevm.transactions` 2024-07 2025-09
**Fantom**
Table Earliest Latest
`fantom.blocks` 2019-12 2025-10
`fantom.logs` 2019-12 2025-10
`fantom.traces` 2023-06 2025-02
`fantom.transactions` 2019-12 2025-10
**Mantra EVM**
Table Earliest Latest
`mantraevm.blocks` 2024-10 2026-04
`mantraevm.logs` 2025-09 2026-04
`mantraevm.traces` 2025-10 2025-12
`mantraevm.transactions` 2025-09 2026-04
**Ronin**
Table Earliest Latest
`ronin.blocks` 2021-01 2026-05
`ronin.logs` 2021-01 2026-05
`ronin.transactions` 2021-01 2026-05
**XAI**
Table Earliest Latest
`xai.blocks` 2024-01 2025-08
`xai.logs` 2024-01 2025-08
`xai.traces` 2024-01 2025-08
`xai.transactions` 2024-01 2025-08
# Archived chains Source: https://tokenterminal.com/docs/catalog/chain-verticals/archived/index The chains whose record has ended, and the months each raw table covers. A chain in this section has stopped. Its dataset holds the record up to the latest month listed and takes no further writes, so both dates on these pages are final. A chain appears here as rows rather than a section of its own. ## Pages > **[EVM ecosystem](/docs/catalog/chain-verticals/archived/evm)** > > The archived EVM chains, and the months each raw table covers. > **[Cosmos ecosystem](/docs/catalog/chain-verticals/archived/cosmos)** > > The archived Cosmos chains, and the months each raw table covers. > **[Substrate ecosystem](/docs/catalog/chain-verticals/archived/substrate)** > > The archived Substrate chains, and the months each raw table covers. # Substrate ecosystem Source: https://tokenterminal.com/docs/catalog/chain-verticals/archived/substrate The archived Substrate chains, and the months each raw table covers. Every chain here has the family's `blocks`, `events` and `extrinsics` tables. Each tab is one chain, and its tables are named for the dataset that holds them. Both dates are final: the chain has stopped, so nothing is added after the latest month. **Centrifuge**
Table Earliest Latest
`centrifuge.blocks` 2022-03 2026-06
`centrifuge.events` 2022-03 2026-06
`centrifuge.extrinsics` 2022-03 2026-06
**Interlay**
Table Earliest Latest
`interlay.blocks` 2022-03 2026-07
`interlay.events` 2022-03 2026-07
`interlay.extrinsics` 2022-03 2026-07
**Invarch**
Table Earliest Latest
`invarch.blocks` 2023-10 2025-07
`invarch.events` 2023-10 2025-07
`invarch.extrinsics` 2023-10 2025-07
**Kilt**
Table Earliest Latest
`kilt.blocks` 2021-11 2025-12
`kilt.events` 2021-11 2025-12
`kilt.extrinsics` 2021-11 2025-12
**Moonbeam**
Table Earliest Latest
`moonbeam.blocks` 2021-12 2026-07
`moonbeam.events` 2021-12 2026-07
`moonbeam.extrinsics` 2021-12 2026-07
**Mythos**
Table Earliest Latest
`mythos.blocks` 2024-03 2026-05
`mythos.events` 2024-03 2026-05
`mythos.extrinsics` 2024-03 2026-05
**Nodle**
Table Earliest Latest
`nodle.blocks` 2022-03 2026-01
`nodle.events` 2022-03 2026-01
`nodle.extrinsics` 2022-03 2026-01
**Phala**
Table Earliest Latest
`phala.blocks` 2022-04 2025-11
`phala.events` 2022-04 2025-11
`phala.extrinsics` 2022-04 2025-11
**Polimec**
Table Earliest Latest
`polimec.blocks` 2024-01 2025-09
`polimec.events` 2024-01 2025-09
`polimec.extrinsics` 2024-01 2025-09
**Polkadex**
Table Earliest Latest
`polkadex.blocks` 2022-06 2025-01
`polkadex.events` 2022-06 2025-01
`polkadex.extrinsics` 2022-06 2025-01
**Subsocial**
Table Earliest Latest
`subsocial.blocks` 2022-01 2025-08
`subsocial.events` 2022-01 2025-08
`subsocial.extrinsics` 2022-01 2025-08
**Zeitgeist**
Table Earliest Latest
`zeitgeist.blocks` 2022-02 2026-03
`zeitgeist.events` 2022-02 2026-03
`zeitgeist.extrinsics` 2022-02 2026-03
# Bitcoin Source: https://tokenterminal.com/docs/catalog/chain-verticals/bitcoin/bitcoin Standardized Bitcoin tables from the 2009 genesis block. `bitcoin` holds the standardized Bitcoin tables, following the schema documented in [the family overview](/docs/catalog/chain-verticals/bitcoin/index) exactly, with no differences. Both tables cover the chain's full history, from the 2009 genesis block through to the current day. Bitcoin also appears in the catalog's list of chains; everything else for the chain comes from the `bitcoin` dataset. [Chains](/docs/catalog/chains/index) covers that list and the daily tables built on it, and [Tokens](/docs/catalog/tokens/index), [DEX](/docs/catalog/dex/index), [Real-world assets](/docs/catalog/real-world-assets/index) and [Projects](/docs/catalog/projects/index) cover the chains that run contracts. ## Tables
Table Since Description
`blocks` 2009-01 One row per block, with its fee, size and unspent-output figures already worked out.
`transactions` 2009-01 One row per transaction, with its inputs and outputs nested on the row.
## Sample queries **Daily fees and output** **Sum daily fees and output value from block statistics over one week.** ```sql theme={null} select date(timestamp) as day, sum(transaction_count) as transactions, sum(total_fee) as total_fee, sum(total_out) as total_out from `bitcoin.blocks` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') group by day order by day ``` **Chain registry lookup** **Look up Bitcoin's chain entry and the project it belongs to.** ```sql theme={null} select chains.chain_id, chains.name as chain_name, projects.name as project_name, projects.primary_market_sector from `dimensions.chains` as chains join `dimensions.projects` as projects using (project_id) where chains.chain_id = 'bitcoin' ``` # Dogecoin Source: https://tokenterminal.com/docs/catalog/chain-verticals/bitcoin/dogecoin The standardized Dogecoin tables. The `dogecoin` dataset holds the standardized Dogecoin tables. History starts 2013-12. Every column is documented at [UTXO ▸ Overview](/docs/catalog/chain-verticals/bitcoin/index). ## Tables
Table Since
`blocks` 2013-12
`transactions` 2013-12
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `dogecoin.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # UTXO ecosystem Source: https://tokenterminal.com/docs/catalog/chain-verticals/bitcoin/index Standardized blocks and transactions for Bitcoin and the chains built like it. These chains keep no account balances. Coins sit in outputs, each one a chunk of value locked to whoever can unlock it, and a transaction spends whole outputs as its inputs and creates new ones. An output nobody has spent yet is an unspent transaction output, or UTXO, and someone's balance is just the sum of the ones they can unlock. Recording that takes only two tables: `blocks`, with the totals for each block, and `transactions`, with each transaction's inputs and outputs held on the same row. The [Tables](#tables) section below says what each table holds and lists the columns. ## Chains
Chain `chain_id` blocks transactions events
Bitcoin `bitcoin` ✓ ✓ ✗
Dogecoin `dogecoin` ✓ ✓ ✗
Litecoin `litecoin` ✓ ✓ ✗
Zcash `zcash` ✓ ✓ ✗
Stacks `stacks` ✓ ✓ ✓
## Tables The schemas below are read from `bitcoin`, and apply to the chains listed on the [Bitcoin ecosystem overview](/docs/catalog/chain-verticals/bitcoin/index). Stacks has a different shape and is documented on its [own page](/docs/catalog/chain-verticals/bitcoin/stacks). These chains keep no account balances. Coins sit in outputs, each one a chunk of value locked to whoever can unlock it. A transaction spends whole outputs as its inputs and creates new outputs, and an output still unspent is an unspent transaction output, or UTXO. Someone's balance is the sum of the unspent outputs they can unlock. `transactions` is split by day on `block_timestamp`, and `blocks` on `timestamp`. Filter on that column in every query: with a filter the query reads only the days you asked for, without one it reads the whole table. **blocks** A block is a batch of transactions a miner added to the chain. `blocks` contains one row per block, with the fee, size and unspent-output figures for that block already worked out, so you rarely have to total them yourself.
Column Type Description
`timestamp` `TIMESTAMP` The time the block was mined. Partition column.
`height` `INT64` The block height.
`block_hash` `STRING` The hash of the block.
`block_subsidy` `INT64` The block subsidy paid to the miner.
`transaction_count` `INT64` The number of transactions in the block.
`total_fee` `INT64` The total fees paid in the block.
`total_out` `INT64` The total value of all outputs in the block.
`total_size` `INT64` The block size in bytes.
`total_weight` `INT64` The block weight.
`avg_fee` `INT64` The average transaction fee.
`avg_fee_rate` `INT64` The average fee rate.
`avg_transaction_size` `INT64` The average transaction size in bytes.
`max_fee` `INT64` The highest transaction fee in the block.
`max_fee_rate` `INT64` The highest fee rate in the block.
`max_transaction_size` `INT64` The largest transaction size in the block.
`median_fee` `INT64` The median transaction fee.
`median_time` `INT64` The median time of the previous blocks.
`median_transaction_size` `INT64` The median transaction size.
`min_fee` `INT64` The lowest transaction fee in the block.
`min_fee_rate` `INT64` The lowest fee rate in the block.
`min_transaction_size` `INT64` The smallest transaction size in the block.
`segwit_total_size` `INT64` The total size of segwit transactions.
`segwit_total_weight` `INT64` The total weight of segwit transactions.
`segwit_transaction_count` `INT64` The number of segwit transactions.
`utxo_increase` `INT64` The net change in the number of unspent outputs on the chain.
`utxo_size_increase` `INT64` The net change in the storage size of those unspent outputs.
`feerate_percentiles` `ARRAY` Fee rate percentiles for the block.
`ins` `INT64` The number of inputs in the block.
`outs` `INT64` The number of outputs in the block.
**Daily fees and output** **Sum daily fees and output value from block statistics over one week.** ```sql theme={null} select date(timestamp) as day, sum(transaction_count) as transactions, sum(total_fee) as total_fee, sum(total_out) as total_out from `bitcoin.blocks` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') group by day order by day ``` **transactions** A transaction spends outputs and creates new ones. `transactions` contains one row per transaction, with its inputs and its outputs held as lists on that same row rather than in separate tables.
Column Type Description
`block_timestamp` `TIMESTAMP` The time of the block containing the transaction. Partition column.
`block_height` `INT64` The height of the containing block.
`block_hash` `STRING` The hash of the containing block.
`txid` `STRING` The transaction identifier.
`fee` `NUMERIC` The transaction fee.
`is_coinbase` `BOOL` Whether this is the block's coinbase transaction, the one that pays the miner and has no inputs to spend.
`size` `INT64` The transaction size in bytes.
`vsize` `INT64` The virtual size in vbytes.
`weight` `INT64` The transaction weight.
`inputs` `ARRAY` The transaction inputs. Each element holds the previous output reference (`txid`, `vout`), the unlock script, witness data and the resolved `prevout` with its value and script public key.
`outputs` `ARRAY` The transaction outputs. Each element holds the output `value`, position `n` and `scriptPubKey` with type and addresses.
To get one row per output rather than one row per transaction, unnest `inputs` or `outputs`. Each input already holds the output it spends, in `prevout`, including that output's value, so the table needs no self-join to find out what was spent. **Daily transactions** **Count daily transactions and coinbase transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, countif(is_coinbase) as coinbase_transactions from `bitcoin.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` ## Exceptions Stacks sits on top of Bitcoin and runs contracts of its own, written in a language called Clarity, so its tables have extra columns for that and it adds a third table, `events`, for the movements of assets and tokens and the notes its contracts write. The [Stacks](/docs/catalog/chain-verticals/bitcoin/stacks) page describes them. # Litecoin Source: https://tokenterminal.com/docs/catalog/chain-verticals/bitcoin/litecoin Standardized Litecoin tables from October 2011. `litecoin` holds the standardized Litecoin tables, following the schema documented in [the family overview](/docs/catalog/chain-verticals/bitcoin/index) exactly, with no differences. Both tables cover the chain's full history, from October 2011 through to the current day. Litecoin also appears in the catalog's list of chains; everything else for the chain comes from the `litecoin` dataset. [Chains](/docs/catalog/chains/index) covers that list and the daily tables built on it. [Stacks](/docs/catalog/chain-verticals/bitcoin/stacks) is the one chain in this family that runs contracts, so its tokens also reach the catalog's token list. ## Tables
Table Since Description
`blocks` 2011-10 One row per block, with its fee, size and unspent-output figures already worked out.
`transactions` 2011-10 One row per transaction, with its inputs and outputs nested on the row.
## Sample queries **Daily output moved** **Measure daily output value moved over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, sum((select sum(output.value) from unnest(outputs) as output)) as total_output_value from `litecoin.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **Chain registry lookup** **Look up Litecoin's chain entry and the project it belongs to.** ```sql theme={null} select chains.chain_id, chains.name as chain_name, projects.name as project_name, projects.primary_market_sector from `dimensions.chains` as chains join `dimensions.projects` as projects using (project_id) where chains.chain_id = 'litecoin' ``` # Stacks Source: https://tokenterminal.com/docs/catalog/chain-verticals/bitcoin/stacks Standardized Stacks tables, with Clarity contract calls and asset events. `stacks` holds the standardized Stacks tables. Stacks sits on top of Bitcoin and runs contracts of its own, written in a language called Clarity, so its tables differ from the rest of the Bitcoin family: `blocks` and `transactions` have extra columns for that, and a third table, `events`, records asset movements, locked STX (the chain's own token), and the notes its contracts write. A Stacks transaction comes in one of several kinds, and `transaction_type` says which. Each kind fills its own group of columns: `token_transfer_*` for a transfer, `contract_call_*` for a call into a contract, `smart_contract_*` for publishing one. Because Stacks runs contracts, its tokens reach the catalog's token list, and some have a daily USD price. [Tokens](/docs/catalog/tokens/index) covers the token list and the daily price table in depth. [Chains](/docs/catalog/chains/index) covers the list of chains we track. ## Tables
Table Since Description
`blocks` 2024-04 One row per block, with burn-block anchoring and execution cost totals.
`transactions` 2024-04 One row per transaction, keyed on `transaction_id`, with the columns its Clarity type populates.
`events` 2021-01 One row per event, keyed on `transaction_id` and `event_index`: asset transfers, STX locks and contract logs.
`events` reaches back to 2021-01, while `blocks` and `transactions` begin on 2024-04-16. ## Sample queries **Events by type** **Count events by type on one day.** ```sql theme={null} select event_type, count(*) as events from `stacks.events` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by event_type order by events desc ``` **Priced tokens** **List the Stacks tokens that had a daily price over one week.** ```sql theme={null} with priced as ( select token_id, avg(price) as avg_price, count(*) as price_days from `metrics_tokens.price_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'stacks' group by token_id ) select tokens.symbol, tokens.name, priced.avg_price, priced.price_days from priced join `dimensions.tokens` as tokens using (token_id) order by priced.avg_price desc limit 20 ``` # Zcash Source: https://tokenterminal.com/docs/catalog/chain-verticals/bitcoin/zcash The standardized Zcash tables. The `zcash` dataset holds the standardized Zcash tables. History starts 2016-10. Every column is documented at [UTXO ▸ Overview](/docs/catalog/chain-verticals/bitcoin/index). ## Tables
Table Since
`blocks` 2016-10
`transactions` 2016-10
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `zcash.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Celestia Source: https://tokenterminal.com/docs/catalog/chain-verticals/cosmos/celestia The standardized Celestia tables. The `celestia` dataset holds the standardized Celestia tables. History starts 2023-10. Every column is documented at [Cosmos ▸ Overview](/docs/catalog/chain-verticals/cosmos/index). ## Tables
Table Since
`block_events` 2025-07
`blocks` 2023-10
`message_events` 2023-10
`transaction_messages` 2023-10
`transactions` 2023-10
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `celestia.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Cosmos Hub Source: https://tokenterminal.com/docs/catalog/chain-verticals/cosmos/cosmoshub Standardized Cosmos Hub tables. `cosmoshub` holds the standardized Cosmos Hub tables, following the schema documented in [the family overview](/docs/catalog/chain-verticals/cosmos/index) exactly, with no differences. Chain activity comes from these tables. Elsewhere in the catalog, Cosmos Hub appears through its tokens. Some arrived from another chain over IBC, the Cosmos transfer protocol, and are held as vouchers; the others were minted on Cosmos Hub itself by its token factory. [Tokens](/docs/catalog/tokens/index) covers the token list and the daily price table built beside it. [Chains](/docs/catalog/chains/index) covers the list of chains we track. ## Tables
Table Since Description
`blocks` 2019-12 One row per block, with its transaction count and proposer.
`transactions` 2021-02 One row per transaction, with its fee and result code.
`transaction_messages` 2021-02 One row per message inside a transaction.
`message_events` 2021-02 One row per event emitted during transaction execution.
`block_events` 2021-02 One row per event emitted outside a transaction.
The transaction tables begin on 2021-02-18, at the Cosmos Hub 4 upgrade; `blocks` also covers the hub version before it. ## Sample queries **Daily success rate** **Count daily transactions and their success rate over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, countif(transaction_code = 0) as successful from `cosmoshub.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **Tokens tracked** **List the Cosmos Hub tokens we track, with the name the chain knows each one by.** Cosmos chains identify a token by a string called its denom, and that is what `token_address` holds: an `ibc/` hash for a voucher, or a `factory/` path for one the token factory minted. ```sql theme={null} select token_id, symbol, name, decimals, token_address from `dimensions.tokens` where chain_id = 'cosmoshub' and symbol is not null order by created_at limit 20 ``` # dYdX Source: https://tokenterminal.com/docs/catalog/chain-verticals/cosmos/dydx The standardized dYdX tables. The `dydx` dataset holds the standardized dYdX tables. History starts 2023-10. Every column is documented at [Cosmos ▸ Overview](/docs/catalog/chain-verticals/cosmos/index). ## Tables
Table Since
`block_events` 2023-10
`blocks` 2023-10
`message_events` 2023-10
`transaction_messages` 2023-10
`transactions` 2023-10
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `dydx.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Cosmos ecosystem Source: https://tokenterminal.com/docs/catalog/chain-verticals/cosmos/index Standardized blocks, transactions, messages and events for every Cosmos chain. These chains are all built with the same toolkit, the Cosmos SDK. On them a transaction is a bundle: it holds a list of messages, each one a typed request such as "send these coins" or "vote on this proposal". Running those messages makes the chain write events, its own notes on what happened, and the chain writes more of them at the start and end of each block, on its own account rather than for a transaction. So each chain gets five tables, `blocks`, `transactions`, `transaction_messages`, `message_events` and `block_events`, in one dataset per chain. The [Tables](#tables) section below says what each table holds and lists the columns once for the whole family. ## Chains
Chain `chain_id` blocks transactions transaction\_messages message\_events block\_events
Celestia `celestia` ✓ ✓ ✓ ✓ ✓
Cosmos Hub `cosmoshub` ✓ ✓ ✓ ✓ ✓
dYdX `dydx` ✓ ✓ ✓ ✓ ✓
Injective `injective` ✓ ✓ ✓ ✓ ✓
## Tables Cosmos chains are built from the same toolkit, so they all have the same five tables with the same columns. The schemas below are read from `cosmoshub`, and apply to every chain listed on the [Cosmos overview](/docs/catalog/chain-verticals/cosmos/index). One thing to know before the tables. On these chains a transaction is a bundle: it holds a list of **messages**, each one a typed request such as "send these coins" or "vote on this proposal". Running those messages emits **events**, which are the chain's own notes about what happened, so the sequence is transaction, then messages, then events. Every table except `blocks` is split by day on `block_timestamp`, and `blocks` on `timestamp`. Filter on that column in every query: with a filter the query reads only the days you asked for, without one it reads the whole table. **blocks** A block is a batch of transactions added to the chain, and the validator that put it forward is its proposer. `blocks` contains one row per block.
Column Type Description
`timestamp` `TIMESTAMP` The time the block was produced. Partition column.
`block_height` `INT64` The block height.
`transaction_count` `INT64` The number of transactions in the block.
`validators_hash` `STRING` The hash of the validator set.
`proposer_address` `STRING` The address of the block proposer.
**Daily blocks and transactions** **Count blocks and total transactions per day over one week.** ```sql theme={null} select timestamp_trunc(timestamp, day) as day, count(*) as blocks, sum(transaction_count) as transactions from `cosmoshub.blocks` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') group by day order by day ``` **transactions** A transaction is one signed submission to the chain, holding the messages that say what to do. `transactions` contains one row per transaction, with the fee it paid and whether it worked.
Column Type Description
`block_height` `INT64` The height of the containing block.
`block_timestamp` `TIMESTAMP` The time of the containing block. Partition column.
`transaction_hash` `STRING` The hash of the transaction.
`transaction_index` `INT64` The position of the transaction within the block.
`transaction_info` `STRING` The transaction info string returned by the node.
`transaction_log` `STRING` The execution log.
`transaction_code` `INT64` The result code. Zero marks success.
`transaction_fee` `INT64` The fee paid.
`gas_wanted` `STRING` The gas requested.
`gas_used` `STRING` The gas consumed.
**Daily success rate and fees** **Count daily transactions, their success rate and average fee over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, countif(transaction_code = 0) as successful, avg(transaction_fee) as avg_fee from `cosmoshub.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **transaction\_messages** A message is one typed request inside a transaction: send coins, delegate a stake, vote. Its type is the best single column for asking what users were doing on the chain. `transaction_messages` contains one row per message.
Column Type Description
`block_timestamp` `TIMESTAMP` The time of the containing block. Partition column.
`block_height` `INT64` The height of the containing block.
`transaction_hash` `STRING` The hash of the containing transaction.
`transaction_index` `INT64` The position of the transaction within the block.
`message_index` `INT64` The position of the message within the transaction.
`message_type` `STRING` What kind of request this is, written as a full type path such as `/cosmos.bank.v1beta1.MsgSend`.
`message` `STRING` The message payload.
**Message types** **Rank message types by count over one week.** ```sql theme={null} select message_type, count(*) as messages from `cosmoshub.transaction_messages` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by message_type order by messages desc limit 20 ``` **message\_events** An event is a note the chain writes while it runs a message: coins moved, a stake changed. `message_events` contains one row per event a transaction produced.
Column Type Description
`block_timestamp` `TIMESTAMP` The time of the containing block. Partition column.
`block_height` `INT64` The height of the containing block.
`transaction_hash` `STRING` The hash of the emitting transaction.
`event_type` `STRING` The event type.
`transaction_index` `INT64` The position of the transaction within the block.
`event_index` `INT64` The position of the event within the transaction.
`event_attributes` `JSON` The event attributes, as key-value pairs.
**Event types** **Rank event types by count over one week.** ```sql theme={null} select event_type, count(*) as events from `cosmoshub.message_events` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by event_type order by events desc limit 20 ``` **block\_events** Some things happen because the chain itself does them at the start or end of a block, with no transaction behind them: paying out staking rewards, for instance. `block_events` contains one row per event of that kind, and `source` says whether it came at the beginning of the block or the end.
Column Type Description
`block_timestamp` `TIMESTAMP` The time of the block. Partition column.
`block_height` `INT64` The block height.
`event_type` `STRING` The event type.
`event_index` `INT64` The position of the event within its source.
`event_attributes` `JSON` The event attributes, as key-value pairs.
`source` `STRING` The emission point, begin block or end block.
**Block event types by source** **Rank block-level event types by source, begin block or end block, over one week.** ```sql theme={null} select source, event_type, count(*) as events from `cosmoshub.block_events` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by source, event_type order by events desc limit 20 ``` ## Exceptions Injective runs two layers, and the catalog files them as two chains. `injective` is the Cosmos layer described here, and it is where the chain's tokens and the tokenized assets issued on it sit. Its EVM layer is a dataset of its own, `injectiveevm`, documented under [EVM](/docs/catalog/chain-verticals/evm/index); that is where the app activity sits, along with the value bridged in from other chains. # Injective Source: https://tokenterminal.com/docs/catalog/chain-verticals/cosmos/injective Standardized Injective tables, with one row per event the chain's exchange emitted. `injective` holds the standardized Injective tables, following the schema documented in [the family overview](/docs/catalog/chain-verticals/cosmos/index) exactly, with no differences. Injective has two layers, and the catalog treats them as two separate chains. `injective` is the Cosmos layer, and that is where its tokens and the tokenized assets issued on it are filed. `injectiveevm` is the EVM layer, where Ethereum-style contracts run; it lives in a dataset of its own, documented under [EVM](/docs/catalog/chain-verticals/evm/index), and that is where the app activity is filed, including the value bridged in from other chains. The market pages go deeper on each of these. [Real-world assets](/docs/catalog/real-world-assets/index) and [Stablecoins](/docs/catalog/stablecoins/index) cover the tokenized assets and their daily tables. [Bridges](/docs/catalog/bridges/index) covers transfers between chains, [Projects](/docs/catalog/projects/index) covers app and project activity per chain, and [Tokens](/docs/catalog/tokens/index) covers the token list. ## Tables
Table Since Description
`blocks` 2021-09 One row per block, with its transaction count and proposer.
`transactions` 2021-09 One row per transaction, with its fee and result code.
`transaction_messages` 2021-09 One row per message inside a transaction.
`message_events` 2021-09 One row per event emitted during transaction execution.
`block_events` 2021-09 One row per event emitted outside a transaction.
Injective runs its whole exchange on the chain itself, and every order and trade leaves a note behind, so `message_events` and `block_events` are far larger here than on most Cosmos chains. Keep the `block_timestamp` range narrow and filter on `event_type` as early in the query as you can. ## Sample queries **Event types by day** **Rank event types emitted by transactions on one day.** ```sql theme={null} select event_type, count(*) as events from `injective.message_events` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by event_type order by events desc limit 20 ``` **Tokenized assets by market cap** **Rank the tokenized assets deployed on the Cosmos layer by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'injective' order by daily.market_cap_circulating desc ``` **App activity** **Rank the apps active on the EVM layer by fees over one week.** ```sql theme={null} select apps.name, sum(daily.fees) as fees from `metrics_apps_by_chain.fees_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'injectiveevm' group by apps.name order by fees desc ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/anime/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Anime table resolves to a name. # Anime Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/anime/index Everything the catalog holds for Anime, from raw blocks to project activity. The chain's own record is queryable for Anime, with its eligible catalog layers above it. The chain's own record sits in the `anime` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Anime rows are selected with `chain_id = 'anime'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Anime. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/anime/raw) 2025-01 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/anime/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/anime/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `anime` wherever a catalog table has a chain column, so the same filter selects Anime everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `anime.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/anime/raw The standardized Anime blocks, transactions, logs and internal calls. The `anime` dataset holds the standardized Anime tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-01 One row per block, with its gas and fee totals.
`transactions` 2025-01 One row per transaction, with its receipt fields on the same row.
`logs` 2025-01 One row per event log a contract emitted.
`traces` 2025-01 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `anime.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `anime.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/anime/tokens Anime token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/apechain/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any ApeChain table resolves to a name. # ApeChain Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/apechain/index Everything the catalog holds for ApeChain, from raw blocks to project activity. The chain's own record is queryable for ApeChain, with its eligible catalog layers above it. The chain's own record sits in the `apechain` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the ApeChain rows are selected with `chain_id = 'apechain'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on ApeChain. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/apechain/raw) 2024-08 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/apechain/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/apechain/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `apechain` wherever a catalog table has a chain column, so the same filter selects ApeChain everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `apechain.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/apechain/raw The standardized ApeChain blocks, transactions, logs and internal calls. The `apechain` dataset holds the standardized ApeChain tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-08 One row per block, with its gas and fee totals.
`transactions` 2024-08 One row per transaction, with its receipt fields on the same row.
`logs` 2024-08 One row per event log a contract emitted.
`traces` 2024-08 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `apechain.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `apechain.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/apechain/tokens ApeChain token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Arbitrum that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Arbitrum table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Arbitrum.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'arbitrum' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Arbitrum.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'arbitrum' and project_id = 'robinhood' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Arbitrum.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'arbitrum' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Arbitrum. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/arbitrum/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Arbitrum for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/arbitrum/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/arbitrum/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Arbitrum** **Rank the apps active on Arbitrum by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'arbitrum' group by apps.name order by trading_volume desc ``` **Arbitrum's share** **Work out how much of one app runs on Arbitrum.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/assets Every curated asset issued on Arbitrum, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Arbitrum holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/arbitrum/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/arbitrum/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Arbitrum by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'arbitrum' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Arbitrum deployments by asset kind, and how many were issued on Arbitrum itself.** A deployment is native when the issuer minted the token on Arbitrum, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'arbitrum' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Arbitrum deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xaf88d065e77c8cc2239327c5edb3a432268e5831-arbitrum' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xaf88d065e77c8cc2239327c5edb3a432268e5831-arbitrum' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/bridges Cross-chain transfers that left Arbitrum or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'arbitrum'` for transfers leaving Arbitrum, `destination_chain_id = 'arbitrum'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Arbitrum with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'arbitrum', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'arbitrum', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'arbitrum' or destination_chain_id = 'arbitrum') group by day order by day ``` **Where value went** **Find where the value leaving Arbitrum went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'arbitrum' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Arbitrum value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'arbitrum') as leaving, countif(transfers.destination_chain_id = 'arbitrum') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'arbitrum' or transfers.destination_chain_id = 'arbitrum') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/contracts Every contract deployed on Arbitrum, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Arbitrum, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Arbitrum contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'arbitrum' and contract_address = '0x71962b7f226f96e6ee2bc38c937932dcdb949c1f' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'arbitrum' and creator_address = '0x9d0e2aac65d4d59f55eee0ae301f8064f2859f48' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Arbitrum.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'arbitrum' and contracts.first_deployed_at >= timestamp('2023-06-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/dex Arbitrum trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Arbitrum pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Arbitrum pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'arbitrum' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Arbitrum, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'arbitrum' group by dex_pair_id order by trading_volume desc limit 20 ``` # Arbitrum Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/index Everything the catalog holds for Arbitrum, from raw blocks to project activity. Most of the catalog is queryable for Arbitrum, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `arbitrum` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Arbitrum rows are selected with `chain_id = 'arbitrum'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Arbitrum. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/arbitrum/raw) 2021-05 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/arbitrum/projects) 2021-08 Daily Fees and Revenue for each tracked project, broken out to Arbitrum.
[Apps](/docs/catalog/chain-verticals/evm/arbitrum/apps) 2022-08 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Arbitrum.
[Assets](/docs/catalog/chain-verticals/evm/arbitrum/assets) 2021-06 Every curated asset issued on Arbitrum, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/arbitrum/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/arbitrum/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/arbitrum/contracts) 2023-06 Every contract deployed on Arbitrum, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/arbitrum/stablecoins) 2021-06 Every stablecoin issued on Arbitrum: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/arbitrum/real-world-assets) 2023-02 Tokenized stocks, funds and commodities issued on Arbitrum, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/arbitrum/dex) 2021-07 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/arbitrum/lending) **In progress** The lending markets deployed on Arbitrum, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/arbitrum/bridges) 2022-11 Cross-chain transfers that left Arbitrum or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `arbitrum` wherever a catalog table has a chain column, so the same filter selects Arbitrum everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'arbitrum' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/lending The lending markets deployed on Arbitrum and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Arbitrum markets with `chain_id = 'arbitrum'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Arbitrum markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'arbitrum' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Arbitrum.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'arbitrum' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/projects Daily Fees and Revenue for each tracked project, broken out to Arbitrum. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Arbitrum sit on [Apps](/docs/catalog/chain-verticals/evm/arbitrum/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Arbitrum fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'arbitrum' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Arbitrum's share** **Work out how much of a project runs on Arbitrum.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/raw The standardized Arbitrum blocks, transactions, logs and internal calls. The `arbitrum` dataset holds the standardized Arbitrum tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2021-05 One row per block, with its gas and fee totals.
`transactions` 2022-08 One row per transaction, with its receipt fields on the same row.
`logs` 2021-05 One row per event log a contract emitted.
`traces` 2023-06 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. > > `blocks` also has a 1970-01-01 partition holding rows whose source timestamp is zero; bound the column and it never appears. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `arbitrum.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `arbitrum.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xaf88d065e77c8cc2239327c5edb3a432268e5831' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/real-world-assets Tokenized stocks, funds and commodities issued on Arbitrum, tracked against their underlying instruments. Arbitrum real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/arbitrum/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Arbitrum deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Arbitrum by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'arbitrum' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Arbitrum tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'arbitrum' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/stablecoins Every stablecoin issued on Arbitrum: supply, holders and transfers. Arbitrum stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/arbitrum/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Arbitrum by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'arbitrum' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Arbitrum.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xaf88d065e77c8cc2239327c5edb3a432268e5831-arbitrum' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xaf88d065e77c8cc2239327c5edb3a432268e5831-arbitrum' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arbitrum/tokens Arbitrum token transfers, holder balances and daily prices. Four surfaces cover token activity on Arbitrum. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/arbitrum/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'arbitrum' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Arbitrum tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'arbitrum' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'arbitrum' and movements.token_address = '0xaf88d065e77c8cc2239327c5edb3a432268e5831' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Arbitrum token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'arbitrum', '0xaf88d065e77c8cc2239327c5edb3a432268e5831', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'arbitrum', '0xaf88d065e77c8cc2239327c5edb3a432268e5831', 'erc20' ) where account_address = '0x74bbbb0e7f0bad6938509dd4b556a39a4db1f2cd' order by balance_date desc limit 20 ``` **Daily price** **Read one Arbitrum token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xaf88d065e77c8cc2239327c5edb3a432268e5831-arbitrum' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Arc that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Arc table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Arc.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'arc' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Arc.** `contract_name` is the label the attributing project gives an address, such as `GatewayWallet` or a token's own contract. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'arc' and project_id = 'circle' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Arc.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'arc' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/assets Every curated asset issued on Arc, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Arc holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/arc/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/arc/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Arc by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-09-20') and daily.timestamp < timestamp('2026-09-21') and deployments.chain_id = 'arc' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Arc deployments by asset kind, and how many were issued on Arc itself.** A deployment is native when the issuer minted the token on Arc, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'arc' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Arc deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x3600000000000000000000000000000000000000-arc' and timestamp >= timestamp('2026-09-14') and timestamp < timestamp('2026-09-21') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x3600000000000000000000000000000000000000-arc' and timestamp >= timestamp('2026-09-14') and timestamp < timestamp('2026-09-21') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/dex Arc trading pools and their daily volume. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Arc pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): `trading_volume_daily`, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume is a flow, so it adds up: a week of daily rows sums to the week, and a set of pools sums to the group. Volume rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Arc pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-10-14') and timestamp < timestamp('2026-10-15') and chain_id = 'arc' order by trading_volume desc limit 20 ) select pools.pool_display_name, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Arc, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-10-12') and timestamp < timestamp('2026-10-19') and chain_id = 'arc' group by dex_pair_id order by trading_volume desc limit 20 ``` # Arc Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/index Everything the catalog holds for Arc, from raw blocks to project activity. Most of the catalog is queryable for Arc, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `arc` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Arc rows are selected with `chain_id = 'arc'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Arc. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/arc/raw) 2026-05 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/arc/projects) 2026-05 Daily Fees and Revenue for each tracked project, broken out to Arc.
[Assets](/docs/catalog/chain-verticals/evm/arc/assets) 2026-05 Every curated asset issued on Arc, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/arc/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/arc/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Stablecoins](/docs/catalog/chain-verticals/evm/arc/stablecoins) 2026-05 Every stablecoin issued on Arc: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/arc/real-world-assets) 2026-09 Tokenized stocks, funds and commodities issued on Arc, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/arc/dex) 2026-09 Trading pools and their daily volume.
## Filtering `chain_id` reads `arc` wherever a catalog table has a chain column, so the same filter selects Arc everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'arc' and daily.timestamp >= timestamp('2026-09-01') and daily.timestamp < timestamp('2026-09-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/projects Daily Fees and Revenue for each tracked project, broken out to Arc. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Circle. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Arc fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-09-14') and daily.timestamp < timestamp('2026-09-21') and daily.chain_id = 'arc' and daily.project_id = 'circle' order by daily.timestamp ``` **Arc's share** **Work out how much of a project runs on Arc.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-09-14') and timestamp < timestamp('2026-09-21') and project_id = 'circle' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/raw The standardized Arc blocks, transactions, logs and internal calls. The `arc` dataset holds the standardized Arc tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2026-05 One row per block, with its gas and fee totals.
`transactions` 2026-05 One row per transaction, with its receipt fields on the same row.
`logs` 2026-05 One row per event log a contract emitted.
`traces` 2026-05 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `arc.transactions` where block_timestamp >= timestamp('2026-09-14') and block_timestamp < timestamp('2026-09-21') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `arc.logs` where block_timestamp >= timestamp('2026-09-18') and block_timestamp < timestamp('2026-09-19') and address = '0x3600000000000000000000000000000000000000' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/real-world-assets Tokenized stocks, funds and commodities issued on Arc, tracked against their underlying instruments. Arc real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/arc/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Arc deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Arc by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-09-20') and daily.timestamp < timestamp('2026-09-21') and deployments.chain_id = 'arc' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Arc tokenized funds with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'arc' and assets.asset_type = 'tokenized-funds' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/stablecoins Every stablecoin issued on Arc: supply, holders and transfers. Arc stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/arc/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Arc by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-09-20') and daily.timestamp < timestamp('2026-09-21') and deployments.chain_id = 'arc' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Arc.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x3600000000000000000000000000000000000000-arc' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-09-21') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x3600000000000000000000000000000000000000-arc' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-09-21') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/arc/tokens Arc token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Avalanche that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Avalanche table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Avalanche.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'avalanche' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Avalanche.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'avalanche' and project_id = 'dinari' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Avalanche.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'avalanche' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Avalanche. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/avalanche/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Avalanche for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/avalanche/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/avalanche/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Avalanche** **Rank the apps active on Avalanche by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'avalanche' group by apps.name order by trading_volume desc ``` **Avalanche's share** **Work out how much of one app runs on Avalanche.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/assets Every curated asset issued on Avalanche, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Avalanche holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/avalanche/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/avalanche/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Avalanche by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'avalanche' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Avalanche deployments by asset kind, and how many were issued on Avalanche itself.** A deployment is native when the issuer minted the token on Avalanche, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'avalanche' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Avalanche deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e-avalanche' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e-avalanche' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/bridges Cross-chain transfers that left Avalanche or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'avalanche'` for transfers leaving Avalanche, `destination_chain_id = 'avalanche'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Avalanche with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'avalanche', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'avalanche', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'avalanche' or destination_chain_id = 'avalanche') group by day order by day ``` **Where value went** **Find where the value leaving Avalanche went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'avalanche' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Avalanche value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'avalanche') as leaving, countif(transfers.destination_chain_id = 'avalanche') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'avalanche' or transfers.destination_chain_id = 'avalanche') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/contracts Every contract deployed on Avalanche, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Avalanche, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Avalanche contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'avalanche' and contract_address = '0xaf1f5acb5bb2d2a99787b38b167a3698cee5f7aa' ``` **A factory's output** **List the contracts one factory created.** The CoinTool batch minter calls `CREATE` for every contract it stamps out, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'avalanche' and creator_address = '0x9ec1c3dcf667f2035fb4cd2eb42a1566fd54d2b7' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Avalanche.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'avalanche' and contracts.first_deployed_at >= timestamp('2023-07-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/dex Avalanche trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Avalanche pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Avalanche pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'avalanche' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Avalanche, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'avalanche' group by dex_pair_id order by trading_volume desc limit 20 ``` # Avalanche Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/index Everything the catalog holds for Avalanche, from raw blocks to project activity. Most of the catalog is queryable for Avalanche, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `avalanche` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Avalanche rows are selected with `chain_id = 'avalanche'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Avalanche. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/avalanche/raw) 2020-09 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/avalanche/projects) 2020-09 Daily Fees and Revenue for each tracked project, broken out to Avalanche.
[Apps](/docs/catalog/chain-verticals/evm/avalanche/apps) 2023-06 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Avalanche.
[Assets](/docs/catalog/chain-verticals/evm/avalanche/assets) 2021-02 Every curated asset issued on Avalanche, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/avalanche/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/avalanche/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/avalanche/contracts) 2023-07 Every contract deployed on Avalanche, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/avalanche/stablecoins) 2021-02 Every stablecoin issued on Avalanche: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/avalanche/real-world-assets) 2022-10 Tokenized stocks, funds and commodities issued on Avalanche, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/avalanche/dex) 2023-06 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/avalanche/lending) **In progress** The lending markets deployed on Avalanche, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/avalanche/bridges) 2022-09 Cross-chain transfers that left Avalanche or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `avalanche` wherever a catalog table has a chain column, so the same filter selects Avalanche everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'avalanche' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/lending The lending markets deployed on Avalanche and the asset each one lends. A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Avalanche markets with `chain_id = 'avalanche'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Avalanche markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'avalanche' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Avalanche.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'avalanche' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/projects Daily Fees and Revenue for each tracked project, broken out to Avalanche. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Avalanche sit on [Apps](/docs/catalog/chain-verticals/evm/avalanche/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Avalanche fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'avalanche' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Avalanche's share** **Work out how much of a project runs on Avalanche.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/raw The standardized Avalanche blocks, transactions, logs and internal calls. The `avalanche` dataset holds the standardized Avalanche tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2020-09 One row per block, with its gas and fee totals.
`transactions` 2020-09 One row per transaction, with its receipt fields on the same row.
`logs` 2020-09 One row per event log a contract emitted.
`traces` 2020-09 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `avalanche.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `avalanche.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/real-world-assets Tokenized stocks, funds and commodities issued on Avalanche, tracked against their underlying instruments. Avalanche real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/avalanche/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Avalanche deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Avalanche by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'avalanche' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Avalanche tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'avalanche' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/stablecoins Every stablecoin issued on Avalanche: supply, holders and transfers. Avalanche stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/avalanche/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Avalanche by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'avalanche' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Avalanche.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e-avalanche' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e-avalanche' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/avalanche/tokens Avalanche token transfers, holder balances and daily prices. Four surfaces cover token activity on Avalanche. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/avalanche/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'avalanche' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Avalanche tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'avalanche' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'avalanche' and movements.token_address = '0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Avalanche token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'avalanche', '0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'avalanche', '0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e', 'erc20' ) where account_address = '0xa44e85f5bb4c6e7efe5eb69931e587d9c695ae2e' order by balance_date desc limit 20 ``` **Daily price** **Read one Avalanche token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e-avalanche' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Base that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Base table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Base.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'base' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Base.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'base' and project_id = 'dinari' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Base.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'base' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Base. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/base/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Base for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/base/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/base/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Base** **Rank the apps active on Base by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'base' group by apps.name order by trading_volume desc ``` **Base's share** **Work out how much of one app runs on Base.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/assets Every curated asset issued on Base, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Base holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/base/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/base/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Base by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'base' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Base deployments by asset kind, and how many were issued on Base itself.** A deployment is native when the issuer minted the token on Base, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'base' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Base deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913-base' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913-base' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/bridges Cross-chain transfers that left Base or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'base'` for transfers leaving Base, `destination_chain_id = 'base'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Base with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'base', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'base', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'base' or destination_chain_id = 'base') group by day order by day ``` **Where value went** **Find where the value leaving Base went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'base' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Base value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'base') as leaving, countif(transfers.destination_chain_id = 'base') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'base' or transfers.destination_chain_id = 'base') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/contracts Every contract deployed on Base, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Base, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Base contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'base' and contract_address = '0xe944e688a31a9177271a9f02df3e0f1647174b51' ``` **A factory's output** **List the contracts one factory created.** The XEN torrent minter calls `CREATE` for every mint it batches, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'base' and creator_address = '0x379002701bf6f2862e3dfdd1f96d3c5e1bf450b6' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Base.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'base' and contracts.first_deployed_at >= timestamp('2023-06-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/dex Base trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Base pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Base pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'base' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Base, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'base' group by dex_pair_id order by trading_volume desc limit 20 ``` # Base Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/index Everything the catalog holds for Base, from raw blocks to project activity. Most of the catalog is queryable for Base, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `base` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Base rows are selected with `chain_id = 'base'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Base. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/base/raw) 2023-06 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/base/projects) 2023-02 Daily Fees and Revenue for each tracked project, broken out to Base.
[Apps](/docs/catalog/chain-verticals/evm/base/apps) 2023-08 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Base.
[Assets](/docs/catalog/chain-verticals/evm/base/assets) 2023-04 Every curated asset issued on Base, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/base/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/base/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/base/contracts) 2023-06 Every contract deployed on Base, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/base/stablecoins) 2023-07 Every stablecoin issued on Base: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/base/real-world-assets) 2023-04 Tokenized stocks, funds and commodities issued on Base, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/base/dex) 2023-08 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/base/lending) **In progress** The lending markets deployed on Base, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/base/bridges) 2023-07 Cross-chain transfers that left Base or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `base` wherever a catalog table has a chain column, so the same filter selects Base everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'base' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/lending The lending markets deployed on Base and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Base markets with `chain_id = 'base'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Base markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'base' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Base.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'base' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/projects Daily Fees and Revenue for each tracked project, broken out to Base. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Base sit on [Apps](/docs/catalog/chain-verticals/evm/base/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Base fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'base' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Base's share** **Work out how much of a project runs on Base.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/raw The standardized Base blocks, transactions, logs and internal calls. The `base` dataset holds the standardized Base tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2023-06 One row per block, with its gas and fee totals.
`transactions` 2023-06 One row per transaction, with its receipt fields on the same row.
`logs` 2023-06 One row per event log a contract emitted.
`traces` 2023-06 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `base.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `base.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x833589fcd6edb6e08f4c7c32d4f71b54bda02913' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/real-world-assets Tokenized stocks, funds and commodities issued on Base, tracked against their underlying instruments. Base real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/base/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Base deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Base by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'base' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Base tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'base' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/stablecoins Every stablecoin issued on Base: supply, holders and transfers. Base stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/base/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Base by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'base' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Base.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913-base' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913-base' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/base/tokens Base token transfers, holder balances and daily prices. Four surfaces cover token activity on Base. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/base/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'base' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Base tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'base' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'base' and movements.token_address = '0x833589fcd6edb6e08f4c7c32d4f71b54bda02913' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Base token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'base', '0x833589fcd6edb6e08f4c7c32d4f71b54bda02913', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'base', '0x833589fcd6edb6e08f4c7c32d4f71b54bda02913', 'erc20' ) where account_address = '0xde16cae674b3208ac51c700a37784ccb6239f15f' order by balance_date desc limit 20 ``` **Daily price** **Read one Base token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x833589fcd6edb6e08f4c7c32d4f71b54bda02913-base' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Berachain that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Berachain table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Berachain.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'berachain' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Berachain.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'berachain' and project_id = 'beraborrow' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Berachain.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'berachain' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/assets Every curated asset issued on Berachain, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Berachain holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/berachain/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/berachain/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Berachain by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'berachain' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Berachain deployments by asset kind, and how many were issued on Berachain itself.** A deployment is native when the issuer minted the token on Berachain, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'berachain' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Berachain deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'bold-0xf05a207442f14e446b0e32b12d2043bfc68cb1c9-berachain' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'bold-0xf05a207442f14e446b0e32b12d2043bfc68cb1c9-berachain' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/bridges Cross-chain transfers that left Berachain or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'berachain'` for transfers leaving Berachain, `destination_chain_id = 'berachain'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Berachain with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'berachain', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'berachain', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'berachain' or destination_chain_id = 'berachain') group by day order by day ``` **Where value went** **Find where the value leaving Berachain went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'berachain' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Berachain value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'berachain') as leaving, countif(transfers.destination_chain_id = 'berachain') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'berachain' or transfers.destination_chain_id = 'berachain') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/contracts Every contract deployed on Berachain, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Berachain, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Berachain contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'berachain' and contract_address = '0xb7222f32433f016842e049c62129be2b6b694ed2' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'berachain' and creator_address = '0xa98ded78b56a720dc965f609534cde2af9d22c40' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Berachain.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'berachain' and contracts.first_deployed_at >= timestamp('2025-01-01') order by contracts.first_deployed_at desc limit 100 ``` # Berachain Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/index Everything the catalog holds for Berachain, from raw blocks to project activity. Most of the catalog is queryable for Berachain, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `berachain` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Berachain rows are selected with `chain_id = 'berachain'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Berachain. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/berachain/raw) 2025-01 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/berachain/projects) 2025-01 Daily Fees and Revenue for each tracked project, broken out to Berachain.
[Assets](/docs/catalog/chain-verticals/evm/berachain/assets) 2024-01 Every curated asset issued on Berachain, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/berachain/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/berachain/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/berachain/contracts) 2025-01 Every contract deployed on Berachain, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/berachain/stablecoins) 2025-01 Every stablecoin issued on Berachain: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/berachain/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on Berachain, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/berachain/bridges) 2025-01 Cross-chain transfers that left Berachain or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `berachain` wherever a catalog table has a chain column, so the same filter selects Berachain everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'berachain' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/projects Daily Fees and Revenue for each tracked project, broken out to Berachain. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Berachain fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'berachain' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Berachain's share** **Work out how much of a project runs on Berachain.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/raw The standardized Berachain blocks, transactions, logs and internal calls. The `berachain` dataset holds the standardized Berachain tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-01 One row per block, with its gas and fee totals.
`transactions` 2025-01 One row per transaction, with its receipt fields on the same row.
`logs` 2025-01 One row per event log a contract emitted.
`traces` 2025-01 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `berachain.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `berachain.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xf05a207442f14e446b0e32b12d2043bfc68cb1c9' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/real-world-assets Tokenized stocks, funds and commodities issued on Berachain, tracked against their underlying instruments. Berachain real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/berachain/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Berachain deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Berachain by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'berachain' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Berachain tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'berachain' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/stablecoins Every stablecoin issued on Berachain: supply, holders and transfers. Berachain stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/berachain/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Berachain by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'berachain' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Berachain.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'bold-0xf05a207442f14e446b0e32b12d2043bfc68cb1c9-berachain' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'bold-0xf05a207442f14e446b0e32b12d2043bfc68cb1c9-berachain' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/berachain/tokens Berachain token transfers, holder balances and daily prices. Four surfaces cover token activity on Berachain. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/berachain/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'berachain' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Berachain tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'berachain' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'berachain' and movements.token_address = '0x6969696969696969696969696969696969696969' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Berachain token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'berachain', '0x6969696969696969696969696969696969696969', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'berachain', '0x6969696969696969696969696969696969696969', 'erc20' ) where account_address = '0x1ae7dd7ae06f6c58b4524d9c1f816094b1bccd8e' order by balance_date desc limit 20 ``` **Daily price** **Read one Berachain token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x6969696969696969696969696969696969696969-berachain' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Blast that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Blast table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Blast.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'blast' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Blast.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'blast' and project_id = 'dinari' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Blast.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'blast' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Blast. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/blast/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Blast for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/blast/dex). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Blast** **Rank the apps active on Blast by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'blast' group by apps.name order by trading_volume desc ``` **Blast's share** **Work out how much of one app runs on Blast.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/assets Every curated asset issued on Blast, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Blast holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/blast/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/blast/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Blast by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'blast' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Blast deployments by asset kind, and how many were issued on Blast itself.** A deployment is native when the issuer minted the token on Blast, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'blast' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Blast deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'aapld-0x30fa6b130399cba3037f77472bb4a681c6c3153d-blast' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'aapld-0x30fa6b130399cba3037f77472bb4a681c6c3153d-blast' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/contracts Every contract deployed on Blast, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Blast, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Blast contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'blast' and contract_address = '0x93814ba469cda859e039a14635b27374d15fbe0e' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'blast' and creator_address = '0xa0df6adaa4f7e880b4b3c40147c6ae92124d88a8' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Blast.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'blast' and contracts.first_deployed_at >= timestamp('2024-02-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/dex Blast trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Blast pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Blast pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'blast' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Blast, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'blast' group by dex_pair_id order by trading_volume desc limit 20 ``` # Blast Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/index Everything the catalog holds for Blast, from raw blocks to project activity. Most of the catalog is queryable for Blast, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `blast` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Blast rows are selected with `chain_id = 'blast'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Blast. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/blast/raw) 2024-02 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/blast/projects) 2024-02 Daily Fees and Revenue for each tracked project, broken out to Blast.
[Apps](/docs/catalog/chain-verticals/evm/blast/apps) 2024-03 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Blast.
[Assets](/docs/catalog/chain-verticals/evm/blast/assets) 2024-01 Every curated asset issued on Blast, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/blast/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/blast/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/blast/contracts) 2024-02 Every contract deployed on Blast, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/blast/stablecoins) 2024-04 Every stablecoin issued on Blast: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/blast/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on Blast, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/blast/dex) 2024-03 Trading pools, their daily volume, value locked and fees.
## Filtering `chain_id` reads `blast` wherever a catalog table has a chain column, so the same filter selects Blast everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'blast' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/projects Daily Fees and Revenue for each tracked project, broken out to Blast. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Blast sit on [Apps](/docs/catalog/chain-verticals/evm/blast/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Blast fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'blast' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Blast's share** **Work out how much of a project runs on Blast.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/raw The standardized Blast blocks, transactions, logs and internal calls. The `blast` dataset holds the standardized Blast tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-02 One row per block, with its gas and fee totals.
`transactions` 2024-02 One row per transaction, with its receipt fields on the same row.
`logs` 2024-02 One row per event log a contract emitted.
`traces` 2024-02 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `blast.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `blast.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x30fa6b130399cba3037f77472bb4a681c6c3153d' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/real-world-assets Tokenized stocks, funds and commodities issued on Blast, tracked against their underlying instruments. Blast real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/blast/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Blast deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Blast by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'blast' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Blast tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'blast' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/stablecoins Every stablecoin issued on Blast: supply, holders and transfers. Blast stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/blast/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Blast by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'blast' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Blast.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'aapld-0x30fa6b130399cba3037f77472bb4a681c6c3153d-blast' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'aapld-0x30fa6b130399cba3037f77472bb4a681c6c3153d-blast' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/blast/tokens Blast token transfers, holder balances and daily prices. Four surfaces cover token activity on Blast. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/blast/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'blast' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Blast tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'blast' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'blast' and movements.token_address = '0x4300000000000000000000000000000000000004' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Blast token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'blast', '0x4300000000000000000000000000000000000004', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'blast', '0x4300000000000000000000000000000000000004', 'erc20' ) where account_address = '0xb2676eb41b0356dbb2059190490669e920b8baf3' order by balance_date desc limit 20 ``` **Daily price** **Read one Blast token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x4300000000000000000000000000000000000004-blast' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bob/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on BOB that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any BOB table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on BOB.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'bob' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on BOB.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'bob' and project_id = 'euler' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on BOB.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'bob' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bob/assets Every curated asset issued on BOB, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what BOB holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). [Stablecoins](/docs/catalog/chain-verticals/evm/bob/stablecoins) scopes this layer further. ## Sample queries **Largest assets** **Rank the assets on BOB by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'bob' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count BOB deployments by asset kind, and how many were issued on BOB itself.** A deployment is native when the issuer minted the token on BOB, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'bob' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one BOB deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'satusd-0xecf21b335b41f9d5a89f6186a99c19a3c467871f-bob' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'satusd-0xecf21b335b41f9d5a89f6186a99c19a3c467871f-bob' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bob/bridges Cross-chain transfers that left BOB or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'bob'` for transfers leaving BOB, `destination_chain_id = 'bob'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving BOB with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'bob', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'bob', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'bob' or destination_chain_id = 'bob') group by day order by day ``` **Where value went** **Find where the value leaving BOB went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'bob' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the BOB value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'bob') as leaving, countif(transfers.destination_chain_id = 'bob') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'bob' or transfers.destination_chain_id = 'bob') group by apps.name order by volume_usd desc ``` # BOB Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bob/index Everything the catalog holds for BOB, from raw blocks to project activity. Most of the catalog is queryable for BOB, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `bob` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the BOB rows are selected with `chain_id = 'bob'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on BOB. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/bob/raw) 2024-04 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/bob/projects) 2024-04 Daily Fees and Revenue for each tracked project, broken out to BOB.
[Assets](/docs/catalog/chain-verticals/evm/bob/assets) 2025-02 Every curated asset issued on BOB, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/bob/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/bob/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Stablecoins](/docs/catalog/chain-verticals/evm/bob/stablecoins) 2025-02 Every stablecoin issued on BOB: supply, holders and transfers.
[Bridges](/docs/catalog/chain-verticals/evm/bob/bridges) 2024-09 Cross-chain transfers that left BOB or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `bob` wherever a catalog table has a chain column, so the same filter selects BOB everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'bob' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bob/projects Daily Fees and Revenue for each tracked project, broken out to BOB. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily BOB fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'bob' and daily.project_id = 'uniswap' order by daily.timestamp ``` **BOB's share** **Work out how much of a project runs on BOB.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bob/raw The standardized BOB blocks, transactions, logs and internal calls. The `bob` dataset holds the standardized BOB tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-04 One row per block, with its gas and fee totals.
`transactions` 2024-04 One row per transaction, with its receipt fields on the same row.
`logs` 2024-04 One row per event log a contract emitted.
`traces` 2024-04 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `bob.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `bob.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xecf21b335b41f9d5a89f6186a99c19a3c467871f' ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bob/stablecoins Every stablecoin issued on BOB: supply, holders and transfers. BOB stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/bob/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on BOB by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'bob' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on BOB.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'satusd-0xecf21b335b41f9d5a89f6186a99c19a3c467871f-bob' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'satusd-0xecf21b335b41f9d5a89f6186a99c19a3c467871f-bob' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bob/tokens BOB token transfers, holder balances and daily prices. Four surfaces cover token activity on BOB. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/bob/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'bob' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest BOB tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'bob' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'bob' and movements.token_address = '0x03c7054bcb39f7b2e5b2c7acb37583e32d70cfa3' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one BOB token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'bob', '0x03c7054bcb39f7b2e5b2c7acb37583e32d70cfa3', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'bob', '0x03c7054bcb39f7b2e5b2c7acb37583e32d70cfa3', 'erc20' ) where account_address = '0x8ce8a7ea34035adb46caae3f66f012dacbbe9f01' order by balance_date desc limit 20 ``` **Daily price** **Read one BOB token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x03c7054bcb39f7b2e5b2c7acb37583e32d70cfa3-bob' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bobanetwork/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Boba Network that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Boba Network table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Boba Network.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'bobanetwork' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Boba Network.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'bobanetwork' and project_id = 'uniswap' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Boba Network.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'bobanetwork' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bobanetwork/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Boba Network. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/bobanetwork/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Boba Network for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/bobanetwork/dex). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Boba Network** **Rank the apps active on Boba Network by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'bobanetwork' group by apps.name order by trading_volume desc ``` **Boba Network's share** **Work out how much of one app runs on Boba Network.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bobanetwork/contracts Every contract deployed on Boba Network, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Boba Network, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Boba Network contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'bobanetwork' and contract_address = '0x0aed5e29a06a6bc0ca5d5f9cbbe2014b62bb8db0' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'bobanetwork' and creator_address = '0x81e8f26a96e62bd26c6ec9b58b6387fd09d2dc85' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Boba Network.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'bobanetwork' and contracts.first_deployed_at >= timestamp('2021-11-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bobanetwork/dex Boba Network trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Boba Network pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Boba Network pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'bobanetwork' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Boba Network, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'bobanetwork' group by dex_pair_id order by trading_volume desc limit 20 ``` # Boba Network Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bobanetwork/index Everything the catalog holds for Boba Network, from raw blocks to project activity. The chain's own record is queryable for Boba Network, with its eligible catalog layers above it. The chain's own record sits in the `bobanetwork` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Boba Network rows are selected with `chain_id = 'bobanetwork'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Boba Network. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/bobanetwork/raw) 2021-10 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/bobanetwork/projects) 2021-10 Daily Fees and Revenue for each tracked project, broken out to Boba Network.
[Apps](/docs/catalog/chain-verticals/evm/bobanetwork/apps) 2023-07 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Boba Network.
[Tokens](/docs/catalog/chain-verticals/evm/bobanetwork/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/bobanetwork/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/bobanetwork/contracts) 2021-11 Every contract deployed on Boba Network, with the account that created it.
[DEX](/docs/catalog/chain-verticals/evm/bobanetwork/dex) 2023-07 Trading pools, their daily volume, value locked and fees.
## Filtering `chain_id` reads `bobanetwork` wherever a catalog table has a chain column, so the same filter selects Boba Network everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `bobanetwork.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bobanetwork/projects Daily Fees and Revenue for each tracked project, broken out to Boba Network. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Boba Network sit on [Apps](/docs/catalog/chain-verticals/evm/bobanetwork/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Boba Network fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'bobanetwork' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Boba Network's share** **Work out how much of a project runs on Boba Network.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bobanetwork/raw The standardized Boba Network blocks, transactions, logs and internal calls. The `bobanetwork` dataset holds the standardized Boba Network tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2021-10 One row per block, with its gas and fee totals.
`transactions` 2021-10 One row per transaction, with its receipt fields on the same row.
`logs` 2021-10 One row per event log a contract emitted.
`traces` 2021-10 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `bobanetwork.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `bobanetwork.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x66a2a913e447d6b4bf33efbec43aaef87890fbbc' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bobanetwork/tokens Boba Network token transfers, holder balances and daily prices. Four surfaces cover token activity on Boba Network. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/assets/registry) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'bobanetwork' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Boba Network tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'bobanetwork' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'bobanetwork' and movements.token_address = '0x66a2a913e447d6b4bf33efbec43aaef87890fbbc' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Boba Network token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'bobanetwork', '0x66a2a913e447d6b4bf33efbec43aaef87890fbbc', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'bobanetwork', '0x66a2a913e447d6b4bf33efbec43aaef87890fbbc', 'erc20' ) where account_address = '0xde125f169caad0bce3aad68703e53b3fdac8a6e6' order by balance_date desc limit 20 ``` **Daily price** **Read one Boba Network token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x66a2a913e447d6b4bf33efbec43aaef87890fbbc-bobanetwork' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on BNB Smart Chain that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any BNB Smart Chain table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on BNB Smart Chain.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'bsc' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on BNB Smart Chain.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'bsc' and project_id = 'xstocks' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on BNB Smart Chain.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'bsc' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to BNB Smart Chain. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/bsc/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on BNB Smart Chain for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/bsc/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/bsc/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on BNB Smart Chain** **Rank the apps active on BNB Smart Chain by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'bsc' group by apps.name order by trading_volume desc ``` **BNB Smart Chain's share** **Work out how much of one app runs on BNB Smart Chain.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/assets Every curated asset issued on BNB Smart Chain, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what BNB Smart Chain holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/bsc/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/bsc/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on BNB Smart Chain by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'bsc' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count BNB Smart Chain deployments by asset kind, and how many were issued on BNB Smart Chain itself.** A deployment is native when the issuer minted the token on BNB Smart Chain, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'bsc' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one BNB Smart Chain deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d-bsc' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d-bsc' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/bridges Cross-chain transfers that left BNB Smart Chain or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'bsc'` for transfers leaving BNB Smart Chain, `destination_chain_id = 'bsc'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving BNB Smart Chain with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'bsc', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'bsc', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'bsc' or destination_chain_id = 'bsc') group by day order by day ``` **Where value went** **Find where the value leaving BNB Smart Chain went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'bsc' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the BNB Smart Chain value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'bsc') as leaving, countif(transfers.destination_chain_id = 'bsc') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'bsc' or transfers.destination_chain_id = 'bsc') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/contracts Every contract deployed on BNB Smart Chain, with the account that created it. `dimensions.contracts` holds one row per contract deployed on BNB Smart Chain, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one BNB Smart Chain contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'bsc' and contract_address = '0x98da4b55dc19d31b57007a514b137bf431b487d6' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'bsc' and creator_address = '0x0000000000004946c0e9f43f4dee607b0ef1fa1c' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on BNB Smart Chain.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'bsc' and contracts.first_deployed_at >= timestamp('2020-08-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/dex BNB Smart Chain trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. BNB Smart Chain pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank BNB Smart Chain pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'bsc' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on BNB Smart Chain, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'bsc' group by dex_pair_id order by trading_volume desc limit 20 ``` # BNB Smart Chain Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/index Everything the catalog holds for BNB Smart Chain, from raw blocks to project activity. Most of the catalog is queryable for BNB Smart Chain, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `bsc` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the BNB Smart Chain rows are selected with `chain_id = 'bsc'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on BNB Smart Chain. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/bsc/raw) 2020-04 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/bsc/projects) 2020-08 Daily Fees and Revenue for each tracked project, broken out to BNB Smart Chain.
[Apps](/docs/catalog/chain-verticals/evm/bsc/apps) 2023-03 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to BNB Smart Chain.
[Assets](/docs/catalog/chain-verticals/evm/bsc/assets) 2020-09 Every curated asset issued on BNB Smart Chain, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/bsc/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/bsc/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/bsc/contracts) 2020-08 Every contract deployed on BNB Smart Chain, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/bsc/stablecoins) 2020-09 Every stablecoin issued on BNB Smart Chain: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/bsc/real-world-assets) 2023-02 Tokenized stocks, funds and commodities issued on BNB Smart Chain, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/bsc/dex) 2023-03 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/bsc/lending) **In progress** The lending markets deployed on BNB Smart Chain, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/bsc/bridges) 2022-09 Cross-chain transfers that left BNB Smart Chain or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `bsc` wherever a catalog table has a chain column, so the same filter selects BNB Smart Chain everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'bsc' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/lending The lending markets deployed on BNB Smart Chain and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the BNB Smart Chain markets with `chain_id = 'bsc'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count BNB Smart Chain markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'bsc' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on BNB Smart Chain.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'bsc' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/projects Daily Fees and Revenue for each tracked project, broken out to BNB Smart Chain. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on BNB Smart Chain sit on [Apps](/docs/catalog/chain-verticals/evm/bsc/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily BNB Smart Chain fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'bsc' and daily.project_id = 'uniswap' order by daily.timestamp ``` **BNB Smart Chain's share** **Work out how much of a project runs on BNB Smart Chain.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/raw The standardized BNB Smart Chain blocks, transactions, logs and internal calls. The `bsc` dataset holds the standardized BNB Smart Chain tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2020-04 One row per block, with its gas and fee totals.
`transactions` 2020-04 One row per transaction, with its receipt fields on the same row.
`logs` 2020-04 One row per event log a contract emitted.
`traces` 2020-04 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `bsc.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `bsc.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/real-world-assets Tokenized stocks, funds and commodities issued on BNB Smart Chain, tracked against their underlying instruments. BNB Smart Chain real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/bsc/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its BNB Smart Chain deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on BNB Smart Chain by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'bsc' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List BNB Smart Chain tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'bsc' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/stablecoins Every stablecoin issued on BNB Smart Chain: supply, holders and transfers. BNB Smart Chain stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/bsc/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on BNB Smart Chain by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'bsc' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on BNB Smart Chain.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d-bsc' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d-bsc' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/bsc/tokens BNB Smart Chain token transfers, holder balances and daily prices. Four surfaces cover token activity on BNB Smart Chain. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/bsc/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'bsc' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest BNB Smart Chain tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'bsc' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'bsc' and movements.token_address = '0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one BNB Smart Chain token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'bsc', '0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'bsc', '0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d', 'erc20' ) where account_address = '0xb92fe925dc43a0ecde6c8b1a2709c170ec4fff4f' order by balance_date desc limit 20 ``` **Daily price** **Read one BNB Smart Chain token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d-bsc' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Celo that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Celo table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Celo.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'celo' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Celo.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'celo' and project_id = 'textilecredit' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Celo.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'celo' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Celo. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/celo/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Celo for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/celo/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/celo/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Celo** **Rank the apps active on Celo by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'celo' group by apps.name order by trading_volume desc ``` **Celo's share** **Work out how much of one app runs on Celo.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/assets Every curated asset issued on Celo, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Celo holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/celo/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/celo/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Celo by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'celo' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Celo deployments by asset kind, and how many were issued on Celo itself.** A deployment is native when the issuer minted the token on Celo, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'celo' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Celo deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xceba9300f2b948710d2653dd7b07f33a8b32118c-celo' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xceba9300f2b948710d2653dd7b07f33a8b32118c-celo' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/bridges Cross-chain transfers that left Celo or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'celo'` for transfers leaving Celo, `destination_chain_id = 'celo'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Celo with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'celo', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'celo', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'celo' or destination_chain_id = 'celo') group by day order by day ``` **Where value went** **Find where the value leaving Celo went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'celo' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Celo value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'celo') as leaving, countif(transfers.destination_chain_id = 'celo') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'celo' or transfers.destination_chain_id = 'celo') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/contracts Every contract deployed on Celo, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Celo, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Celo contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'celo' and contract_address = '0x769180cbd6fac94bd001512d8d54150493b54f90' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'celo' and creator_address = '0x62a25e867f7853b362bbda8c0f400466a8063880' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Celo.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'celo' and contracts.first_deployed_at >= timestamp('2020-04-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/dex Celo trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Celo pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Celo pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'celo' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Celo, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'celo' group by dex_pair_id order by trading_volume desc limit 20 ``` # Celo Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/index Everything the catalog holds for Celo, from raw blocks to project activity. Most of the catalog is queryable for Celo, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `celo` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Celo rows are selected with `chain_id = 'celo'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Celo. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/celo/raw) 2020-04 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/celo/projects) 2020-04 Daily Fees and Revenue for each tracked project, broken out to Celo.
[Apps](/docs/catalog/chain-verticals/evm/celo/apps) 2022-07 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Celo.
[Assets](/docs/catalog/chain-verticals/evm/celo/assets) 2020-04 Every curated asset issued on Celo, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/celo/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/celo/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/celo/contracts) 2020-04 Every contract deployed on Celo, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/celo/stablecoins) 2020-04 Every stablecoin issued on Celo: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/celo/real-world-assets) 2021-09 Tokenized stocks, funds and commodities issued on Celo, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/celo/dex) 2022-07 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/celo/lending) **In progress** The lending markets deployed on Celo, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/celo/bridges) 2023-04 Cross-chain transfers that left Celo or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `celo` wherever a catalog table has a chain column, so the same filter selects Celo everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'celo' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/lending The lending markets deployed on Celo and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Celo markets with `chain_id = 'celo'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Celo markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'celo' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Celo.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'celo' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/projects Daily Fees and Revenue for each tracked project, broken out to Celo. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Celo sit on [Apps](/docs/catalog/chain-verticals/evm/celo/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Celo fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'celo' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Celo's share** **Work out how much of a project runs on Celo.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/raw The standardized Celo blocks, transactions, logs and internal calls. The `celo` dataset holds the standardized Celo tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2020-04 One row per block, with its gas and fee totals.
`transactions` 2020-04 One row per transaction, with its receipt fields on the same row.
`logs` 2020-04 One row per event log a contract emitted.
`traces` 2020-04 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `celo.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `celo.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xceba9300f2b948710d2653dd7b07f33a8b32118c' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/real-world-assets Tokenized stocks, funds and commodities issued on Celo, tracked against their underlying instruments. Celo real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/celo/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Celo deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Celo by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'celo' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Celo tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'celo' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/stablecoins Every stablecoin issued on Celo: supply, holders and transfers. Celo stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/celo/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Celo by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'celo' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Celo.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xceba9300f2b948710d2653dd7b07f33a8b32118c-celo' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xceba9300f2b948710d2653dd7b07f33a8b32118c-celo' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/celo/tokens Celo token transfers, holder balances and daily prices. Four surfaces cover token activity on Celo. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/celo/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'celo' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Celo tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'celo' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'celo' and movements.token_address = '0xceba9300f2b948710d2653dd7b07f33a8b32118c' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Celo token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'celo', '0xceba9300f2b948710d2653dd7b07f33a8b32118c', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'celo', '0xceba9300f2b948710d2653dd7b07f33a8b32118c', 'erc20' ) where account_address = '0xa70c1084b65c6f259f698c050b983b925fe30e08' order by balance_date desc limit 20 ``` **Daily price** **Read one Celo token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xceba9300f2b948710d2653dd7b07f33a8b32118c-celo' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Ethereum that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Ethereum table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Ethereum.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'ethereum' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Ethereum.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'ethereum' and project_id = 'xstocks' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Ethereum.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'ethereum' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Ethereum. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/ethereum/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Ethereum for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/ethereum/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/ethereum/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Ethereum** **Rank the apps active on Ethereum by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'ethereum' group by apps.name order by trading_volume desc ``` **Ethereum's share** **Work out how much of one app runs on Ethereum.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/assets Every curated asset issued on Ethereum, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Ethereum holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/ethereum/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/ethereum/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Ethereum by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'ethereum' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Ethereum deployments by asset kind, and how many were issued on Ethereum itself.** A deployment is native when the issuer minted the token on Ethereum, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'ethereum' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Ethereum deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/bridges Cross-chain transfers that left Ethereum or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'ethereum'` for transfers leaving Ethereum, `destination_chain_id = 'ethereum'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Ethereum with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'ethereum', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'ethereum', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'ethereum' or destination_chain_id = 'ethereum') group by day order by day ``` **Where value went** **Find where the value leaving Ethereum went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'ethereum' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Ethereum value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'ethereum') as leaving, countif(transfers.destination_chain_id = 'ethereum') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'ethereum' or transfers.destination_chain_id = 'ethereum') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/contracts Every contract deployed on Ethereum, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Ethereum, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Ethereum contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'ethereum' and contract_address = '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2' ``` **A factory's output** **List the contracts one factory created.** The Uniswap v3 factory calls `CREATE` for every pool it deploys, so `creator_address` returns the pool list. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'ethereum' and creator_address = '0x1f98431c8ad98523631ae4a59f267346ea31f984' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Ethereum.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'ethereum' and contracts.first_deployed_at >= timestamp('2026-08-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/dex Ethereum trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Ethereum pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Ethereum pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'ethereum' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Ethereum, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'ethereum' group by dex_pair_id order by trading_volume desc limit 20 ``` # Ethereum Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/index Everything the catalog holds for Ethereum, from raw blocks to project activity. Every layer of the catalog is queryable for Ethereum, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `ethereum` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Ethereum rows are selected with `chain_id = 'ethereum'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Ethereum. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/ethereum/raw) 2015-07 Blocks, transactions, logs and internal calls, plus two tables unique to Ethereum.
[Projects](/docs/catalog/chain-verticals/evm/ethereum/projects) 2015-08 Daily Fees and Revenue for each tracked project, broken out to Ethereum.
[Apps](/docs/catalog/chain-verticals/evm/ethereum/apps) 2020-05 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Ethereum.
[Assets](/docs/catalog/chain-verticals/evm/ethereum/assets) 2017-11 Every curated asset issued on Ethereum, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/ethereum/tokens) 2015-10 Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/ethereum/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/ethereum/contracts) 2015-08 Every contract deployed on Ethereum, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/ethereum/stablecoins) 2017-11 Every stablecoin issued on Ethereum: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/ethereum/real-world-assets) 2018-09 Tokenized stocks, funds and commodities issued on Ethereum, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/ethereum/dex) 2020-05 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/ethereum/lending) **In progress** The lending markets deployed on Ethereum, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/ethereum/bridges) 2022-09 Cross-chain transfers that left Ethereum or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `ethereum` wherever a catalog table has a chain column, so the same filter selects Ethereum everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, token_address, from_address, to_address from `facts_tokens.transfers` where chain_id = 'ethereum' and block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/lending The lending markets deployed on Ethereum and the asset each one lends. A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Ethereum markets with `chain_id = 'ethereum'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Ethereum markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'ethereum' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Ethereum.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'ethereum' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/projects Daily Fees and Revenue for each tracked project, broken out to Ethereum. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Ethereum sit on [Apps](/docs/catalog/chain-verticals/evm/ethereum/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Ethereum fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'ethereum' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Ethereum's share** **Work out how much of a project runs on Ethereum.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/raw The standardized Ethereum blocks, transactions, logs and internal calls. The `ethereum` dataset holds the standardized Ethereum tables. The four core tables follow the shared EVM layout, and Ethereum adds tables of its own. `beacon_validators` covers the consensus side of the chain. Ethereum runs two chains in step: the execution chain that holds transactions, and the beacon chain that agrees on them. One row is one validator at one slot, with its balance and status at that moment. `uncle_blocks` holds a closed chapter. Before the 2022 switch away from mining, a block produced slightly too late became an uncle, referenced by a later canonical block and rewarded in part. The table stops at 2022-09-15 because Ethereum stopped producing them. `block_rewards` records what mining paid. Each proof-of-work block paid its miner a fixed subsidy plus a bonus for every uncle it referenced, and paid each uncle's miner a share that shrank with the uncle's age. Those payments never appear as calls. Balances built from `traces` alone leave them out. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2015-07 One row per block, with its gas and fee totals.
`transactions` 2015-08 One row per transaction, with its receipt fields on the same row.
`logs` 2015-08 One row per event log a contract emitted.
`traces` 2015-08 One row per internal call recorded during execution.
`beacon_validators` 2020-12 Beacon chain validator balances and statuses, snapshotted per slot.
`uncle_blocks` 2015-07 to 2022-09 Headers of the uncle blocks that canonical blocks reference.
`block_rewards` **In progress** One row per mining reward paid to a block or uncle miner, in wei.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. > > `blocks` also has a 1970-01-01 partition holding rows whose source timestamp is zero; bound the column and it never appears. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `ethereum.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **Daily ETH burn** **Work out how much ETH the network burned each day.** Ethereum destroys the base fee of every block rather than paying it to the block producer, so the burn is the base fee per gas unit multiplied by the gas the block used. `blocks` splits on `timestamp`, not `block_timestamp`. ```sql theme={null} select timestamp_trunc(timestamp, day) as day, count(*) as blocks, sum(gas_used) as gas_used, sum(cast(base_fee_per_gas as bignumeric) * gas_used) / 1e18 as eth_burned from `ethereum.blocks` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdt_logs, count(distinct transaction_hash) as transactions from `ethereum.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xdac17f958d2ee523a2206206994597c13d831ec7' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/real-world-assets Tokenized stocks, funds and commodities issued on Ethereum, tracked against their underlying instruments. Ethereum real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/ethereum/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Ethereum deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Ethereum by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'ethereum' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Ethereum tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'ethereum' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/stablecoins Every stablecoin issued on Ethereum: supply, holders and transfers. Ethereum stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/ethereum/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Individual transfers sit on [Tokens](/docs/catalog/chain-verticals/evm/ethereum/tokens). Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Ethereum by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'ethereum' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Ethereum.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ethereum/tokens Ethereum token transfers, holder balances and daily prices. Four surfaces cover token activity on Ethereum. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/ethereum/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'ethereum' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Ethereum tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'ethereum' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'ethereum' and movements.token_address = '0xdac17f958d2ee523a2206206994597c13d831ec7' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Ethereum token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'ethereum', '0xdac17f958d2ee523a2206206994597c13d831ec7', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'ethereum', '0xdac17f958d2ee523a2206206994597c13d831ec7', 'erc20' ) where account_address = '0x28c6c06298d514db089934071355e5743bf21d60' order by balance_date desc limit 20 ``` **Daily price** **Read one Ethereum token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Flow EVM that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Flow EVM table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Flow EVM.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'flowevm' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Flow EVM.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'flowevm' and project_id = 'more' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Flow EVM.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'flowevm' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/assets Every curated asset issued on Flow EVM, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Flow EVM holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). [Stablecoins](/docs/catalog/chain-verticals/evm/flowevm/stablecoins) scopes this layer further. ## Sample queries **Largest assets** **Rank the assets on Flow EVM by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'flowevm' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Flow EVM deployments by asset kind, and how many were issued on Flow EVM itself.** A deployment is native when the issuer minted the token on Flow EVM, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'flowevm' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Flow EVM deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdt-0x674843c06ff83502ddb4d37c2e09c01cda38cbc8-flowevm' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdt-0x674843c06ff83502ddb4d37c2e09c01cda38cbc8-flowevm' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/bridges Cross-chain transfers that left Flow EVM or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'flowevm'` for transfers leaving Flow EVM, `destination_chain_id = 'flowevm'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Flow EVM with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'flowevm', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'flowevm', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'flowevm' or destination_chain_id = 'flowevm') group by day order by day ``` **Where value went** **Find where the value leaving Flow EVM went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'flowevm' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Flow EVM value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'flowevm') as leaving, countif(transfers.destination_chain_id = 'flowevm') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'flowevm' or transfers.destination_chain_id = 'flowevm') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/contracts Every contract deployed on Flow EVM, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Flow EVM, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Flow EVM contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'flowevm' and contract_address = '0x0000000000000000000000021f22333e09a1939d' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'flowevm' and creator_address = '0x0000000000000000000000020000000000000000' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Flow EVM.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'flowevm' and contracts.first_deployed_at >= timestamp('2024-09-01') order by contracts.first_deployed_at desc limit 100 ``` # Flow EVM Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/index Everything the catalog holds for Flow EVM, from raw blocks to project activity. Most of the catalog is queryable for Flow EVM, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `flowevm` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Flow EVM rows are selected with `chain_id = 'flowevm'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Flow EVM. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/flowevm/raw) 2024-09 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/flowevm/projects) 2024-09 Daily Fees and Revenue for each tracked project, broken out to Flow EVM.
[Assets](/docs/catalog/chain-verticals/evm/flowevm/assets) 2024-09 Every curated asset issued on Flow EVM, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/flowevm/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/flowevm/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/flowevm/contracts) 2024-09 Every contract deployed on Flow EVM, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/flowevm/stablecoins) 2024-09 Every stablecoin issued on Flow EVM: supply, holders and transfers.
[Bridges](/docs/catalog/chain-verticals/evm/flowevm/bridges) 2025-01 Cross-chain transfers that left Flow EVM or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `flowevm` wherever a catalog table has a chain column, so the same filter selects Flow EVM everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'flowevm' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/projects Daily Fees and Revenue for each tracked project, broken out to Flow EVM. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Flow EVM fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'flowevm' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Flow EVM's share** **Work out how much of a project runs on Flow EVM.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/raw The standardized Flow EVM blocks, transactions, logs and internal calls. The `flowevm` dataset holds the standardized Flow EVM tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-09 One row per block, with its gas and fee totals.
`transactions` 2024-09 One row per transaction, with its receipt fields on the same row.
`logs` 2024-09 One row per event log a contract emitted.
`traces` 2024-09 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `flowevm.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `flowevm.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x674843c06ff83502ddb4d37c2e09c01cda38cbc8' ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/stablecoins Every stablecoin issued on Flow EVM: supply, holders and transfers. Flow EVM stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/flowevm/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Flow EVM by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'flowevm' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Flow EVM.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdt-0x674843c06ff83502ddb4d37c2e09c01cda38cbc8-flowevm' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdt-0x674843c06ff83502ddb4d37c2e09c01cda38cbc8-flowevm' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/flowevm/tokens Flow EVM token transfers, holder balances and daily prices. Four surfaces cover token activity on Flow EVM. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/flowevm/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'flowevm' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Flow EVM tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'flowevm' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'flowevm' and movements.token_address = '0x99af3eea856556646c98c8b9b2548fe815240750' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Flow EVM token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'flowevm', '0x99af3eea856556646c98c8b9b2548fe815240750', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'flowevm', '0x99af3eea856556646c98c8b9b2548fe815240750', 'erc20' ) where account_address = '0xb7b6b3ffbf157cd5e2ef622cfc12fda065be0e6a' order by balance_date desc limit 20 ``` **Daily price** **Read one Flow EVM token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x99af3eea856556646c98c8b9b2548fe815240750-flowevm' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/fraxtal/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Fraxtal that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Fraxtal table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Fraxtal.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'fraxtal' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Fraxtal.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'fraxtal' and project_id = 'frax' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Fraxtal.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'fraxtal' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/fraxtal/assets Every curated asset issued on Fraxtal, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Fraxtal holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/fraxtal/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/fraxtal/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Fraxtal by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'fraxtal' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Fraxtal deployments by asset kind, and how many were issued on Fraxtal itself.** A deployment is native when the issuer minted the token on Fraxtal, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'fraxtal' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Fraxtal deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'dtrinitydusd-0x788d96f655735f52c676a133f4dfc53cec614d4a-fraxtal' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'dtrinitydusd-0x788d96f655735f52c676a133f4dfc53cec614d4a-fraxtal' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/fraxtal/contracts Every contract deployed on Fraxtal, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Fraxtal, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Fraxtal contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'fraxtal' and contract_address = '0x99b8e50ca5c266a23773c90ddaf054098a0d4316' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'fraxtal' and creator_address = '0x642635ce9ed5d50d9d94d07c406e92142e71d6cb' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Fraxtal.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'fraxtal' and contracts.first_deployed_at >= timestamp('2024-02-01') order by contracts.first_deployed_at desc limit 100 ``` # Fraxtal Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/fraxtal/index Everything the catalog holds for Fraxtal, from raw blocks to project activity. Most of the catalog is queryable for Fraxtal, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `fraxtal` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Fraxtal rows are selected with `chain_id = 'fraxtal'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Fraxtal. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/fraxtal/raw) 2024-02 Blocks, transactions, logs and internal calls.
[Assets](/docs/catalog/chain-verticals/evm/fraxtal/assets) 2024-02 Every curated asset issued on Fraxtal, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/fraxtal/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/fraxtal/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/fraxtal/contracts) 2024-02 Every contract deployed on Fraxtal, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/fraxtal/stablecoins) 2024-02 Every stablecoin issued on Fraxtal: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/fraxtal/real-world-assets) 2024-02 Tokenized stocks, funds and commodities issued on Fraxtal, tracked against their underlying instruments.
## Filtering `chain_id` reads `fraxtal` wherever a catalog table has a chain column, so the same filter selects Fraxtal everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'fraxtal' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/fraxtal/raw The standardized Fraxtal blocks, transactions, logs and internal calls. The `fraxtal` dataset holds the standardized Fraxtal tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-02 One row per block, with its gas and fee totals.
`transactions` 2024-02 One row per transaction, with its receipt fields on the same row.
`logs` 2024-02 One row per event log a contract emitted.
`traces` 2024-02 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `fraxtal.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `fraxtal.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x788d96f655735f52c676a133f4dfc53cec614d4a' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/fraxtal/real-world-assets Tokenized stocks, funds and commodities issued on Fraxtal, tracked against their underlying instruments. Fraxtal real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/fraxtal/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Fraxtal deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Fraxtal by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'fraxtal' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Fraxtal tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'fraxtal' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/fraxtal/stablecoins Every stablecoin issued on Fraxtal: supply, holders and transfers. Fraxtal stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/fraxtal/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Fraxtal by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'fraxtal' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Fraxtal.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'dtrinitydusd-0x788d96f655735f52c676a133f4dfc53cec614d4a-fraxtal' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'dtrinitydusd-0x788d96f655735f52c676a133f4dfc53cec614d4a-fraxtal' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/fraxtal/tokens Fraxtal token transfers, holder balances and daily prices. Four surfaces cover token activity on Fraxtal. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/fraxtal/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'fraxtal' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Fraxtal tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'fraxtal' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'fraxtal' and movements.token_address = '0x788d96f655735f52c676a133f4dfc53cec614d4a' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Fraxtal token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'fraxtal', '0x788d96f655735f52c676a133f4dfc53cec614d4a', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'fraxtal', '0x788d96f655735f52c676a133f4dfc53cec614d4a', 'erc20' ) where account_address = '0x5ecfa6940a33a2dad5c473896452f018c6c04577' order by balance_date desc limit 20 ``` **Daily price** **Read one Fraxtal token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x788d96f655735f52c676a133f4dfc53cec614d4a-fraxtal' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/galactica/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Galactica table resolves to a name. # Galactica Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/galactica/index Everything the catalog holds for Galactica, from raw blocks to project activity. The chain's own record is queryable for Galactica, with its eligible catalog layers above it. The chain's own record sits in the `galactica` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Galactica rows are selected with `chain_id = 'galactica'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Galactica. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/galactica/raw) 2025-06 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/galactica/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/galactica/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `galactica` wherever a catalog table has a chain column, so the same filter selects Galactica everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `galactica.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/galactica/raw The standardized Galactica blocks, transactions, logs and internal calls. The `galactica` dataset holds the standardized Galactica tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-06 One row per block, with its gas and fee totals.
`transactions` 2025-06 One row per transaction, with its receipt fields on the same row.
`logs` 2025-06 One row per event log a contract emitted.
`traces` 2025-06 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `galactica.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `galactica.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/galactica/tokens Galactica token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Gnosis that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Gnosis table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Gnosis.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'gnosis' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Gnosis.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'gnosis' and project_id = 'safe' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Gnosis.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'gnosis' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/assets Every curated asset issued on Gnosis, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Gnosis holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/gnosis/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/gnosis/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Gnosis by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'gnosis' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Gnosis deployments by asset kind, and how many were issued on Gnosis itself.** A deployment is native when the issuer minted the token on Gnosis, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'gnosis' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Gnosis deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'agnoeure-0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2-gnosis' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'agnoeure-0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2-gnosis' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/bridges Cross-chain transfers that left Gnosis or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'gnosis'` for transfers leaving Gnosis, `destination_chain_id = 'gnosis'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Gnosis with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'gnosis', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'gnosis', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'gnosis' or destination_chain_id = 'gnosis') group by day order by day ``` **Where value went** **Find where the value leaving Gnosis went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'gnosis' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Gnosis value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'gnosis') as leaving, countif(transfers.destination_chain_id = 'gnosis') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'gnosis' or transfers.destination_chain_id = 'gnosis') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/contracts Every contract deployed on Gnosis, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Gnosis, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Gnosis contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'gnosis' and contract_address = '0xde1944e610a72c39449c1a184383b421218835a3' ``` **A factory's output** **List the contracts one factory created.** The Swarm swap factory calls `CREATE` for every swap contract it deploys, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'gnosis' and creator_address = '0xc2d5a532cf69aa9a1378737d8ccdef884b6e7420' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Gnosis.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'gnosis' and contracts.first_deployed_at >= timestamp('2018-10-01') order by contracts.first_deployed_at desc limit 100 ``` # Gnosis Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/index Everything the catalog holds for Gnosis, from raw blocks to project activity. Most of the catalog is queryable for Gnosis, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `gnosis` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Gnosis rows are selected with `chain_id = 'gnosis'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Gnosis. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/gnosis/raw) 2018-10 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/gnosis/projects) 2018-10 Daily Fees and Revenue for each tracked project, broken out to Gnosis.
[Assets](/docs/catalog/chain-verticals/evm/gnosis/assets) 2021-02 Every curated asset issued on Gnosis, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/gnosis/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/gnosis/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/gnosis/contracts) 2018-10 Every contract deployed on Gnosis, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/gnosis/stablecoins) 2021-02 Every stablecoin issued on Gnosis: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/gnosis/real-world-assets) 2023-02 Tokenized stocks, funds and commodities issued on Gnosis, tracked against their underlying instruments.
[Lending](/docs/catalog/chain-verticals/evm/gnosis/lending) **In progress** The lending markets deployed on Gnosis, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/gnosis/bridges) 2023-03 Cross-chain transfers that left Gnosis or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `gnosis` wherever a catalog table has a chain column, so the same filter selects Gnosis everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'gnosis' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/lending The lending markets deployed on Gnosis and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Gnosis markets with `chain_id = 'gnosis'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Gnosis markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'gnosis' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Gnosis.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'gnosis' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/projects Daily Fees and Revenue for each tracked project, broken out to Gnosis. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Gnosis fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'gnosis' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Gnosis's share** **Work out how much of a project runs on Gnosis.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/raw The standardized Gnosis blocks, transactions, logs and internal calls. The `gnosis` dataset holds the standardized Gnosis tables. `block_rewards` records xDai minted to bridge deposit recipients. The Gnosis bridge credits a deposit by minting native xDai at the protocol level, without a call. Balances built from `traces` alone leave these mints out. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2018-10 One row per block, with its gas and fee totals.
`transactions` 2018-10 One row per transaction, with its receipt fields on the same row.
`logs` 2018-10 One row per event log a contract emitted.
`traces` 2018-10 One row per internal call recorded during execution.
`block_rewards` **In progress** One row per xDai mint credited to a bridge deposit recipient, in wei.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `gnosis.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `gnosis.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/real-world-assets Tokenized stocks, funds and commodities issued on Gnosis, tracked against their underlying instruments. Gnosis real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/gnosis/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Gnosis deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Gnosis by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'gnosis' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Gnosis tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'gnosis' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/stablecoins Every stablecoin issued on Gnosis: supply, holders and transfers. Gnosis stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/gnosis/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Gnosis by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'gnosis' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Gnosis.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'agnoeure-0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2-gnosis' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'agnoeure-0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2-gnosis' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gnosis/tokens Gnosis token transfers, holder balances and daily prices. Four surfaces cover token activity on Gnosis. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/gnosis/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'gnosis' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Gnosis tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'gnosis' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'gnosis' and movements.token_address = '0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Gnosis token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'gnosis', '0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'gnosis', '0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2', 'erc20' ) where account_address = '0x9008d19f58aabd9ed0d60971565aa8510560ab41' order by balance_date desc limit 20 ``` **Daily price** **Read one Gnosis token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xedbc7449a9b594ca4e053d9737ec5dc4cbccbfb2-gnosis' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gravityalpha/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Gravity Alpha that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Gravity Alpha table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Gravity Alpha.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'gravityalpha' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Gravity Alpha.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'gravityalpha' and project_id = 'layerzero' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Gravity Alpha.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'gravityalpha' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gravityalpha/bridges Cross-chain transfers that left Gravity Alpha or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'gravityalpha'` for transfers leaving Gravity Alpha, `destination_chain_id = 'gravityalpha'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Gravity Alpha with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'gravityalpha', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'gravityalpha', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'gravityalpha' or destination_chain_id = 'gravityalpha') group by day order by day ``` **Where value went** **Find where the value leaving Gravity Alpha went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'gravityalpha' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Gravity Alpha value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'gravityalpha') as leaving, countif(transfers.destination_chain_id = 'gravityalpha') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'gravityalpha' or transfers.destination_chain_id = 'gravityalpha') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gravityalpha/contracts Every contract deployed on Gravity Alpha, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Gravity Alpha, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Gravity Alpha contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'gravityalpha' and contract_address = '0x60320a64f8a6d885c955833bb944f7b510bfde47' ``` **A factory's output** **List the contracts one factory created.** The Galxe loyalty-point factory calls `CREATE` for every point contract it deploys, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'gravityalpha' and creator_address = '0x4f4b657292588fa52aadf700bfeeb8c2398c2c72' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Gravity Alpha.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'gravityalpha' and contracts.first_deployed_at >= timestamp('2024-05-01') order by contracts.first_deployed_at desc limit 100 ``` # Gravity Alpha Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gravityalpha/index Everything the catalog holds for Gravity Alpha, from raw blocks to project activity. The chain's own record is queryable for Gravity Alpha, with its eligible catalog layers above it. The chain's own record sits in the `gravityalpha` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Gravity Alpha rows are selected with `chain_id = 'gravityalpha'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Gravity Alpha. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/gravityalpha/raw) 2024-05 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/gravityalpha/projects) 2024-05 Daily Fees and Revenue for each tracked project, broken out to Gravity Alpha.
[Tokens](/docs/catalog/chain-verticals/evm/gravityalpha/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/gravityalpha/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/gravityalpha/contracts) 2024-05 Every contract deployed on Gravity Alpha, with the account that created it.
[Bridges](/docs/catalog/chain-verticals/evm/gravityalpha/bridges) 2024-07 Cross-chain transfers that left Gravity Alpha or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `gravityalpha` wherever a catalog table has a chain column, so the same filter selects Gravity Alpha everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `gravityalpha.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gravityalpha/projects Daily Fees and Revenue for each tracked project, broken out to Gravity Alpha. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Gravity Alpha fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'gravityalpha' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Gravity Alpha's share** **Work out how much of a project runs on Gravity Alpha.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gravityalpha/raw The standardized Gravity Alpha blocks, transactions, logs and internal calls. The `gravityalpha` dataset holds the standardized Gravity Alpha tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-05 One row per block, with its gas and fee totals.
`transactions` 2024-05 One row per transaction, with its receipt fields on the same row.
`logs` 2024-05 One row per event log a contract emitted.
`traces` 2024-05 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `gravityalpha.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `gravityalpha.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xfbda5f676cb37624f28265a144a48b0d6e87d3b6' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/gravityalpha/tokens Gravity Alpha token transfers, holder balances and daily prices. Four surfaces cover token activity on Gravity Alpha. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/assets/registry) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'gravityalpha' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Gravity Alpha tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'gravityalpha' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'gravityalpha' and movements.token_address = '0xf6f832466cd6c21967e0d954109403f36bc8ceaa' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Gravity Alpha token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'gravityalpha', '0xf6f832466cd6c21967e0d954109403f36bc8ceaa', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'gravityalpha', '0xf6f832466cd6c21967e0d954109403f36bc8ceaa', 'erc20' ) where account_address = '0x0000000000000000000000000000000000000000' order by balance_date desc limit 20 ``` **Daily price** **Read one Gravity Alpha token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xf6f832466cd6c21967e0d954109403f36bc8ceaa-gravityalpha' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hederaevm/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Hedera EVM that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Hedera EVM table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Hedera EVM.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'hederaevm' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Hedera EVM.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'hederaevm' and project_id = 'chainlink' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Hedera EVM.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'hederaevm' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hederaevm/bridges Cross-chain transfers that left Hedera EVM or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'hederaevm'` for transfers leaving Hedera EVM, `destination_chain_id = 'hederaevm'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Hedera EVM with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'hederaevm', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'hederaevm', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'hederaevm' or destination_chain_id = 'hederaevm') group by day order by day ``` **Where value went** **Find where the value leaving Hedera EVM went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'hederaevm' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Hedera EVM value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'hederaevm') as leaving, countif(transfers.destination_chain_id = 'hederaevm') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'hederaevm' or transfers.destination_chain_id = 'hederaevm') group by apps.name order by volume_usd desc ``` # Hedera EVM Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hederaevm/index Everything the catalog holds for Hedera EVM, from raw blocks to project activity. The chain's own record is queryable for Hedera EVM, with its eligible catalog layers above it. The chain's own record sits in the `hederaevm` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Hedera EVM rows are selected with `chain_id = 'hederaevm'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Hedera EVM. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/hederaevm/raw) 2019-09 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/hederaevm/projects) **In progress** Daily Fees and Revenue for each tracked project, broken out to Hedera EVM.
[Tokens](/docs/catalog/chain-verticals/evm/hederaevm/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/hederaevm/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Bridges](/docs/catalog/chain-verticals/evm/hederaevm/bridges) 2026-06 Cross-chain transfers that left Hedera EVM or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `hederaevm` wherever a catalog table has a chain column, so the same filter selects Hedera EVM everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `hederaevm.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hederaevm/projects Daily Fees and Revenue for each tracked project, broken out to Hedera EVM. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Hedera EVM fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'hederaevm' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Hedera EVM's share** **Work out how much of a project runs on Hedera EVM.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hederaevm/raw The standardized Hedera EVM blocks, transactions, logs and internal calls. The `hederaevm` dataset holds the standardized Hedera EVM tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2019-09 One row per block, with its gas and fee totals.
`transactions` 2019-09 One row per transaction, with its receipt fields on the same row.
`logs` 2019-09 One row per event log a contract emitted.
`traces` 2019-09 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `hederaevm.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `hederaevm.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hederaevm/tokens Hedera EVM token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/humanity/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Humanity table resolves to a name. # Humanity Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/humanity/index Everything the catalog holds for Humanity, from raw blocks to project activity. The chain's own record is queryable for Humanity, with its eligible catalog layers above it. The chain's own record sits in the `humanity` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Humanity rows are selected with `chain_id = 'humanity'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Humanity. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/humanity/raw) 2025-06 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/humanity/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/humanity/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `humanity` wherever a catalog table has a chain column, so the same filter selects Humanity everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `humanity.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/humanity/raw The standardized Humanity blocks, transactions, logs and internal calls. The `humanity` dataset holds the standardized Humanity tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-06 One row per block, with its gas and fee totals.
`transactions` 2025-06 One row per transaction, with its receipt fields on the same row.
`logs` 2025-06 One row per event log a contract emitted.
`traces` 2025-06 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `humanity.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `humanity.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/humanity/tokens Humanity token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on HyperEVM that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any HyperEVM table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on HyperEVM.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'hyperevm' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on HyperEVM.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'hyperevm' and project_id = 'xstocks' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on HyperEVM.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'hyperevm' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/assets Every curated asset issued on HyperEVM, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what HyperEVM holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/hyperevm/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/hyperevm/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on HyperEVM by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'hyperevm' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count HyperEVM deployments by asset kind, and how many were issued on HyperEVM itself.** A deployment is native when the issuer minted the token on HyperEVM, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'hyperevm' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one HyperEVM deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xb88339cb7199b77e23db6e890353e22632ba630f-hyperevm' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xb88339cb7199b77e23db6e890353e22632ba630f-hyperevm' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/bridges Cross-chain transfers that left HyperEVM or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'hyperevm'` for transfers leaving HyperEVM, `destination_chain_id = 'hyperevm'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving HyperEVM with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'hyperevm', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'hyperevm', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'hyperevm' or destination_chain_id = 'hyperevm') group by day order by day ``` **Where value went** **Find where the value leaving HyperEVM went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'hyperevm' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the HyperEVM value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'hyperevm') as leaving, countif(transfers.destination_chain_id = 'hyperevm') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'hyperevm' or transfers.destination_chain_id = 'hyperevm') group by apps.name order by volume_usd desc ``` # HyperEVM Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/index Everything the catalog holds for HyperEVM, from raw blocks to project activity. Most of the catalog is queryable for HyperEVM, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `hyperevm` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the HyperEVM rows are selected with `chain_id = 'hyperevm'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on HyperEVM. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/hyperevm/raw) 2025-02 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/hyperevm/projects) 2025-02 Daily Fees and Revenue for each tracked project, broken out to HyperEVM.
[Assets](/docs/catalog/chain-verticals/evm/hyperevm/assets) 2024-01 Every curated asset issued on HyperEVM, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/hyperevm/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/hyperevm/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Stablecoins](/docs/catalog/chain-verticals/evm/hyperevm/stablecoins) 2025-03 Every stablecoin issued on HyperEVM: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/hyperevm/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on HyperEVM, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/hyperevm/bridges) 2025-03 Cross-chain transfers that left HyperEVM or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `hyperevm` wherever a catalog table has a chain column, so the same filter selects HyperEVM everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'hyperevm' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/projects Daily Fees and Revenue for each tracked project, broken out to HyperEVM. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily HyperEVM fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'hyperevm' and daily.project_id = 'uniswap' order by daily.timestamp ``` **HyperEVM's share** **Work out how much of a project runs on HyperEVM.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/raw The standardized HyperEVM blocks, transactions, logs and internal calls. The `hyperevm` dataset holds the standardized HyperEVM tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-02 One row per block, with its gas and fee totals.
`transactions` 2025-02 One row per transaction, with its receipt fields on the same row.
`logs` 2025-02 One row per event log a contract emitted.
`traces` 2025-02 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `hyperevm.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `hyperevm.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xb88339cb7199b77e23db6e890353e22632ba630f' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/real-world-assets Tokenized stocks, funds and commodities issued on HyperEVM, tracked against their underlying instruments. HyperEVM real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/hyperevm/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its HyperEVM deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on HyperEVM by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'hyperevm' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List HyperEVM tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'hyperevm' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/stablecoins Every stablecoin issued on HyperEVM: supply, holders and transfers. HyperEVM stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/hyperevm/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on HyperEVM by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'hyperevm' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on HyperEVM.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xb88339cb7199b77e23db6e890353e22632ba630f-hyperevm' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xb88339cb7199b77e23db6e890353e22632ba630f-hyperevm' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/hyperevm/tokens HyperEVM token transfers, holder balances and daily prices. Four surfaces cover token activity on HyperEVM. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/hyperevm/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'hyperevm' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest HyperEVM tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'hyperevm' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'hyperevm' and movements.token_address = '0xb88339cb7199b77e23db6e890353e22632ba630f' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one HyperEVM token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'hyperevm', '0xb88339cb7199b77e23db6e890353e22632ba630f', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'hyperevm', '0xb88339cb7199b77e23db6e890353e22632ba630f', 'erc20' ) where account_address = '0x6b9e773128f453f5c2c60935ee2de2cbc5390a24' order by balance_date desc limit 20 ``` **Daily price** **Read one HyperEVM token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xb88339cb7199b77e23db6e890353e22632ba630f-hyperevm' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/immutablezkevm/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Immutable zkEVM that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Immutable zkEVM table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Immutable zkEVM.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'immutablezkevm' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Immutable zkEVM.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'immutablezkevm' and project_id = 'overtake' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Immutable zkEVM.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'immutablezkevm' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/immutablezkevm/contracts Every contract deployed on Immutable zkEVM, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Immutable zkEVM, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Immutable zkEVM contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'immutablezkevm' and contract_address = '0x0c0abcce000ea765921d6b1415011282a146e50f' ``` **A factory's output** **List the contracts one factory created.** The Immutable factory calls `CREATE` for every contract it deploys, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'immutablezkevm' and creator_address = '0x8fa5088df65855e0daf87fa6591659893b24871d' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Immutable zkEVM.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'immutablezkevm' and contracts.first_deployed_at >= timestamp('2023-12-01') order by contracts.first_deployed_at desc limit 100 ``` # Immutable zkEVM Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/immutablezkevm/index Everything the catalog holds for Immutable zkEVM, from raw blocks to project activity. The chain's own record is queryable for Immutable zkEVM, with its eligible catalog layers above it. The chain's own record sits in the `immutablezkevm` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Immutable zkEVM rows are selected with `chain_id = 'immutablezkevm'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Immutable zkEVM. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/immutablezkevm/raw) 2023-12 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/immutablezkevm/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/immutablezkevm/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/immutablezkevm/contracts) 2023-12 Every contract deployed on Immutable zkEVM, with the account that created it.
## Filtering `chain_id` reads `immutablezkevm` wherever a catalog table has a chain column, so the same filter selects Immutable zkEVM everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `immutablezkevm.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/immutablezkevm/raw The standardized Immutable zkEVM blocks, transactions, logs and internal calls. The `immutablezkevm` dataset holds the standardized Immutable zkEVM tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2023-12 One row per block, with its gas and fee totals.
`transactions` 2023-12 One row per transaction, with its receipt fields on the same row.
`logs` 2023-12 One row per event log a contract emitted.
`traces` 2023-12 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `immutablezkevm.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `immutablezkevm.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x00000000efe302beaa2b3e6e1b18d08d69a9012a' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/immutablezkevm/tokens Immutable zkEVM token transfers, holder balances and daily prices. Four surfaces cover token activity on Immutable zkEVM. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/assets/registry) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'immutablezkevm' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Immutable zkEVM tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'immutablezkevm' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'immutablezkevm' and movements.token_address = '0x00000000efe302beaa2b3e6e1b18d08d69a9012a' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Immutable zkEVM token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'immutablezkevm', '0x00000000efe302beaa2b3e6e1b18d08d69a9012a', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'immutablezkevm', '0x00000000efe302beaa2b3e6e1b18d08d69a9012a', 'erc20' ) where account_address = '0x42514fa59dd4689573d35119cf9e0bda218e15ee' order by balance_date desc limit 20 ``` **Daily price** **Read one Immutable zkEVM token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x00000000efe302beaa2b3e6e1b18d08d69a9012a-immutablezkevm' order by prices.timestamp ``` # EVM ecosystem Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/index Standardized blocks, transactions, logs and traces for every EVM chain. EVM stands for Ethereum Virtual Machine, the engine that runs contracts on Ethereum. Every chain in this family runs that same engine, so they all keep the same kind of records and get the same four core tables: `blocks`, `transactions`, `logs` and `traces`. The [Tables](#tables) section below lists the columns once for the whole family. ## Chains
Chain `chain_id` blocks transactions logs traces
Anime `anime` ✓ ✓ ✓ ✓
ApeChain `apechain` ✓ ✓ ✓ ✓
Arbitrum `arbitrum` ✓ ✓ ✓ ✓
Arc `arc` ✓ ✓ ✓ ✓
Avalanche `avalanche` ✓ ✓ ✓ ✓
Base `base` ✓ ✓ ✓ ✓
Berachain `berachain` ✓ ✓ ✓ ✓
Blast `blast` ✓ ✓ ✓ ✓
BNB Smart Chain `bsc` ✓ ✓ ✓ ✓
BOB `bob` ✓ ✓ ✓ ✓
Boba Network `bobanetwork` ✓ ✓ ✓ ✓
Celo `celo` ✓ ✓ ✓ ✓
Ethereum `ethereum` ✓ ✓ ✓ ✓
Flow EVM `flowevm` ✓ ✓ ✓ ✓
Fraxtal `fraxtal` ✓ ✓ ✓ ✓
Galactica `galactica` ✓ ✓ ✓ ✓
Gnosis `gnosis` ✓ ✓ ✓ ✓
Gravity Alpha `gravityalpha` ✓ ✓ ✓ ✓
Hedera EVM `hederaevm` ✓ ✓ ✓ ✗
Humanity `humanity` ✓ ✓ ✓ ✓
HyperEVM `hyperevm` ✓ ✓ ✓ ✗
Immutable zkEVM `immutablezkevm` ✓ ✓ ✓ ✓
Injective EVM `injectiveevm` ✓ ✓ ✓ ✗
Ink `ink` ✓ ✓ ✓ ✓
IoTeX `iotex` ✓ ✓ ✓ ✗
Katana `katananetwork` ✓ ✓ ✓ ✓
Linea `linea` ✓ ✓ ✓ ✓
Manta `manta` ✓ ✓ ✓ ✓
MegaETH `megaeth` ✓ ✓ ✓ ✗
Metis `metis` ✓ ✓ ✓ ✓
Mode `mode` ✓ ✓ ✓ ✓
Monad `monad` ✓ ✓ ✓ ✓
opBNB `opbnb` ✓ ✓ ✓ ✓
Optimism `optimism` ✓ ✓ ✓ ✓
Plasma `plasma` ✓ ✓ ✓ ✓
Polygon `polygon` ✓ ✓ ✓ ✓
Robinhood Chain `robinhoodchain` ✓ ✓ ✓ ✓
Rootstock `rootstock` ✓ ✓ ✓ ✓
Scroll `scroll` ✓ ✓ ✓ ✓
Sei EVM `seievm` ✓ ✓ ✓ ✓
Settlus `settlus` ✓ ✓ ✓ ✓
Shape `shape` ✓ ✓ ✓ ✓
Soneium `soneium` ✓ ✓ ✓ ✓
Sonic `sonic` ✓ ✓ ✓ ✓
Story `story` ✓ ✓ ✓ ✓
Superseed `superseed` ✓ ✓ ✓ ✓
Tempo `tempo` ✓ ✓ ✓ ✓
Unichain `unichain` ✓ ✓ ✓ ✓
Viction `viction` ✓ ✓ ✓ ✓
World Chain `worldchain` ✓ ✓ ✓ ✓
World Mobile Chain `worldmobilechain` ✓ ✓ ✓ ✓
XDC `xdc` ✓ ✓ ✓ ✗
X Layer `xlayer` ✓ ✓ ✓ ✓
ZKsync Era `zksyncera` ✓ ✓ ✓ ✓
## Tables Every chain in the EVM family runs the Ethereum Virtual Machine, the same engine Ethereum runs, so every one of their datasets has the same four core tables with the same columns. The schemas apply to every chain listed in the [chain matrix](#chains). A receipt is the chain's record of what a transaction cost and whether it worked. Those fields sit on the transaction's own row, named `receipt_*`. > [!WARNING] > > Every table splits by day: `blocks` on `timestamp`, the rest on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. **blocks** A block is a batch of transactions that the network agreed on and added to the chain as one unit. `blocks` contains one row per block, keyed on the block number.
Column Type Description
`timestamp` TIMESTAMP The time the block was produced. Partition column.
`number` INT64 The block number.
`block_hash` STRING The hash of the block.
`transaction_count` INT64 The number of transactions in the block.
`gas_limit` INT64 The maximum gas the block allows.
`gas_used` INT64 The gas consumed by all transactions in the block.
`blob_gas_used` INT64 The blob gas consumed by the block.
`excess_blob_gas` INT64 The running excess of blob gas above the target.
`base_fee_per_gas` INT64 The base fee per gas unit, in wei.
`miner` STRING The address credited with producing the block.
`parent_hash` STRING The hash of the parent block.
`nonce` STRING The proof-of-work nonce.
`sha3_uncles` STRING The hash of the block's uncle list.
`logs_bloom` STRING The bloom filter over the block's logs.
`transactions_root` STRING The root hash of the transaction trie.
`state_root` STRING The root hash of the state trie.
`receipts_root` STRING The root hash of the receipt trie.
`difficulty` INT64 The proof-of-work difficulty.
`total_difficulty` NUMERIC The cumulative difficulty up to this block.
`size` INT64 The block size in bytes.
`extra_data` STRING Arbitrary data included by the block producer.
`parent_beacon_block_root` STRING The root of the parent beacon block.
`mix_hash` STRING The mix hash from block sealing.
`uncles` ARRAY\ The hashes of the block's uncles.
`withdrawals` ARRAY\ Validator withdrawals credited in the block: address, amount, index and validator index.
`withdrawals_root` STRING The root hash of the withdrawal list.
**Daily blocks and gas** **Count blocks and gas used per day.** `blocks` splits on `timestamp`, not `block_timestamp`. ```sql theme={null} select timestamp_trunc(timestamp, day) as day, count(*) as blocks, sum(gas_used) as gas_used from `ethereum.blocks` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') group by day order by day ``` **transactions** A transaction is one signed instruction an account sent to the chain: a payment, or a call into a contract. `transactions` contains one row per transaction, with its receipt fields on the same row.
Column Type Description
`block_timestamp` TIMESTAMP The time of the block containing the transaction. Partition column.
`block_number` INT64 The number of the block containing the transaction.
`transaction_hash` STRING The hash of the transaction.
`transaction_index` INT64 The position of the transaction within the block.
`from_address` STRING The sending address.
`to_address` STRING The receiving address. Null for contract creations.
`value` NUMERIC The native value transferred, in wei.
`gas` INT64 The gas limit set by the sender.
`gas_price` INT64 The gas price, in wei.
`nonce` INT64 The sender's transaction count at submission.
`input` STRING The data sent with the transaction, saying which contract function to run and with what arguments.
`block_hash` STRING The hash of the containing block.
`max_fee_per_gas` INT64 The EIP-1559 fee cap per gas unit.
`max_priority_fee_per_gas` INT64 The EIP-1559 priority fee per gas unit.
`transaction_type` INT64 The transaction type identifier.
`receipt_type` INT64 The type identifier recorded on the receipt.
`receipt_effective_gas_price` INT64 The gas price paid, in wei.
`receipt_blob_gas_price` INT64 The blob gas price paid.
`receipt_cumulative_gas_used` INT64 The gas used in the block up to and including this transaction.
`receipt_gas_used` INT64 The gas used by this transaction.
`receipt_blob_gas_used` INT64 The blob gas used by this transaction.
`receipt_contract_address` STRING The address of the contract created, when the transaction deploys one.
`receipt_status` BOOL Whether the transaction succeeded.
`receipt_logs_bloom` STRING The bloom filter over the transaction's logs.
`receipt_transaction_index` INT64 The transaction index recorded on the receipt.
`v` STRING The signature recovery value.
`r` STRING The signature r value.
`s` STRING The signature s value.
`chain_id` INT64 The chain id the transaction was signed for.
`blob_versioned_hashes` ARRAY\ The versioned hashes of attached blobs.
`max_fee_per_blob_gas` INT64 The blob gas fee cap.
`access_list` ARRAY\ The declared access list: address and storage keys.
**Daily success rate** **Count daily transactions and their success rate over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, countif(receipt_status) as successful from `ethereum.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **logs** A log is a note a contract writes when something happens inside it: a transfer, a swap, a deposit. Each contract decides what it announces this way, so logs are the main record of what apps did. `logs` contains one row per log.
Column Type Description
`block_timestamp` TIMESTAMP The time of the block containing the log. Partition column.
`block_number` INT64 The number of the block containing the log.
`transaction_hash` STRING The hash of the transaction that emitted the log.
`log_index` INT64 The position of the log within the block.
`address` STRING The contract that emitted the log.
`data` STRING The rest of the log's contents, the part that is not searchable.
`topics` ARRAY\ The searchable fields of the log. The first one identifies which event this is.
`removed` BOOL Whether the log was removed by a reorganization.
`block_hash` STRING The hash of the containing block.
`transaction_index` INT64 The position of the emitting transaction within the block.
**One contract's logs** **Count the logs one contract emitted on a single day.** `address` is the contract that wrote the log. ```sql theme={null} select count(*) as logs, count(distinct transaction_hash) as transactions from `ethereum.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xdac17f958d2ee523a2206206994597c13d831ec7' ``` **traces** A trace is a record of one internal step a transaction took, including the calls a contract makes to other contracts. A single transaction usually produces many of them. `traces` contains one row per step: a call, a contract creation, a contract self-destruct, or a reward.
Column Type Description
`from_address` STRING The calling address.
`gas` INT64 The gas available to the call.
`gas_used` INT64 The gas used by the call.
`to_address` STRING The called address.
`input` STRING The call data.
`value` FLOAT64 The native value transferred by the call, in wei.
`trace_type` STRING The trace type: call, create, suicide or reward.
`transaction_hash` STRING The hash of the containing transaction.
`block_timestamp` TIMESTAMP The time of the block containing the trace. Partition column.
`block_number` INT64 The number of the containing block.
`trace_address` STRING The position of the call in the call tree.
`output` STRING The return data of the call.
`error` STRING The error raised by the call, when it failed.
`revert_reason` STRING The revert reason string, when one was returned.
`transaction_index` INT64 The position of the containing transaction within the block.
`trace_id` STRING The unique identifier of the trace.
`status` BOOL Whether the call succeeded.
The chains marked ✓ for `traces` in the [chain matrix](#chains) have this table. **Calls into one contract** **Count the internal calls into one contract on a single day.** `to_address` is the contract being called, whether directly or from another contract. ```sql theme={null} select count(*) as calls, count(distinct transaction_hash) as transactions from `ethereum.traces` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and to_address = '0xdac17f958d2ee523a2206206994597c13d831ec7' ``` ## Exceptions * Ethereum adds two tables to the four, `beacon_validators` and `uncle_blocks`, documented on its [Raw](/docs/catalog/chain-verticals/evm/ethereum/raw) page. * HyperEVM publishes its receipt fields as a separate `receipts` table; every other chain keeps them on the transaction row. # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/injectiveevm/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Injective EVM that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Injective EVM table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Injective EVM.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'injectiveevm' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Injective EVM.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'injectiveevm' and project_id = 'yeifinance' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Injective EVM.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'injectiveevm' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/injectiveevm/assets Every curated asset issued on Injective EVM, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Injective EVM holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). [Stablecoins](/docs/catalog/chain-verticals/evm/injectiveevm/stablecoins) scopes this layer further. ## Sample queries **Largest assets** **Rank the assets on Injective EVM by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'injectiveevm' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Injective EVM deployments by asset kind, and how many were issued on Injective EVM itself.** A deployment is native when the issuer minted the token on Injective EVM, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'injectiveevm' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Injective EVM deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xa00c59ff5a080d2b954d0c75e46e22a0c371235a-injectiveevm' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xa00c59ff5a080d2b954d0c75e46e22a0c371235a-injectiveevm' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/injectiveevm/bridges Cross-chain transfers that left Injective EVM or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'injectiveevm'` for transfers leaving Injective EVM, `destination_chain_id = 'injectiveevm'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Injective EVM with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'injectiveevm', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'injectiveevm', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'injectiveevm' or destination_chain_id = 'injectiveevm') group by day order by day ``` **Where value went** **Find where the value leaving Injective EVM went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'injectiveevm' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Injective EVM value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'injectiveevm') as leaving, countif(transfers.destination_chain_id = 'injectiveevm') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'injectiveevm' or transfers.destination_chain_id = 'injectiveevm') group by apps.name order by volume_usd desc ``` # Injective EVM Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/injectiveevm/index Everything the catalog holds for Injective EVM, from raw blocks to project activity. Most of the catalog is queryable for Injective EVM, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `injectiveevm` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Injective EVM rows are selected with `chain_id = 'injectiveevm'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Injective EVM. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/injectiveevm/raw) 2025-11 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/injectiveevm/projects) 2025-11 Daily Fees and Revenue for each tracked project, broken out to Injective EVM.
[Assets](/docs/catalog/chain-verticals/evm/injectiveevm/assets) 2025-11 Every curated asset issued on Injective EVM, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/injectiveevm/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/injectiveevm/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Stablecoins](/docs/catalog/chain-verticals/evm/injectiveevm/stablecoins) 2026-03 Every stablecoin issued on Injective EVM: supply, holders and transfers.
[Bridges](/docs/catalog/chain-verticals/evm/injectiveevm/bridges) 2026-04 Cross-chain transfers that left Injective EVM or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `injectiveevm` wherever a catalog table has a chain column, so the same filter selects Injective EVM everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'injectiveevm' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/injectiveevm/projects Daily Fees and Revenue for each tracked project, broken out to Injective EVM. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Injective EVM fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'injectiveevm' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Injective EVM's share** **Work out how much of a project runs on Injective EVM.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/injectiveevm/raw The standardized Injective EVM blocks, transactions, logs and internal calls. The `injectiveevm` dataset holds the standardized Injective EVM tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-11 One row per block, with its gas and fee totals.
`transactions` 2025-11 One row per transaction, with its receipt fields on the same row.
`logs` 2025-11 One row per event log a contract emitted.
`traces` 2025-11 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `injectiveevm.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `injectiveevm.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xa00c59ff5a080d2b954d0c75e46e22a0c371235a' ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/injectiveevm/stablecoins Every stablecoin issued on Injective EVM: supply, holders and transfers. Injective EVM stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/injectiveevm/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Injective EVM by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'injectiveevm' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Injective EVM.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xa00c59ff5a080d2b954d0c75e46e22a0c371235a-injectiveevm' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xa00c59ff5a080d2b954d0c75e46e22a0c371235a-injectiveevm' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/injectiveevm/tokens Injective EVM token transfers, holder balances and daily prices. Four surfaces cover token activity on Injective EVM. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/injectiveevm/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'injectiveevm' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Injective EVM tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'injectiveevm' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'injectiveevm' and movements.token_address = '0xa00c59ff5a080d2b954d0c75e46e22a0c371235a' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Injective EVM token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'injectiveevm', '0xa00c59ff5a080d2b954d0c75e46e22a0c371235a', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'injectiveevm', '0xa00c59ff5a080d2b954d0c75e46e22a0c371235a', 'erc20' ) where account_address = '0x8367cc5b351183f486e007dfea712b909eddcc12' order by balance_date desc limit 20 ``` **Daily price** **Read one Injective EVM token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xa00c59ff5a080d2b954d0c75e46e22a0c371235a-injectiveevm' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Ink that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Ink table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Ink.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'ink' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Ink.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'ink' and project_id = 'xstocks' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Ink.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'ink' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/assets Every curated asset issued on Ink, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Ink holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/ink/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/ink/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Ink by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'ink' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Ink deployments by asset kind, and how many were issued on Ink itself.** A deployment is native when the issuer minted the token on Ink, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'ink' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Ink deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x2d270e6886d130d724215a266106e6832161eaed-ink' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x2d270e6886d130d724215a266106e6832161eaed-ink' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/bridges Cross-chain transfers that left Ink or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'ink'` for transfers leaving Ink, `destination_chain_id = 'ink'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Ink with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'ink', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'ink', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'ink' or destination_chain_id = 'ink') group by day order by day ``` **Where value went** **Find where the value leaving Ink went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'ink' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Ink value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'ink') as leaving, countif(transfers.destination_chain_id = 'ink') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'ink' or transfers.destination_chain_id = 'ink') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/contracts Every contract deployed on Ink, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Ink, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Ink contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'ink' and contract_address = '0xfe73af51f4832d0b6fa168fc0a45dbe4e024c5ae' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'ink' and creator_address = '0xbaf05914e32153f58603d2de176d51e88186aadb' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Ink.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'ink' and contracts.first_deployed_at >= timestamp('2024-12-01') order by contracts.first_deployed_at desc limit 100 ``` # Ink Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/index Everything the catalog holds for Ink, from raw blocks to project activity. Most of the catalog is queryable for Ink, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `ink` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Ink rows are selected with `chain_id = 'ink'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Ink. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/ink/raw) 2024-12 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/ink/projects) 2024-12 Daily Fees and Revenue for each tracked project, broken out to Ink.
[Assets](/docs/catalog/chain-verticals/evm/ink/assets) 2024-12 Every curated asset issued on Ink, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/ink/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/ink/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/ink/contracts) 2024-12 Every contract deployed on Ink, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/ink/stablecoins) 2024-12 Every stablecoin issued on Ink: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/ink/real-world-assets) 2025-03 Tokenized stocks, funds and commodities issued on Ink, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/ink/bridges) 2024-12 Cross-chain transfers that left Ink or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `ink` wherever a catalog table has a chain column, so the same filter selects Ink everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'ink' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/projects Daily Fees and Revenue for each tracked project, broken out to Ink. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Ink fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'ink' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Ink's share** **Work out how much of a project runs on Ink.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/raw The standardized Ink blocks, transactions, logs and internal calls. The `ink` dataset holds the standardized Ink tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-12 One row per block, with its gas and fee totals.
`transactions` 2024-12 One row per transaction, with its receipt fields on the same row.
`logs` 2024-12 One row per event log a contract emitted.
`traces` 2024-12 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `ink.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `ink.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x2d270e6886d130d724215a266106e6832161eaed' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/real-world-assets Tokenized stocks, funds and commodities issued on Ink, tracked against their underlying instruments. Ink real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/ink/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Ink deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Ink by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'ink' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Ink tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'ink' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/stablecoins Every stablecoin issued on Ink: supply, holders and transfers. Ink stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/ink/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Ink by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'ink' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Ink.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x2d270e6886d130d724215a266106e6832161eaed-ink' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x2d270e6886d130d724215a266106e6832161eaed-ink' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/ink/tokens Ink token transfers, holder balances and daily prices. Four surfaces cover token activity on Ink. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/ink/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'ink' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Ink tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'ink' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'ink' and movements.token_address = '0x2d270e6886d130d724215a266106e6832161eaed' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Ink token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'ink', '0x2d270e6886d130d724215a266106e6832161eaed', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'ink', '0x2d270e6886d130d724215a266106e6832161eaed', 'erc20' ) where account_address = '0xf2427f0f8437bc2a00f0ff8db71305918534e00b' order by balance_date desc limit 20 ``` **Daily price** **Read one Ink token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x2d270e6886d130d724215a266106e6832161eaed-ink' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/iotex/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on IoTeX that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any IoTeX table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on IoTeX.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'iotex' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on IoTeX.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'iotex' and project_id = 'magmafinance' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on IoTeX.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'iotex' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/iotex/assets Every curated asset issued on IoTeX, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what IoTeX holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). [Real-world assets](/docs/catalog/chain-verticals/evm/iotex/real-world-assets) scopes this layer further. ## Sample queries **Largest assets** **Rank the assets on IoTeX by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'iotex' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count IoTeX deployments by asset kind, and how many were issued on IoTeX itself.** A deployment is native when the issuer minted the token on IoTeX, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'iotex' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one IoTeX deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'daimatic-0x62a9d987cbf4c45a550deed5b57b200d7a319632-iotex' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'daimatic-0x62a9d987cbf4c45a550deed5b57b200d7a319632-iotex' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # IoTeX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/iotex/index Everything the catalog holds for IoTeX, from raw blocks to project activity. Most of the catalog is queryable for IoTeX, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `iotex` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the IoTeX rows are selected with `chain_id = 'iotex'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on IoTeX. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/iotex/raw) 2019-03 Blocks, transactions, logs and internal calls.
[Assets](/docs/catalog/chain-verticals/evm/iotex/assets) 2021-06 Every curated asset issued on IoTeX, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/iotex/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/iotex/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Real-world assets](/docs/catalog/chain-verticals/evm/iotex/real-world-assets) 2021-06 Tokenized stocks, funds and commodities issued on IoTeX, tracked against their underlying instruments.
## Filtering `chain_id` reads `iotex` wherever a catalog table has a chain column, so the same filter selects IoTeX everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'iotex' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/iotex/raw The standardized IoTeX blocks, transactions, logs and internal calls. The `iotex` dataset holds the standardized IoTeX tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2019-03 One row per block, with its gas and fee totals.
`transactions` 2019-03 One row per transaction, with its receipt fields on the same row.
`logs` 2019-03 One row per event log a contract emitted.
`traces` 2019-03 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `iotex.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `iotex.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x62a9d987cbf4c45a550deed5b57b200d7a319632' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/iotex/real-world-assets Tokenized stocks, funds and commodities issued on IoTeX, tracked against their underlying instruments. IoTeX real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/iotex/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its IoTeX deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on IoTeX by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'iotex' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List IoTeX tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'iotex' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/iotex/tokens IoTeX token transfers, holder balances and daily prices. Four surfaces cover token activity on IoTeX. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/iotex/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'iotex' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest IoTeX tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'iotex' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'iotex' and movements.token_address = '0x62a9d987cbf4c45a550deed5b57b200d7a319632' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one IoTeX token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'iotex', '0x62a9d987cbf4c45a550deed5b57b200d7a319632', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'iotex', '0x62a9d987cbf4c45a550deed5b57b200d7a319632', 'erc20' ) where account_address = '0xd40bfd9bffc798b5183cbe27d877562fb09c8958' order by balance_date desc limit 20 ``` **Daily price** **Read one IoTeX token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x62a9d987cbf4c45a550deed5b57b200d7a319632-iotex' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Katana that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Katana table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Katana.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'katananetwork' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Katana.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'katananetwork' and project_id = 'morpho' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Katana.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'katananetwork' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/assets Every curated asset issued on Katana, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Katana holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/katananetwork/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/katananetwork/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Katana by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'katananetwork' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Katana deployments by asset kind, and how many were issued on Katana itself.** A deployment is native when the issuer minted the token on Katana, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'katananetwork' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Katana deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'ausd-0x00000000efe302beaa2b3e6e1b18d08d69a9012a-katananetwork' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'ausd-0x00000000efe302beaa2b3e6e1b18d08d69a9012a-katananetwork' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/bridges Cross-chain transfers that left Katana or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'katananetwork'` for transfers leaving Katana, `destination_chain_id = 'katananetwork'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Katana with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'katananetwork', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'katananetwork', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'katananetwork' or destination_chain_id = 'katananetwork') group by day order by day ``` **Where value went** **Find where the value leaving Katana went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'katananetwork' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Katana value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'katananetwork') as leaving, countif(transfers.destination_chain_id = 'katananetwork') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'katananetwork' or transfers.destination_chain_id = 'katananetwork') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/contracts Every contract deployed on Katana, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Katana, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Katana contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'katananetwork' and contract_address = '0x5c79c1416a6de9f0649b2aebcf2311ecfdd8eca2' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'katananetwork' and creator_address = '0x00000000000018a77519fccca060c2537c9d6d3f' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Katana.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'katananetwork' and contracts.first_deployed_at >= timestamp('2025-05-01') order by contracts.first_deployed_at desc limit 100 ``` # Katana Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/index Everything the catalog holds for Katana, from raw blocks to project activity. Most of the catalog is queryable for Katana, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `katananetwork` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Katana rows are selected with `chain_id = 'katananetwork'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Katana. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/katananetwork/raw) 2025-05 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/katananetwork/projects) 2025-05 Daily Fees and Revenue for each tracked project, broken out to Katana.
[Assets](/docs/catalog/chain-verticals/evm/katananetwork/assets) 2025-01 Every curated asset issued on Katana, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/katananetwork/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/katananetwork/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/katananetwork/contracts) 2025-05 Every contract deployed on Katana, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/katananetwork/stablecoins) 2025-06 Every stablecoin issued on Katana: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/katananetwork/real-world-assets) 2025-01 Tokenized stocks, funds and commodities issued on Katana, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/katananetwork/bridges) 2025-06 Cross-chain transfers that left Katana or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `katananetwork` wherever a catalog table has a chain column, so the same filter selects Katana everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'katananetwork' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/projects Daily Fees and Revenue for each tracked project, broken out to Katana. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Katana fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'katananetwork' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Katana's share** **Work out how much of a project runs on Katana.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/raw The standardized Katana blocks, transactions, logs and internal calls. The `katananetwork` dataset holds the standardized Katana tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-05 One row per block, with its gas and fee totals.
`transactions` 2025-05 One row per transaction, with its receipt fields on the same row.
`logs` 2025-05 One row per event log a contract emitted.
`traces` 2025-05 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `katananetwork.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `katananetwork.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x00000000efe302beaa2b3e6e1b18d08d69a9012a' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/real-world-assets Tokenized stocks, funds and commodities issued on Katana, tracked against their underlying instruments. Katana real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/katananetwork/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Katana deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Katana by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'katananetwork' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Katana tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'katananetwork' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/stablecoins Every stablecoin issued on Katana: supply, holders and transfers. Katana stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/katananetwork/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Katana by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'katananetwork' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Katana.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'ausd-0x00000000efe302beaa2b3e6e1b18d08d69a9012a-katananetwork' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'ausd-0x00000000efe302beaa2b3e6e1b18d08d69a9012a-katananetwork' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/katananetwork/tokens Katana token transfers, holder balances and daily prices. Four surfaces cover token activity on Katana. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/katananetwork/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'katananetwork' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Katana tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'katananetwork' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'katananetwork' and movements.token_address = '0x00000000efe302beaa2b3e6e1b18d08d69a9012a' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Katana token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'katananetwork', '0x00000000efe302beaa2b3e6e1b18d08d69a9012a', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'katananetwork', '0x00000000efe302beaa2b3e6e1b18d08d69a9012a', 'erc20' ) where account_address = '0x02cdd2dd00e1e0900ec03267cf16e6170ff7b05b' order by balance_date desc limit 20 ``` **Daily price** **Read one Katana token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x00000000efe302beaa2b3e6e1b18d08d69a9012a-katananetwork' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Linea that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Linea table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Linea.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'linea' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Linea.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'linea' and project_id = 'euler' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Linea.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'linea' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/assets Every curated asset issued on Linea, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Linea holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/linea/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/linea/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Linea by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'linea' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Linea deployments by asset kind, and how many were issued on Linea itself.** A deployment is native when the issuer minted the token on Linea, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'linea' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Linea deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x176211869ca2b568f2a7d4ee941e073a821ee1ff-linea' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x176211869ca2b568f2a7d4ee941e073a821ee1ff-linea' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/bridges Cross-chain transfers that left Linea or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'linea'` for transfers leaving Linea, `destination_chain_id = 'linea'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Linea with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'linea', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'linea', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'linea' or destination_chain_id = 'linea') group by day order by day ``` **Where value went** **Find where the value leaving Linea went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'linea' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Linea value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'linea') as leaving, countif(transfers.destination_chain_id = 'linea') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'linea' or transfers.destination_chain_id = 'linea') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/contracts Every contract deployed on Linea, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Linea, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Linea contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'linea' and contract_address = '0x5d57eb11142cd89660e75951612bc8482f6e8f85' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'linea' and creator_address = '0xda36df0764d138993f9811353ecadd6b32caafb9' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Linea.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'linea' and contracts.first_deployed_at >= timestamp('2023-07-01') order by contracts.first_deployed_at desc limit 100 ``` # Linea Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/index Everything the catalog holds for Linea, from raw blocks to project activity. Most of the catalog is queryable for Linea, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `linea` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Linea rows are selected with `chain_id = 'linea'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Linea. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/linea/raw) 2022-12 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/linea/projects) 2023-07 Daily Fees and Revenue for each tracked project, broken out to Linea.
[Assets](/docs/catalog/chain-verticals/evm/linea/assets) 2023-08 Every curated asset issued on Linea, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/linea/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/linea/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/linea/contracts) 2023-07 Every contract deployed on Linea, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/linea/stablecoins) 2023-08 Every stablecoin issued on Linea: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/linea/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on Linea, tracked against their underlying instruments.
[Lending](/docs/catalog/chain-verticals/evm/linea/lending) **In progress** The lending markets deployed on Linea, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/linea/bridges) 2023-07 Cross-chain transfers that left Linea or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `linea` wherever a catalog table has a chain column, so the same filter selects Linea everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'linea' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/lending The lending markets deployed on Linea and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Linea markets with `chain_id = 'linea'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Linea markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'linea' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Linea.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'linea' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/projects Daily Fees and Revenue for each tracked project, broken out to Linea. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Linea fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'linea' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Linea's share** **Work out how much of a project runs on Linea.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/raw The standardized Linea blocks, transactions, logs and internal calls. The `linea` dataset holds the standardized Linea tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2022-12 One row per block, with its gas and fee totals.
`transactions` 2022-12 One row per transaction, with its receipt fields on the same row.
`logs` 2022-12 One row per event log a contract emitted.
`traces` 2022-12 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `linea.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `linea.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x176211869ca2b568f2a7d4ee941e073a821ee1ff' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/real-world-assets Tokenized stocks, funds and commodities issued on Linea, tracked against their underlying instruments. Linea real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/linea/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Linea deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Linea by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'linea' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Linea tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'linea' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/stablecoins Every stablecoin issued on Linea: supply, holders and transfers. Linea stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/linea/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Linea by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'linea' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Linea.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x176211869ca2b568f2a7d4ee941e073a821ee1ff-linea' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x176211869ca2b568f2a7d4ee941e073a821ee1ff-linea' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/linea/tokens Linea token transfers, holder balances and daily prices. Four surfaces cover token activity on Linea. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/linea/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'linea' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Linea tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'linea' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'linea' and movements.token_address = '0x176211869ca2b568f2a7d4ee941e073a821ee1ff' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Linea token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'linea', '0x176211869ca2b568f2a7d4ee941e073a821ee1ff', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'linea', '0x176211869ca2b568f2a7d4ee941e073a821ee1ff', 'erc20' ) where account_address = '0x8dfe562cbb4e93d5029f39da26bb6b501a8d1d3e' order by balance_date desc limit 20 ``` **Daily price** **Read one Linea token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x176211869ca2b568f2a7d4ee941e073a821ee1ff-linea' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Manta that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Manta table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Manta.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'manta' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Manta.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'manta' and project_id = 'quickswap' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Manta.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'manta' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/assets Every curated asset issued on Manta, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Manta holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/manta/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/manta/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Manta by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'manta' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Manta deployments by asset kind, and how many were issued on Manta itself.** A deployment is native when the issuer minted the token on Manta, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'manta' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Manta deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'susde-0x211cc4dd073734da055fbf44a2b4667d5e5fe5d2-manta' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'susde-0x211cc4dd073734da055fbf44a2b4667d5e5fe5d2-manta' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/bridges Cross-chain transfers that left Manta or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'manta'` for transfers leaving Manta, `destination_chain_id = 'manta'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Manta with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'manta', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'manta', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'manta' or destination_chain_id = 'manta') group by day order by day ``` **Where value went** **Find where the value leaving Manta went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'manta' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Manta value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'manta') as leaving, countif(transfers.destination_chain_id = 'manta') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'manta' or transfers.destination_chain_id = 'manta') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/contracts Every contract deployed on Manta, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Manta, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Manta contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'manta' and contract_address = '0x0b4f1e84fbfcc72594cabf9c5506557dd8102fbc' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'manta' and creator_address = '0x0dc5181c28c0e4d89ec7e32fd5ff461394628a7d' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Manta.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'manta' and contracts.first_deployed_at >= timestamp('2023-09-01') order by contracts.first_deployed_at desc limit 100 ``` # Manta Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/index Everything the catalog holds for Manta, from raw blocks to project activity. Most of the catalog is queryable for Manta, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `manta` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Manta rows are selected with `chain_id = 'manta'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Manta. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/manta/raw) 2023-09 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/manta/projects) 2023-09 Daily Fees and Revenue for each tracked project, broken out to Manta.
[Assets](/docs/catalog/chain-verticals/evm/manta/assets) 2024-01 Every curated asset issued on Manta, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/manta/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/manta/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/manta/contracts) 2023-09 Every contract deployed on Manta, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/manta/stablecoins) 2024-03 Every stablecoin issued on Manta: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/manta/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on Manta, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/manta/bridges) 2024-03 Cross-chain transfers that left Manta or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `manta` wherever a catalog table has a chain column, so the same filter selects Manta everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'manta' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/projects Daily Fees and Revenue for each tracked project, broken out to Manta. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Manta fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'manta' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Manta's share** **Work out how much of a project runs on Manta.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/raw The standardized Manta blocks, transactions, logs and internal calls. The `manta` dataset holds the standardized Manta tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2023-09 One row per block, with its gas and fee totals.
`transactions` 2023-09 One row per transaction, with its receipt fields on the same row.
`logs` 2023-09 One row per event log a contract emitted.
`traces` 2023-09 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `manta.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `manta.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x211cc4dd073734da055fbf44a2b4667d5e5fe5d2' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/real-world-assets Tokenized stocks, funds and commodities issued on Manta, tracked against their underlying instruments. Manta real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/manta/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Manta deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Manta by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'manta' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Manta tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'manta' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/stablecoins Every stablecoin issued on Manta: supply, holders and transfers. Manta stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/manta/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Manta by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'manta' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Manta.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'susde-0x211cc4dd073734da055fbf44a2b4667d5e5fe5d2-manta' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'susde-0x211cc4dd073734da055fbf44a2b4667d5e5fe5d2-manta' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/manta/tokens Manta token transfers, holder balances and daily prices. Four surfaces cover token activity on Manta. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/manta/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'manta' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Manta tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'manta' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'manta' and movements.token_address = '0x0dc808adce2099a9f62aa87d9670745aba741746' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Manta token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'manta', '0x0dc808adce2099a9f62aa87d9670745aba741746', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'manta', '0x0dc808adce2099a9f62aa87d9670745aba741746', 'erc20' ) where account_address = '0x556b80e031a72dc07785702e9b3af9f33555771f' order by balance_date desc limit 20 ``` **Daily price** **Read one Manta token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x0dc808adce2099a9f62aa87d9670745aba741746-manta' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/megaeth/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on MegaETH that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any MegaETH table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on MegaETH.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'megaeth' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on MegaETH.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'megaeth' and project_id = 'gainsnetwork' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on MegaETH.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'megaeth' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/megaeth/assets Every curated asset issued on MegaETH, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what MegaETH holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). [Real-world assets](/docs/catalog/chain-verticals/evm/megaeth/real-world-assets) scopes this layer further. ## Sample queries **Largest assets** **Rank the assets on MegaETH by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'megaeth' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count MegaETH deployments by asset kind, and how many were issued on MegaETH itself.** A deployment is native when the issuer minted the token on MegaETH, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'megaeth' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one MegaETH deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'cusd-0xcccc62962d17b8914c62d74ffb843d73b2a3cccc-megaeth' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'cusd-0xcccc62962d17b8914c62d74ffb843d73b2a3cccc-megaeth' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/megaeth/bridges Cross-chain transfers that left MegaETH or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'megaeth'` for transfers leaving MegaETH, `destination_chain_id = 'megaeth'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving MegaETH with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'megaeth', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'megaeth', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'megaeth' or destination_chain_id = 'megaeth') group by day order by day ``` **Where value went** **Find where the value leaving MegaETH went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'megaeth' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the MegaETH value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'megaeth') as leaving, countif(transfers.destination_chain_id = 'megaeth') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'megaeth' or transfers.destination_chain_id = 'megaeth') group by apps.name order by volume_usd desc ``` # MegaETH Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/megaeth/index Everything the catalog holds for MegaETH, from raw blocks to project activity. Most of the catalog is queryable for MegaETH, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `megaeth` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the MegaETH rows are selected with `chain_id = 'megaeth'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on MegaETH. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/megaeth/raw) 2025-11 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/megaeth/projects) 2025-11 Daily Fees and Revenue for each tracked project, broken out to MegaETH.
[Assets](/docs/catalog/chain-verticals/evm/megaeth/assets) 2021-02 Every curated asset issued on MegaETH, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/megaeth/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/megaeth/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Real-world assets](/docs/catalog/chain-verticals/evm/megaeth/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on MegaETH, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/megaeth/bridges) 2025-12 Cross-chain transfers that left MegaETH or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `megaeth` wherever a catalog table has a chain column, so the same filter selects MegaETH everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'megaeth' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/megaeth/projects Daily Fees and Revenue for each tracked project, broken out to MegaETH. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily MegaETH fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'megaeth' and daily.project_id = 'uniswap' order by daily.timestamp ``` **MegaETH's share** **Work out how much of a project runs on MegaETH.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/megaeth/raw The standardized MegaETH blocks, transactions, logs and internal calls. The `megaeth` dataset holds the standardized MegaETH tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-11 One row per block, with its gas and fee totals.
`transactions` 2025-11 One row per transaction, with its receipt fields on the same row.
`logs` 2025-11 One row per event log a contract emitted.
`traces` 2025-11 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `megaeth.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `megaeth.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xcccc62962d17b8914c62d74ffb843d73b2a3cccc' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/megaeth/real-world-assets Tokenized stocks, funds and commodities issued on MegaETH, tracked against their underlying instruments. MegaETH real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/megaeth/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its MegaETH deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on MegaETH by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'megaeth' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List MegaETH tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'megaeth' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/megaeth/tokens MegaETH token transfers, holder balances and daily prices. Four surfaces cover token activity on MegaETH. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/megaeth/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'megaeth' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest MegaETH tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'megaeth' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'megaeth' and movements.token_address = '0xfafddbb3fc7688494971a79cc65dca3ef82079e7' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one MegaETH token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'megaeth', '0xfafddbb3fc7688494971a79cc65dca3ef82079e7', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'megaeth', '0xfafddbb3fc7688494971a79cc65dca3ef82079e7', 'erc20' ) where account_address = '0x12759afca690637b425ffba3265f0dc2f6242a8d' order by balance_date desc limit 20 ``` **Daily price** **Read one MegaETH token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xfafddbb3fc7688494971a79cc65dca3ef82079e7-megaeth' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/metis/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Metis table resolves to a name. # Metis Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/metis/index Everything the catalog holds for Metis, from raw blocks to project activity. The chain's own record is queryable for Metis, with its eligible catalog layers above it. The chain's own record sits in the `metis` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Metis rows are selected with `chain_id = 'metis'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Metis. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/metis/raw) 2021-11 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/metis/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/metis/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `metis` wherever a catalog table has a chain column, so the same filter selects Metis everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `metis.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/metis/raw The standardized Metis blocks, transactions, logs and internal calls. The `metis` dataset holds the standardized Metis tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2021-11 One row per block, with its gas and fee totals.
`transactions` 2021-11 One row per transaction, with its receipt fields on the same row.
`logs` 2021-11 One row per event log a contract emitted.
`traces` 2021-11 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `metis.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `metis.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/metis/tokens Metis token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/mode/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Mode table resolves to a name. # Mode Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/mode/index Everything the catalog holds for Mode, from raw blocks to project activity. The chain's own record is queryable for Mode, with its eligible catalog layers above it. The chain's own record sits in the `mode` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Mode rows are selected with `chain_id = 'mode'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Mode. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/mode/raw) 2023-11 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/mode/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/mode/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `mode` wherever a catalog table has a chain column, so the same filter selects Mode everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `mode.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/mode/raw The standardized Mode blocks, transactions, logs and internal calls. The `mode` dataset holds the standardized Mode tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2023-11 One row per block, with its gas and fee totals.
`transactions` 2023-11 One row per transaction, with its receipt fields on the same row.
`logs` 2023-11 One row per event log a contract emitted.
`traces` 2023-11 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `mode.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `mode.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/mode/tokens Mode token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Monad that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Monad table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Monad.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'monad' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Monad.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'monad' and project_id = 'anchored' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Monad.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'monad' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/assets Every curated asset issued on Monad, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Monad holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/monad/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/monad/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Monad by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'monad' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Monad deployments by asset kind, and how many were issued on Monad itself.** A deployment is native when the issuer minted the token on Monad, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'monad' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Monad deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x754704bc059f8c67012fed69bc8a327a5aafb603-monad' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x754704bc059f8c67012fed69bc8a327a5aafb603-monad' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/bridges Cross-chain transfers that left Monad or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'monad'` for transfers leaving Monad, `destination_chain_id = 'monad'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Monad with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'monad', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'monad', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'monad' or destination_chain_id = 'monad') group by day order by day ``` **Where value went** **Find where the value leaving Monad went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'monad' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Monad value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'monad') as leaving, countif(transfers.destination_chain_id = 'monad') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'monad' or transfers.destination_chain_id = 'monad') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/contracts Every contract deployed on Monad, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Monad, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Monad contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'monad' and contract_address = '0x7acf587be6e4831f2892ffe4f0b092db5b15b591' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'monad' and creator_address = '0xf0a6164266d16dc5b7d26bb2e1ea6aaed50a115b' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Monad.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'monad' and contracts.first_deployed_at >= timestamp('2025-06-01') order by contracts.first_deployed_at desc limit 100 ``` # Monad Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/index Everything the catalog holds for Monad, from raw blocks to project activity. Most of the catalog is queryable for Monad, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `monad` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Monad rows are selected with `chain_id = 'monad'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Monad. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/monad/raw) 2025-05 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/monad/projects) 2025-05 Daily Fees and Revenue for each tracked project, broken out to Monad.
[Assets](/docs/catalog/chain-verticals/evm/monad/assets) 2024-01 Every curated asset issued on Monad, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/monad/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/monad/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/monad/contracts) 2025-06 Every contract deployed on Monad, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/monad/stablecoins) 2025-10 Every stablecoin issued on Monad: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/monad/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on Monad, tracked against their underlying instruments.
[Lending](/docs/catalog/chain-verticals/evm/monad/lending) **In progress** The lending markets deployed on Monad, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/monad/bridges) 2025-10 Cross-chain transfers that left Monad or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `monad` wherever a catalog table has a chain column, so the same filter selects Monad everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'monad' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/lending The lending markets deployed on Monad and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Monad markets with `chain_id = 'monad'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Monad markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'monad' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Monad.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'monad' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/projects Daily Fees and Revenue for each tracked project, broken out to Monad. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Monad fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'monad' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Monad's share** **Work out how much of a project runs on Monad.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/raw The standardized Monad blocks, transactions, logs and internal calls. The `monad` dataset holds the standardized Monad tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-05 One row per block, with its gas and fee totals.
`transactions` 2025-05 One row per transaction, with its receipt fields on the same row.
`logs` 2025-05 One row per event log a contract emitted.
`traces` 2025-05 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `monad.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `monad.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x754704bc059f8c67012fed69bc8a327a5aafb603' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/real-world-assets Tokenized stocks, funds and commodities issued on Monad, tracked against their underlying instruments. Monad real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/monad/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Monad deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Monad by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'monad' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Monad tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'monad' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/stablecoins Every stablecoin issued on Monad: supply, holders and transfers. Monad stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/monad/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Monad by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'monad' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Monad.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x754704bc059f8c67012fed69bc8a327a5aafb603-monad' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x754704bc059f8c67012fed69bc8a327a5aafb603-monad' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/monad/tokens Monad token transfers, holder balances and daily prices. Four surfaces cover token activity on Monad. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/monad/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'monad' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Monad tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'monad' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'monad' and movements.token_address = '0x754704bc059f8c67012fed69bc8a327a5aafb603' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Monad token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'monad', '0x754704bc059f8c67012fed69bc8a327a5aafb603', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'monad', '0x754704bc059f8c67012fed69bc8a327a5aafb603', 'erc20' ) where account_address = '0x2a68ba1833cdf93fa9da1eebd7f46242ad8e90c5' order by balance_date desc limit 20 ``` **Daily price** **Read one Monad token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x754704bc059f8c67012fed69bc8a327a5aafb603-monad' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/opbnb/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on opBNB that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any opBNB table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on opBNB.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'opbnb' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on opBNB.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'opbnb' and project_id = 'seraph' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on opBNB.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'opbnb' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/opbnb/bridges Cross-chain transfers that left opBNB or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'opbnb'` for transfers leaving opBNB, `destination_chain_id = 'opbnb'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving opBNB with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'opbnb', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'opbnb', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'opbnb' or destination_chain_id = 'opbnb') group by day order by day ``` **Where value went** **Find where the value leaving opBNB went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'opbnb' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the opBNB value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'opbnb') as leaving, countif(transfers.destination_chain_id = 'opbnb') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'opbnb' or transfers.destination_chain_id = 'opbnb') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/opbnb/contracts Every contract deployed on opBNB, with the account that created it. `dimensions.contracts` holds one row per contract deployed on opBNB, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one opBNB contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'opbnb' and contract_address = '0xae17830b844b3feb055b08ae88bd791a4ead4be2' ``` **A factory's output** **List the contracts one factory created.** The ChainGPT factory calls `CREATE` for every NFT contract it deploys, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'opbnb' and creator_address = '0xe7bcb5bedaf6585ee737e6d05c25f8050b11d74d' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on opBNB.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'opbnb' and contracts.first_deployed_at >= timestamp('2023-09-01') order by contracts.first_deployed_at desc limit 100 ``` # opBNB Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/opbnb/index Everything the catalog holds for opBNB, from raw blocks to project activity. The chain's own record is queryable for opBNB, with its eligible catalog layers above it. The chain's own record sits in the `opbnb` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the opBNB rows are selected with `chain_id = 'opbnb'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on opBNB. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/opbnb/raw) 2023-08 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/opbnb/projects) 2023-08 Daily Fees and Revenue for each tracked project, broken out to opBNB.
[Tokens](/docs/catalog/chain-verticals/evm/opbnb/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/opbnb/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/opbnb/contracts) 2023-09 Every contract deployed on opBNB, with the account that created it.
[Bridges](/docs/catalog/chain-verticals/evm/opbnb/bridges) 2023-09 Cross-chain transfers that left opBNB or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `opbnb` wherever a catalog table has a chain column, so the same filter selects opBNB everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `opbnb.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/opbnb/projects Daily Fees and Revenue for each tracked project, broken out to opBNB. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily opBNB fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'opbnb' and daily.project_id = 'uniswap' order by daily.timestamp ``` **opBNB's share** **Work out how much of a project runs on opBNB.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/opbnb/raw The standardized opBNB blocks, transactions, logs and internal calls. The `opbnb` dataset holds the standardized opBNB tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2023-08 One row per block, with its gas and fee totals.
`transactions` 2023-08 One row per transaction, with its receipt fields on the same row.
`logs` 2023-08 One row per event log a contract emitted.
`traces` 2023-08 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `opbnb.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `opbnb.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0cdbc60e8c1576d7e721e4b2635410fbf30e3183' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/opbnb/tokens opBNB token transfers, holder balances and daily prices. Four surfaces cover token activity on opBNB. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/assets/registry) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'opbnb' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest opBNB tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'opbnb' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'opbnb' and movements.token_address = '0x9e5aac1ba1a2e6aed6b32689dfcf62a509ca96f3' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one opBNB token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'opbnb', '0x9e5aac1ba1a2e6aed6b32689dfcf62a509ca96f3', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'opbnb', '0x9e5aac1ba1a2e6aed6b32689dfcf62a509ca96f3', 'erc20' ) where account_address = '0xf7fdbffcca80cbca187a13fcecda077e907027c9' order by balance_date desc limit 20 ``` **Daily price** **Read one opBNB token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x9e5aac1ba1a2e6aed6b32689dfcf62a509ca96f3-opbnb' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Optimism that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Optimism table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Optimism.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'optimism' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Optimism.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'optimism' and project_id = 'xstocks' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Optimism.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'optimism' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Optimism. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/optimism/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Optimism for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/optimism/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/optimism/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Optimism** **Rank the apps active on Optimism by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'optimism' group by apps.name order by trading_volume desc ``` **Optimism's share** **Work out how much of one app runs on Optimism.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/assets Every curated asset issued on Optimism, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Optimism holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/optimism/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/optimism/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Optimism by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'optimism' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Optimism deployments by asset kind, and how many were issued on Optimism itself.** A deployment is native when the issuer minted the token on Optimism, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'optimism' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Optimism deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x0b2c639c533813f4aa9d7837caf62653d097ff85-optimism' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x0b2c639c533813f4aa9d7837caf62653d097ff85-optimism' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/bridges Cross-chain transfers that left Optimism or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'optimism'` for transfers leaving Optimism, `destination_chain_id = 'optimism'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Optimism with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'optimism', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'optimism', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'optimism' or destination_chain_id = 'optimism') group by day order by day ``` **Where value went** **Find where the value leaving Optimism went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'optimism' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Optimism value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'optimism') as leaving, countif(transfers.destination_chain_id = 'optimism') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'optimism' or transfers.destination_chain_id = 'optimism') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/contracts Every contract deployed on Optimism, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Optimism, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Optimism contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'optimism' and contract_address = '0x8fb6397adad47e524a63472d8f1129a11a1a2679' ``` **A factory's output** **List the contracts one factory created.** The XEN torrent minter calls `CREATE` for every mint it batches, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'optimism' and creator_address = '0xaf18644083151cf57f914cccc23c42a1892c218e' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Optimism.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'optimism' and contracts.first_deployed_at >= timestamp('2021-11-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/dex Optimism trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Optimism pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Optimism pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'optimism' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Optimism, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'optimism' group by dex_pair_id order by trading_volume desc limit 20 ``` # Optimism Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/index Everything the catalog holds for Optimism, from raw blocks to project activity. Most of the catalog is queryable for Optimism, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `optimism` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Optimism rows are selected with `chain_id = 'optimism'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Optimism. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/optimism/raw) 2021-11 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/optimism/projects) 2021-11 Daily Fees and Revenue for each tracked project, broken out to Optimism.
[Apps](/docs/catalog/chain-verticals/evm/optimism/apps) 2021-11 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Optimism.
[Assets](/docs/catalog/chain-verticals/evm/optimism/assets) 2021-11 Every curated asset issued on Optimism, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/optimism/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/optimism/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/optimism/contracts) 2021-11 Every contract deployed on Optimism, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/optimism/stablecoins) 2021-11 Every stablecoin issued on Optimism: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/optimism/real-world-assets) 2022-04 Tokenized stocks, funds and commodities issued on Optimism, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/optimism/dex) 2021-11 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/optimism/lending) **In progress** The lending markets deployed on Optimism, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/optimism/bridges) 2022-10 Cross-chain transfers that left Optimism or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `optimism` wherever a catalog table has a chain column, so the same filter selects Optimism everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'optimism' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/lending The lending markets deployed on Optimism and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Optimism markets with `chain_id = 'optimism'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Optimism markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'optimism' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Optimism.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'optimism' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/projects Daily Fees and Revenue for each tracked project, broken out to Optimism. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Optimism sit on [Apps](/docs/catalog/chain-verticals/evm/optimism/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Optimism fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'optimism' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Optimism's share** **Work out how much of a project runs on Optimism.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/raw The standardized Optimism blocks, transactions, logs and internal calls. The `optimism` dataset holds the standardized Optimism tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2021-11 One row per block, with its gas and fee totals.
`transactions` 2021-11 One row per transaction, with its receipt fields on the same row.
`logs` 2021-11 One row per event log a contract emitted.
`traces` 2021-11 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `optimism.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `optimism.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0b2c639c533813f4aa9d7837caf62653d097ff85' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/real-world-assets Tokenized stocks, funds and commodities issued on Optimism, tracked against their underlying instruments. Optimism real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/optimism/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Optimism deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Optimism by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'optimism' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Optimism tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'optimism' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/stablecoins Every stablecoin issued on Optimism: supply, holders and transfers. Optimism stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/optimism/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Optimism by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'optimism' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Optimism.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x0b2c639c533813f4aa9d7837caf62653d097ff85-optimism' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x0b2c639c533813f4aa9d7837caf62653d097ff85-optimism' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/optimism/tokens Optimism token transfers, holder balances and daily prices. Four surfaces cover token activity on Optimism. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/optimism/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'optimism' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Optimism tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'optimism' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'optimism' and movements.token_address = '0x0b2c639c533813f4aa9d7837caf62653d097ff85' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Optimism token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'optimism', '0x0b2c639c533813f4aa9d7837caf62653d097ff85', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'optimism', '0x0b2c639c533813f4aa9d7837caf62653d097ff85', 'erc20' ) where account_address = '0x343c41429cfad966dbb8a00c5fd096dbb8dc320f' order by balance_date desc limit 20 ``` **Daily price** **Read one Optimism token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x0b2c639c533813f4aa9d7837caf62653d097ff85-optimism' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Plasma that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Plasma table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Plasma.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'plasma' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Plasma.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'plasma' and project_id = 'uniswap' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Plasma.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'plasma' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Plasma. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/plasma/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Plasma for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/plasma/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/plasma/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Plasma** **Rank the apps active on Plasma by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'plasma' group by apps.name order by trading_volume desc ``` **Plasma's share** **Work out how much of one app runs on Plasma.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/assets Every curated asset issued on Plasma, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Plasma holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/plasma/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/plasma/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Plasma by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'plasma' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Plasma deployments by asset kind, and how many were issued on Plasma itself.** A deployment is native when the issuer minted the token on Plasma, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'plasma' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Plasma deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'aplagho-0xad571979b4245e163a7e2119eb4dfd94afdaebc5-plasma' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'aplagho-0xad571979b4245e163a7e2119eb4dfd94afdaebc5-plasma' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/bridges Cross-chain transfers that left Plasma or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'plasma'` for transfers leaving Plasma, `destination_chain_id = 'plasma'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Plasma with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'plasma', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'plasma', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'plasma' or destination_chain_id = 'plasma') group by day order by day ``` **Where value went** **Find where the value leaving Plasma went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'plasma' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Plasma value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'plasma') as leaving, countif(transfers.destination_chain_id = 'plasma') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'plasma' or transfers.destination_chain_id = 'plasma') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/contracts Every contract deployed on Plasma, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Plasma, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Plasma contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'plasma' and contract_address = '0x1ec24466a9653bd3efa49729eb5d36db420b5f61' ``` **A factory's output** **List the contracts one factory created.** The Safe proxy factory calls `CREATE` for every Safe account it deploys, so `creator_address` returns the account list. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'plasma' and creator_address = '0xa6b71e26c5e0845f74c812102ca7114b6a896ab2' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Plasma.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'plasma' and contracts.first_deployed_at >= timestamp('2025-09-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/dex Plasma trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Plasma pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Plasma pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'plasma' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Plasma, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'plasma' group by dex_pair_id order by trading_volume desc limit 20 ``` # Plasma Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/index Everything the catalog holds for Plasma, from raw blocks to project activity. Most of the catalog is queryable for Plasma, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `plasma` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Plasma rows are selected with `chain_id = 'plasma'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Plasma. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/plasma/raw) 2025-09 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/plasma/projects) 2025-09 Daily Fees and Revenue for each tracked project, broken out to Plasma.
[Apps](/docs/catalog/chain-verticals/evm/plasma/apps) 2025-09 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Plasma.
[Assets](/docs/catalog/chain-verticals/evm/plasma/assets) 2024-01 Every curated asset issued on Plasma, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/plasma/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/plasma/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/plasma/contracts) 2025-09 Every contract deployed on Plasma, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/plasma/stablecoins) 2025-09 Every stablecoin issued on Plasma: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/plasma/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on Plasma, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/plasma/dex) 2025-09 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/plasma/lending) **In progress** The lending markets deployed on Plasma, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/plasma/bridges) 2025-09 Cross-chain transfers that left Plasma or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `plasma` wherever a catalog table has a chain column, so the same filter selects Plasma everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'plasma' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/lending The lending markets deployed on Plasma and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Plasma markets with `chain_id = 'plasma'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Plasma markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'plasma' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Plasma.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'plasma' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/projects Daily Fees and Revenue for each tracked project, broken out to Plasma. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Plasma sit on [Apps](/docs/catalog/chain-verticals/evm/plasma/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Plasma fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'plasma' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Plasma's share** **Work out how much of a project runs on Plasma.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/raw The standardized Plasma blocks, transactions, logs and internal calls. The `plasma` dataset holds the standardized Plasma tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-09 One row per block, with its gas and fee totals.
`transactions` 2025-09 One row per transaction, with its receipt fields on the same row.
`logs` 2025-09 One row per event log a contract emitted.
`traces` 2025-09 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `plasma.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `plasma.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xad571979b4245e163a7e2119eb4dfd94afdaebc5' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/real-world-assets Tokenized stocks, funds and commodities issued on Plasma, tracked against their underlying instruments. Plasma real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/plasma/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Plasma deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Plasma by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'plasma' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Plasma tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'plasma' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/stablecoins Every stablecoin issued on Plasma: supply, holders and transfers. Plasma stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/plasma/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Plasma by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'plasma' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Plasma.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'aplagho-0xad571979b4245e163a7e2119eb4dfd94afdaebc5-plasma' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'aplagho-0xad571979b4245e163a7e2119eb4dfd94afdaebc5-plasma' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/plasma/tokens Plasma token transfers, holder balances and daily prices. Four surfaces cover token activity on Plasma. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/plasma/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'plasma' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Plasma tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'plasma' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'plasma' and movements.token_address = '0xad571979b4245e163a7e2119eb4dfd94afdaebc5' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Plasma token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'plasma', '0xad571979b4245e163a7e2119eb4dfd94afdaebc5', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'plasma', '0xad571979b4245e163a7e2119eb4dfd94afdaebc5', 'erc20' ) where account_address = '0xa1c93d2687f7014aaf588c764e3ce80af016229b' order by balance_date desc limit 20 ``` **Daily price** **Read one Plasma token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xad571979b4245e163a7e2119eb4dfd94afdaebc5-plasma' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Polygon that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Polygon table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Polygon.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'polygon' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Polygon.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'polygon' and project_id = 'chainlink' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Polygon.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'polygon' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Polygon. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/polygon/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Polygon for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/polygon/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/polygon/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Polygon** **Rank the apps active on Polygon by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'polygon' group by apps.name order by trading_volume desc ``` **Polygon's share** **Work out how much of one app runs on Polygon.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/assets Every curated asset issued on Polygon, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Polygon holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/polygon/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/polygon/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Polygon by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'polygon' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Polygon deployments by asset kind, and how many were issued on Polygon itself.** A deployment is native when the issuer minted the token on Polygon, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'polygon' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Polygon deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x3c499c542cef5e3811e1192ce70d8cc03d5c3359-polygon' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x3c499c542cef5e3811e1192ce70d8cc03d5c3359-polygon' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/bridges Cross-chain transfers that left Polygon or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'polygon'` for transfers leaving Polygon, `destination_chain_id = 'polygon'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Polygon with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'polygon', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'polygon', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'polygon' or destination_chain_id = 'polygon') group by day order by day ``` **Where value went** **Find where the value leaving Polygon went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'polygon' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Polygon value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'polygon') as leaving, countif(transfers.destination_chain_id = 'polygon') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'polygon' or transfers.destination_chain_id = 'polygon') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/contracts Every contract deployed on Polygon, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Polygon, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Polygon contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'polygon' and contract_address = '0xf0f07ab0ee591c0ef2e6120738f30ccdd2665eb9' ``` **A factory's output** **List the contracts one factory created.** The CoinTool batch minter calls `CREATE` for every contract it stamps out, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'polygon' and creator_address = '0xdf6fee057222d2f7933c215c11e5150bd2efc53e' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Polygon.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'polygon' and contracts.first_deployed_at >= timestamp('2021-01-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/dex Polygon trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Polygon pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Polygon pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'polygon' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Polygon, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'polygon' group by dex_pair_id order by trading_volume desc limit 20 ``` # Polygon Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/index Everything the catalog holds for Polygon, from raw blocks to project activity. Most of the catalog is queryable for Polygon, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `polygon` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Polygon rows are selected with `chain_id = 'polygon'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Polygon. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/polygon/raw) 2020-05 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/polygon/projects) 2020-05 Daily Fees and Revenue for each tracked project, broken out to Polygon.
[Apps](/docs/catalog/chain-verticals/evm/polygon/apps) 2021-12 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Polygon.
[Assets](/docs/catalog/chain-verticals/evm/polygon/assets) 2020-09 Every curated asset issued on Polygon, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/polygon/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/polygon/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/polygon/contracts) 2021-01 Every contract deployed on Polygon, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/polygon/stablecoins) 2020-09 Every stablecoin issued on Polygon: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/polygon/real-world-assets) 2022-09 Tokenized stocks, funds and commodities issued on Polygon, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/polygon/dex) 2021-12 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/polygon/lending) **In progress** The lending markets deployed on Polygon, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/polygon/bridges) 2022-10 Cross-chain transfers that left Polygon or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `polygon` wherever a catalog table has a chain column, so the same filter selects Polygon everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'polygon' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/lending The lending markets deployed on Polygon and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Polygon markets with `chain_id = 'polygon'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Polygon markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'polygon' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Polygon.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'polygon' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/projects Daily Fees and Revenue for each tracked project, broken out to Polygon. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Polygon sit on [Apps](/docs/catalog/chain-verticals/evm/polygon/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Polygon fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'polygon' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Polygon's share** **Work out how much of a project runs on Polygon.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/raw The standardized Polygon blocks, transactions, logs and internal calls. The `polygon` dataset holds the standardized Polygon tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2020-05 One row per block, with its gas and fee totals.
`transactions` 2020-05 One row per transaction, with its receipt fields on the same row.
`logs` 2020-05 One row per event log a contract emitted.
`traces` 2020-05 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `polygon.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `polygon.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x3c499c542cef5e3811e1192ce70d8cc03d5c3359' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/real-world-assets Tokenized stocks, funds and commodities issued on Polygon, tracked against their underlying instruments. Polygon real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/polygon/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Polygon deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Polygon by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'polygon' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Polygon tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'polygon' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/stablecoins Every stablecoin issued on Polygon: supply, holders and transfers. Polygon stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/polygon/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Polygon by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'polygon' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Polygon.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x3c499c542cef5e3811e1192ce70d8cc03d5c3359-polygon' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x3c499c542cef5e3811e1192ce70d8cc03d5c3359-polygon' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/polygon/tokens Polygon token transfers, holder balances and daily prices. Four surfaces cover token activity on Polygon. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/polygon/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'polygon' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Polygon tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'polygon' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'polygon' and movements.token_address = '0x3c499c542cef5e3811e1192ce70d8cc03d5c3359' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Polygon token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'polygon', '0x3c499c542cef5e3811e1192ce70d8cc03d5c3359', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'polygon', '0x3c499c542cef5e3811e1192ce70d8cc03d5c3359', 'erc20' ) where account_address = '0x66fa4d79ca84016b42352be33c908dd812952ec8' order by balance_date desc limit 20 ``` **Daily price** **Read one Polygon token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x3c499c542cef5e3811e1192ce70d8cc03d5c3359-polygon' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Robinhood Chain that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Robinhood Chain table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Robinhood Chain.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'robinhoodchain' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Robinhood Chain.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'robinhoodchain' and project_id = 'robinhood' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Robinhood Chain.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'robinhoodchain' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Robinhood Chain. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/robinhoodchain/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Robinhood Chain for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/robinhoodchain/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/robinhoodchain/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Robinhood Chain** **Rank the apps active on Robinhood Chain by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'robinhoodchain' group by apps.name order by trading_volume desc ``` **Robinhood Chain's share** **Work out how much of one app runs on Robinhood Chain.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/assets Every curated asset issued on Robinhood Chain, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Robinhood Chain holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/robinhoodchain/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/robinhoodchain/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Robinhood Chain by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'robinhoodchain' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Robinhood Chain deployments by asset kind, and how many were issued on Robinhood Chain itself.** A deployment is native when the issuer minted the token on Robinhood Chain, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'robinhoodchain' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Robinhood Chain deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'arcusdg-0x4fdbdaf4800fc28c22a967d23a343acce34315a4-robinhoodchain' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'arcusdg-0x4fdbdaf4800fc28c22a967d23a343acce34315a4-robinhoodchain' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/bridges Cross-chain transfers that left Robinhood Chain or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'robinhoodchain'` for transfers leaving Robinhood Chain, `destination_chain_id = 'robinhoodchain'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Robinhood Chain with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'robinhoodchain', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'robinhoodchain', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'robinhoodchain' or destination_chain_id = 'robinhoodchain') group by day order by day ``` **Where value went** **Find where the value leaving Robinhood Chain went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'robinhoodchain' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Robinhood Chain value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'robinhoodchain') as leaving, countif(transfers.destination_chain_id = 'robinhoodchain') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'robinhoodchain' or transfers.destination_chain_id = 'robinhoodchain') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/contracts Every contract deployed on Robinhood Chain, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Robinhood Chain, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Robinhood Chain contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'robinhoodchain' and contract_address = '0x0175942f126a544fe283216799824fb44c33dd6d' ``` **A factory's output** **List the contracts one factory created.** The Uniswap factory calls `CREATE` for every pool it deploys, so `creator_address` returns the pool list. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'robinhoodchain' and creator_address = '0x1f7d7550b1b028f7571e69a784071f0205fd2efa' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Robinhood Chain.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'robinhoodchain' and contracts.first_deployed_at >= timestamp('2026-04-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/dex Robinhood Chain trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Robinhood Chain pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Robinhood Chain pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'robinhoodchain' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Robinhood Chain, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'robinhoodchain' group by dex_pair_id order by trading_volume desc limit 20 ``` # Robinhood Chain Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/index Everything the catalog holds for Robinhood Chain, from raw blocks to project activity. Most of the catalog is queryable for Robinhood Chain, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `robinhoodchain` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Robinhood Chain rows are selected with `chain_id = 'robinhoodchain'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Robinhood Chain. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/robinhoodchain/raw) 2026-04 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/robinhoodchain/projects) 2026-04 Daily Fees and Revenue for each tracked project, broken out to Robinhood Chain.
[Apps](/docs/catalog/chain-verticals/evm/robinhoodchain/apps) 2026-06 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Robinhood Chain.
[Assets](/docs/catalog/chain-verticals/evm/robinhoodchain/assets) 2021-02 Every curated asset issued on Robinhood Chain, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/robinhoodchain/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/robinhoodchain/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/robinhoodchain/contracts) 2026-04 Every contract deployed on Robinhood Chain, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/robinhoodchain/stablecoins) 2026-05 Every stablecoin issued on Robinhood Chain: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/robinhoodchain/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on Robinhood Chain, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/robinhoodchain/dex) 2026-05 Trading pools, their daily volume, value locked and fees.
[Bridges](/docs/catalog/chain-verticals/evm/robinhoodchain/bridges) 2026-05 Cross-chain transfers that left Robinhood Chain or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `robinhoodchain` wherever a catalog table has a chain column, so the same filter selects Robinhood Chain everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'robinhoodchain' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/projects Daily Fees and Revenue for each tracked project, broken out to Robinhood Chain. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Robinhood Chain sit on [Apps](/docs/catalog/chain-verticals/evm/robinhoodchain/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Robinhood Chain fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'robinhoodchain' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Robinhood Chain's share** **Work out how much of a project runs on Robinhood Chain.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/raw The standardized Robinhood Chain blocks, transactions, logs and internal calls. The `robinhoodchain` dataset holds the standardized Robinhood Chain tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2026-04 One row per block, with its gas and fee totals.
`transactions` 2026-04 One row per transaction, with its receipt fields on the same row.
`logs` 2026-04 One row per event log a contract emitted.
`traces` 2026-04 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `robinhoodchain.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `robinhoodchain.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x4fdbdaf4800fc28c22a967d23a343acce34315a4' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/real-world-assets Tokenized stocks, funds and commodities issued on Robinhood Chain, tracked against their underlying instruments. Robinhood Chain real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/robinhoodchain/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Robinhood Chain deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Robinhood Chain by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'robinhoodchain' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Robinhood Chain tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'robinhoodchain' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/stablecoins Every stablecoin issued on Robinhood Chain: supply, holders and transfers. Robinhood Chain stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/robinhoodchain/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Robinhood Chain by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'robinhoodchain' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Robinhood Chain.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'arcusdg-0x4fdbdaf4800fc28c22a967d23a343acce34315a4-robinhoodchain' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'arcusdg-0x4fdbdaf4800fc28c22a967d23a343acce34315a4-robinhoodchain' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/robinhoodchain/tokens Robinhood Chain token transfers, holder balances and daily prices. Four surfaces cover token activity on Robinhood Chain. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/robinhoodchain/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'robinhoodchain' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Robinhood Chain tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'robinhoodchain' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'robinhoodchain' and movements.token_address = '0x4fdbdaf4800fc28c22a967d23a343acce34315a4' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Robinhood Chain token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'robinhoodchain', '0x4fdbdaf4800fc28c22a967d23a343acce34315a4', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'robinhoodchain', '0x4fdbdaf4800fc28c22a967d23a343acce34315a4', 'erc20' ) where account_address = '0xd42c46c7bad6a54b38395f846b09981ce75fb8e2' order by balance_date desc limit 20 ``` **Daily price** **Read one Robinhood Chain token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x4fdbdaf4800fc28c22a967d23a343acce34315a4-robinhoodchain' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Rootstock that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Rootstock table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Rootstock.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'rootstock' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Rootstock.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'rootstock' and project_id = 'layerzero' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Rootstock.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'rootstock' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/assets Every curated asset issued on Rootstock, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Rootstock holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/rootstock/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/rootstock/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Rootstock by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'rootstock' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Rootstock deployments by asset kind, and how many were issued on Rootstock itself.** A deployment is native when the issuer minted the token on Rootstock, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'rootstock' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Rootstock deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'acredit03-0xbfbfffb8414a26debc0d8105d3ca175380a4ab78-rootstock' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'acredit03-0xbfbfffb8414a26debc0d8105d3ca175380a4ab78-rootstock' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/bridges Cross-chain transfers that left Rootstock or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'rootstock'` for transfers leaving Rootstock, `destination_chain_id = 'rootstock'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Rootstock with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'rootstock', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'rootstock', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'rootstock' or destination_chain_id = 'rootstock') group by day order by day ``` **Where value went** **Find where the value leaving Rootstock went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'rootstock' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Rootstock value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'rootstock') as leaving, countif(transfers.destination_chain_id = 'rootstock') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'rootstock' or transfers.destination_chain_id = 'rootstock') group by apps.name order by volume_usd desc ``` # Rootstock Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/index Everything the catalog holds for Rootstock, from raw blocks to project activity. Most of the catalog is queryable for Rootstock, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `rootstock` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Rootstock rows are selected with `chain_id = 'rootstock'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Rootstock. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/rootstock/raw) 2018-01 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/rootstock/projects) 2018-01 Daily Fees and Revenue for each tracked project, broken out to Rootstock.
[Assets](/docs/catalog/chain-verticals/evm/rootstock/assets) 2019-10 Every curated asset issued on Rootstock, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/rootstock/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/rootstock/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Stablecoins](/docs/catalog/chain-verticals/evm/rootstock/stablecoins) 2019-10 Every stablecoin issued on Rootstock: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/rootstock/real-world-assets) 2025-11 Tokenized stocks, funds and commodities issued on Rootstock, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/rootstock/bridges) 2024-12 Cross-chain transfers that left Rootstock or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `rootstock` wherever a catalog table has a chain column, so the same filter selects Rootstock everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'rootstock' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/projects Daily Fees and Revenue for each tracked project, broken out to Rootstock. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Rootstock fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'rootstock' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Rootstock's share** **Work out how much of a project runs on Rootstock.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/raw The standardized Rootstock blocks, transactions, logs and internal calls. The `rootstock` dataset holds the standardized Rootstock tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2018-01 One row per block, with its gas and fee totals.
`transactions` 2018-01 One row per transaction, with its receipt fields on the same row.
`logs` 2018-01 One row per event log a contract emitted.
`traces` 2018-01 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `rootstock.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `rootstock.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xbfbfffb8414a26debc0d8105d3ca175380a4ab78' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/real-world-assets Tokenized stocks, funds and commodities issued on Rootstock, tracked against their underlying instruments. Rootstock real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/rootstock/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Rootstock deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Rootstock by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'rootstock' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Rootstock tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'rootstock' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/stablecoins Every stablecoin issued on Rootstock: supply, holders and transfers. Rootstock stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/rootstock/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Rootstock by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'rootstock' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Rootstock.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'acredit03-0xbfbfffb8414a26debc0d8105d3ca175380a4ab78-rootstock' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'acredit03-0xbfbfffb8414a26debc0d8105d3ca175380a4ab78-rootstock' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/rootstock/tokens Rootstock token transfers, holder balances and daily prices. Four surfaces cover token activity on Rootstock. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/rootstock/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'rootstock' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Rootstock tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'rootstock' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'rootstock' and movements.token_address = '0x542fda317318ebf1d3deaf76e0b632741a7e677d' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Rootstock token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'rootstock', '0x542fda317318ebf1d3deaf76e0b632741a7e677d', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'rootstock', '0x542fda317318ebf1d3deaf76e0b632741a7e677d', 'erc20' ) where account_address = '0xaef6fabf3b0c9e5f9d6d5170afc703a633479bbd' order by balance_date desc limit 20 ``` **Daily price** **Read one Rootstock token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x542fda317318ebf1d3deaf76e0b632741a7e677d-rootstock' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Scroll that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Scroll table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Scroll.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'scroll' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Scroll.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'scroll' and project_id = 'quillfinance' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Scroll.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'scroll' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/assets Every curated asset issued on Scroll, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Scroll holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). [Stablecoins](/docs/catalog/chain-verticals/evm/scroll/stablecoins) scopes this layer further. ## Sample queries **Largest assets** **Rank the assets on Scroll by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'scroll' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Scroll deployments by asset kind, and how many were issued on Scroll itself.** A deployment is native when the issuer minted the token on Scroll, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'scroll' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Scroll deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'ascrscr-0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64-scroll' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'ascrscr-0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64-scroll' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/bridges Cross-chain transfers that left Scroll or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'scroll'` for transfers leaving Scroll, `destination_chain_id = 'scroll'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Scroll with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'scroll', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'scroll', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'scroll' or destination_chain_id = 'scroll') group by day order by day ``` **Where value went** **Find where the value leaving Scroll went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'scroll' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Scroll value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'scroll') as leaving, countif(transfers.destination_chain_id = 'scroll') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'scroll' or transfers.destination_chain_id = 'scroll') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/contracts Every contract deployed on Scroll, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Scroll, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Scroll contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'scroll' and contract_address = '0xfcf68a50dae273c3bb71e1755b866a41d3e97ece' ``` **A factory's output** **List the contracts one factory created.** The ether.fi cash factory calls `CREATE` for every account contract it deploys, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'scroll' and creator_address = '0xf4e147db314947fc1275a8cbb6cde48c510cd8cf' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Scroll.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'scroll' and contracts.first_deployed_at >= timestamp('2023-10-01') order by contracts.first_deployed_at desc limit 100 ``` # Scroll Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/index Everything the catalog holds for Scroll, from raw blocks to project activity. Most of the catalog is queryable for Scroll, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `scroll` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Scroll rows are selected with `chain_id = 'scroll'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Scroll. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/scroll/raw) 2023-10 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/scroll/projects) 2023-10 Daily Fees and Revenue for each tracked project, broken out to Scroll.
[Assets](/docs/catalog/chain-verticals/evm/scroll/assets) 2024-02 Every curated asset issued on Scroll, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/scroll/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/scroll/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/scroll/contracts) 2023-10 Every contract deployed on Scroll, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/scroll/stablecoins) 2024-03 Every stablecoin issued on Scroll: supply, holders and transfers.
[Lending](/docs/catalog/chain-verticals/evm/scroll/lending) **In progress** The lending markets deployed on Scroll, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/scroll/bridges) 2024-03 Cross-chain transfers that left Scroll or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `scroll` wherever a catalog table has a chain column, so the same filter selects Scroll everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'scroll' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/lending The lending markets deployed on Scroll and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Scroll markets with `chain_id = 'scroll'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Scroll markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'scroll' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Scroll.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'scroll' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/projects Daily Fees and Revenue for each tracked project, broken out to Scroll. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Scroll fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'scroll' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Scroll's share** **Work out how much of a project runs on Scroll.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/raw The standardized Scroll blocks, transactions, logs and internal calls. The `scroll` dataset holds the standardized Scroll tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2023-10 One row per block, with its gas and fee totals.
`transactions` 2023-10 One row per transaction, with its receipt fields on the same row.
`logs` 2023-10 One row per event log a contract emitted.
`traces` 2023-10 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `scroll.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `scroll.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64' ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/stablecoins Every stablecoin issued on Scroll: supply, holders and transfers. Scroll stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/scroll/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Scroll by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'scroll' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Scroll.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'ascrscr-0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64-scroll' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'ascrscr-0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64-scroll' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/scroll/tokens Scroll token transfers, holder balances and daily prices. Four surfaces cover token activity on Scroll. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/scroll/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'scroll' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Scroll tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'scroll' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'scroll' and movements.token_address = '0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Scroll token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'scroll', '0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'scroll', '0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64', 'erc20' ) where account_address = '0x0000000000000000000000000000000000000000' order by balance_date desc limit 20 ``` **Daily price** **Read one Scroll token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x25718130c2a8eb94e2e1fafb5f1cdd4b459acf64-scroll' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Sei EVM that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Sei EVM table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Sei EVM.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'seievm' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Sei EVM.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'seievm' and project_id = 'yeifinance' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Sei EVM.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'seievm' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/assets Every curated asset issued on Sei EVM, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Sei EVM holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/seievm/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/seievm/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Sei EVM by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'seievm' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Sei EVM deployments by asset kind, and how many were issued on Sei EVM itself.** A deployment is native when the issuer minted the token on Sei EVM, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'seievm' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Sei EVM deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392-seievm' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392-seievm' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/bridges Cross-chain transfers that left Sei EVM or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'seievm'` for transfers leaving Sei EVM, `destination_chain_id = 'seievm'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Sei EVM with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'seievm', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'seievm', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'seievm' or destination_chain_id = 'seievm') group by day order by day ``` **Where value went** **Find where the value leaving Sei EVM went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'seievm' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Sei EVM value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'seievm') as leaving, countif(transfers.destination_chain_id = 'seievm') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'seievm' or transfers.destination_chain_id = 'seievm') group by apps.name order by volume_usd desc ``` # Sei EVM Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/index Everything the catalog holds for Sei EVM, from raw blocks to project activity. Most of the catalog is queryable for Sei EVM, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `seievm` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Sei EVM rows are selected with `chain_id = 'seievm'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Sei EVM. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/seievm/raw) 2024-05 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/seievm/projects) 2024-05 Daily Fees and Revenue for each tracked project, broken out to Sei EVM.
[Assets](/docs/catalog/chain-verticals/evm/seievm/assets) 2023-11 Every curated asset issued on Sei EVM, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/seievm/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/seievm/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Stablecoins](/docs/catalog/chain-verticals/evm/seievm/stablecoins) 2024-07 Every stablecoin issued on Sei EVM: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/seievm/real-world-assets) 2023-11 Tokenized stocks, funds and commodities issued on Sei EVM, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/seievm/bridges) 2024-06 Cross-chain transfers that left Sei EVM or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `seievm` wherever a catalog table has a chain column, so the same filter selects Sei EVM everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'seievm' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/projects Daily Fees and Revenue for each tracked project, broken out to Sei EVM. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Sei EVM fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'seievm' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Sei EVM's share** **Work out how much of a project runs on Sei EVM.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/raw The standardized Sei EVM blocks, transactions, logs and internal calls. The `seievm` dataset holds the standardized Sei EVM tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-05 One row per block, with its gas and fee totals.
`transactions` 2024-05 One row per transaction, with its receipt fields on the same row.
`logs` 2024-05 One row per event log a contract emitted.
`traces` 2024-05 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `seievm.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `seievm.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/real-world-assets Tokenized stocks, funds and commodities issued on Sei EVM, tracked against their underlying instruments. Sei EVM real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/seievm/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Sei EVM deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Sei EVM by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'seievm' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Sei EVM tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'seievm' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/stablecoins Every stablecoin issued on Sei EVM: supply, holders and transfers. Sei EVM stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/seievm/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Sei EVM by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'seievm' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Sei EVM.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392-seievm' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392-seievm' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/seievm/tokens Sei EVM token transfers, holder balances and daily prices. Four surfaces cover token activity on Sei EVM. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/seievm/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'seievm' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Sei EVM tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'seievm' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'seievm' and movements.token_address = '0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Sei EVM token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'seievm', '0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'seievm', '0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392', 'erc20' ) where account_address = '0xf62bd525e82577a162de88bd70de032a62675237' order by balance_date desc limit 20 ``` **Daily price** **Read one Sei EVM token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392-seievm' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/settlus/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Settlus table resolves to a name. # Settlus Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/settlus/index Everything the catalog holds for Settlus, from raw blocks to project activity. The chain's own record is queryable for Settlus, with its eligible catalog layers above it. The chain's own record sits in the `settlus` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Settlus rows are selected with `chain_id = 'settlus'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Settlus. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/settlus/raw) 2025-02 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/settlus/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/settlus/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `settlus` wherever a catalog table has a chain column, so the same filter selects Settlus everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `settlus.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/settlus/raw The standardized Settlus blocks, transactions, logs and internal calls. The `settlus` dataset holds the standardized Settlus tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-02 One row per block, with its gas and fee totals.
`transactions` 2025-02 One row per transaction, with its receipt fields on the same row.
`logs` 2025-02 One row per event log a contract emitted.
`traces` 2025-02 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `settlus.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `settlus.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/settlus/tokens Settlus token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/shape/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Shape table resolves to a name. # Shape Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/shape/index Everything the catalog holds for Shape, from raw blocks to project activity. The chain's own record is queryable for Shape, with its eligible catalog layers above it. The chain's own record sits in the `shape` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Shape rows are selected with `chain_id = 'shape'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Shape. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/shape/raw) 2024-07 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/shape/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/shape/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `shape` wherever a catalog table has a chain column, so the same filter selects Shape everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `shape.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/shape/raw The standardized Shape blocks, transactions, logs and internal calls. The `shape` dataset holds the standardized Shape tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-07 One row per block, with its gas and fee totals.
`transactions` 2024-07 One row per transaction, with its receipt fields on the same row.
`logs` 2024-07 One row per event log a contract emitted.
`traces` 2024-07 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `shape.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `shape.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/shape/tokens Shape token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/soneium/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Soneium table resolves to a name. # Soneium Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/soneium/index Everything the catalog holds for Soneium, from raw blocks to project activity. The chain's own record is queryable for Soneium, with its eligible catalog layers above it. The chain's own record sits in the `soneium` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Soneium rows are selected with `chain_id = 'soneium'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Soneium. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/soneium/raw) 2024-12 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/soneium/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/soneium/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `soneium` wherever a catalog table has a chain column, so the same filter selects Soneium everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `soneium.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/soneium/raw The standardized Soneium blocks, transactions, logs and internal calls. The `soneium` dataset holds the standardized Soneium tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-12 One row per block, with its gas and fee totals.
`transactions` 2024-12 One row per transaction, with its receipt fields on the same row.
`logs` 2024-12 One row per event log a contract emitted.
`traces` 2024-12 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `soneium.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `soneium.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/soneium/tokens Soneium token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Sonic that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Sonic table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Sonic.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'sonic' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Sonic.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'sonic' and project_id = 'paintswap' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Sonic.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'sonic' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/assets Every curated asset issued on Sonic, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Sonic holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/sonic/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/sonic/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Sonic by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'sonic' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Sonic deployments by asset kind, and how many were issued on Sonic itself.** A deployment is native when the issuer minted the token on Sonic, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'sonic' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Sonic deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x29219dd400f2bf60e5a23d13be72b486d4038894-sonic' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x29219dd400f2bf60e5a23d13be72b486d4038894-sonic' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/bridges Cross-chain transfers that left Sonic or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'sonic'` for transfers leaving Sonic, `destination_chain_id = 'sonic'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Sonic with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'sonic', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'sonic', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'sonic' or destination_chain_id = 'sonic') group by day order by day ``` **Where value went** **Find where the value leaving Sonic went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'sonic' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Sonic value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'sonic') as leaving, countif(transfers.destination_chain_id = 'sonic') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'sonic' or transfers.destination_chain_id = 'sonic') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/contracts Every contract deployed on Sonic, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Sonic, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Sonic contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'sonic' and contract_address = '0xe5520f9332e604e1ec6266f57bc35e678f51ea94' ``` **A factory's output** **List the contracts one factory created.** The Shadow Exchange factory calls `CREATE` for every pool it deploys, so `creator_address` returns the pool list. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'sonic' and creator_address = '0x2da25e7446a70d7be65fd4c053948becaa6374c8' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Sonic.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'sonic' and contracts.first_deployed_at >= timestamp('2024-12-01') order by contracts.first_deployed_at desc limit 100 ``` # Sonic Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/index Everything the catalog holds for Sonic, from raw blocks to project activity. Most of the catalog is queryable for Sonic, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `sonic` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Sonic rows are selected with `chain_id = 'sonic'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Sonic. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/sonic/raw) 2024-12 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/sonic/projects) 2024-12 Daily Fees and Revenue for each tracked project, broken out to Sonic.
[Assets](/docs/catalog/chain-verticals/evm/sonic/assets) 2024-12 Every curated asset issued on Sonic, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/sonic/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/sonic/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/sonic/contracts) 2024-12 Every contract deployed on Sonic, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/sonic/stablecoins) 2024-12 Every stablecoin issued on Sonic: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/sonic/real-world-assets) 2024-12 Tokenized stocks, funds and commodities issued on Sonic, tracked against their underlying instruments.
[Lending](/docs/catalog/chain-verticals/evm/sonic/lending) **In progress** The lending markets deployed on Sonic, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/sonic/bridges) 2024-12 Cross-chain transfers that left Sonic or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `sonic` wherever a catalog table has a chain column, so the same filter selects Sonic everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'sonic' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/lending The lending markets deployed on Sonic and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the Sonic markets with `chain_id = 'sonic'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count Sonic markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'sonic' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on Sonic.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'sonic' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/projects Daily Fees and Revenue for each tracked project, broken out to Sonic. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Sonic fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'sonic' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Sonic's share** **Work out how much of a project runs on Sonic.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/raw The standardized Sonic blocks, transactions, logs and internal calls. The `sonic` dataset holds the standardized Sonic tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-12 One row per block, with its gas and fee totals.
`transactions` 2024-12 One row per transaction, with its receipt fields on the same row.
`logs` 2024-12 One row per event log a contract emitted.
`traces` 2024-12 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `sonic.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `sonic.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x29219dd400f2bf60e5a23d13be72b486d4038894' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/real-world-assets Tokenized stocks, funds and commodities issued on Sonic, tracked against their underlying instruments. Sonic real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/sonic/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Sonic deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Sonic by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'sonic' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Sonic tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'sonic' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/stablecoins Every stablecoin issued on Sonic: supply, holders and transfers. Sonic stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/sonic/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Sonic by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'sonic' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Sonic.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x29219dd400f2bf60e5a23d13be72b486d4038894-sonic' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x29219dd400f2bf60e5a23d13be72b486d4038894-sonic' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/sonic/tokens Sonic token transfers, holder balances and daily prices. Four surfaces cover token activity on Sonic. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/sonic/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'sonic' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Sonic tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'sonic' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'sonic' and movements.token_address = '0x29219dd400f2bf60e5a23d13be72b486d4038894' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Sonic token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'sonic', '0x29219dd400f2bf60e5a23d13be72b486d4038894', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'sonic', '0x29219dd400f2bf60e5a23d13be72b486d4038894', 'erc20' ) where account_address = '0x000000009b6fd387e7fac6ca56ced4b1def65608' order by balance_date desc limit 20 ``` **Daily price** **Read one Sonic token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x29219dd400f2bf60e5a23d13be72b486d4038894-sonic' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/story/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Story table resolves to a name. # Story Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/story/index Everything the catalog holds for Story, from raw blocks to project activity. The chain's own record is queryable for Story, with its eligible catalog layers above it. The chain's own record sits in the `story` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Story rows are selected with `chain_id = 'story'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Story. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/story/raw) 2025-01 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/story/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/story/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `story` wherever a catalog table has a chain column, so the same filter selects Story everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `story.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/story/raw The standardized Story blocks, transactions, logs and internal calls. The `story` dataset holds the standardized Story tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-01 One row per block, with its gas and fee totals.
`transactions` 2025-01 One row per transaction, with its receipt fields on the same row.
`logs` 2025-01 One row per event log a contract emitted.
`traces` 2025-01 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `story.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `story.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/story/tokens Story token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/superseed/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any Superseed table resolves to a name. # Superseed Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/superseed/index Everything the catalog holds for Superseed, from raw blocks to project activity. The chain's own record is queryable for Superseed, with its eligible catalog layers above it. The chain's own record sits in the `superseed` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Superseed rows are selected with `chain_id = 'superseed'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Superseed. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/superseed/raw) 2024-09 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/superseed/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/superseed/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
## Filtering `chain_id` reads `superseed` wherever a catalog table has a chain column, so the same filter selects Superseed everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `superseed.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/superseed/raw The standardized Superseed blocks, transactions, logs and internal calls. The `superseed` dataset holds the standardized Superseed tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-09 One row per block, with its gas and fee totals.
`transactions` 2024-09 One row per transaction, with its receipt fields on the same row.
`logs` 2024-09 One row per event log a contract emitted.
`traces` 2024-09 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `superseed.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `superseed.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/superseed/tokens Superseed token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Tempo that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Tempo table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Tempo.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'tempo' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Tempo.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'tempo' and project_id = 'circle' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Tempo.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'tempo' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/assets Every curated asset issued on Tempo, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Tempo holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/tempo/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/tempo/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Tempo by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'tempo' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Tempo deployments by asset kind, and how many were issued on Tempo itself.** A deployment is native when the issuer minted the token on Tempo, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'tempo' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Tempo deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x20c000000000000000000000b9537d11c60e8b50-tempo' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x20c000000000000000000000b9537d11c60e8b50-tempo' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/bridges Cross-chain transfers that left Tempo or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'tempo'` for transfers leaving Tempo, `destination_chain_id = 'tempo'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Tempo with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'tempo', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'tempo', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'tempo' or destination_chain_id = 'tempo') group by day order by day ``` **Where value went** **Find where the value leaving Tempo went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'tempo' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Tempo value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'tempo') as leaving, countif(transfers.destination_chain_id = 'tempo') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'tempo' or transfers.destination_chain_id = 'tempo') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/contracts Every contract deployed on Tempo, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Tempo, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Tempo contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'tempo' and contract_address = '0x690f0ed7809d0227428984c0e7ee00248d0e1ee0' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'tempo' and creator_address = '0x29307f6e3a6fa83fb61b5b90a1ad00ec6eaa8f6b' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Tempo.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'tempo' and contracts.first_deployed_at >= timestamp('2026-01-01') order by contracts.first_deployed_at desc limit 100 ``` # Tempo Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/index Everything the catalog holds for Tempo, from raw blocks to project activity. Most of the catalog is queryable for Tempo, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `tempo` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Tempo rows are selected with `chain_id = 'tempo'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Tempo. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/tempo/raw) 2026-01 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/tempo/projects) 2026-01 Daily Fees and Revenue for each tracked project, broken out to Tempo.
[Assets](/docs/catalog/chain-verticals/evm/tempo/assets) 2024-01 Every curated asset issued on Tempo, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/tempo/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/tempo/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/tempo/contracts) 2026-01 Every contract deployed on Tempo, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/tempo/stablecoins) 2026-01 Every stablecoin issued on Tempo: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/tempo/real-world-assets) 2024-01 Tokenized stocks, funds and commodities issued on Tempo, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/tempo/bridges) 2026-03 Cross-chain transfers that left Tempo or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `tempo` wherever a catalog table has a chain column, so the same filter selects Tempo everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'tempo' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/projects Daily Fees and Revenue for each tracked project, broken out to Tempo. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Tempo fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'tempo' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Tempo's share** **Work out how much of a project runs on Tempo.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/raw The standardized Tempo blocks, transactions, logs and internal calls. The `tempo` dataset holds the standardized Tempo tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2026-01 One row per block, with its gas and fee totals.
`transactions` 2026-01 One row per transaction, with its receipt fields on the same row.
`logs` 2026-01 One row per event log a contract emitted.
`traces` 2026-01 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `tempo.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `tempo.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x20c000000000000000000000b9537d11c60e8b50' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/real-world-assets Tokenized stocks, funds and commodities issued on Tempo, tracked against their underlying instruments. Tempo real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/tempo/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Tempo deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Tempo by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'tempo' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Tempo tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'tempo' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/stablecoins Every stablecoin issued on Tempo: supply, holders and transfers. Tempo stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/tempo/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Tempo by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'tempo' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Tempo.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x20c000000000000000000000b9537d11c60e8b50-tempo' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x20c000000000000000000000b9537d11c60e8b50-tempo' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/tempo/tokens Tempo token transfers, holder balances and daily prices. Four surfaces cover token activity on Tempo. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/tempo/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'tempo' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Tempo tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'tempo' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'tempo' and movements.token_address = '0x20c000000000000000000000b9537d11c60e8b50' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Tempo token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'tempo', '0x20c000000000000000000000b9537d11c60e8b50', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'tempo', '0x20c000000000000000000000b9537d11c60e8b50', 'erc20' ) where account_address = '0xfeec000000000000000000000000000000000000' order by balance_date desc limit 20 ``` **Daily price** **Read one Tempo token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x20c000000000000000000000b9537d11c60e8b50-tempo' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Unichain that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Unichain table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Unichain.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'unichain' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Unichain.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'unichain' and project_id = 'euler' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Unichain.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'unichain' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Unichain. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/unichain/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Unichain for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/unichain/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/unichain/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Unichain** **Rank the apps active on Unichain by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'unichain' group by apps.name order by trading_volume desc ``` **Unichain's share** **Work out how much of one app runs on Unichain.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/assets Every curated asset issued on Unichain, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what Unichain holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/unichain/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/unichain/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Unichain by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'unichain' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Unichain deployments by asset kind, and how many were issued on Unichain itself.** A deployment is native when the issuer minted the token on Unichain, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'unichain' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Unichain deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x078d782b760474a361dda0af3839290b0ef57ad6-unichain' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x078d782b760474a361dda0af3839290b0ef57ad6-unichain' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/bridges Cross-chain transfers that left Unichain or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'unichain'` for transfers leaving Unichain, `destination_chain_id = 'unichain'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Unichain with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'unichain', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'unichain', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'unichain' or destination_chain_id = 'unichain') group by day order by day ``` **Where value went** **Find where the value leaving Unichain went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'unichain' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Unichain value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'unichain') as leaving, countif(transfers.destination_chain_id = 'unichain') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'unichain' or transfers.destination_chain_id = 'unichain') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/contracts Every contract deployed on Unichain, with the account that created it. `dimensions.contracts` holds one row per contract deployed on Unichain, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one Unichain contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'unichain' and contract_address = '0x186d68d0ac30de0d5be761f490053d7ac78493af' ``` **A factory's output** **List the contracts one factory created.** The Uniswap factory calls `CREATE` for every pool it deploys, so `creator_address` returns the pool list. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'unichain' and creator_address = '0x1f98400000000000000000000000000000000002' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on Unichain.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'unichain' and contracts.first_deployed_at >= timestamp('2025-02-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/dex Unichain trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. Unichain pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Unichain pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'unichain' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Unichain, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'unichain' group by dex_pair_id order by trading_volume desc limit 20 ``` # Unichain Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/index Everything the catalog holds for Unichain, from raw blocks to project activity. Most of the catalog is queryable for Unichain, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `unichain` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Unichain rows are selected with `chain_id = 'unichain'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Unichain. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/unichain/raw) 2024-11 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/unichain/projects) 2024-11 Daily Fees and Revenue for each tracked project, broken out to Unichain.
[Apps](/docs/catalog/chain-verticals/evm/unichain/apps) 2025-02 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Unichain.
[Assets](/docs/catalog/chain-verticals/evm/unichain/assets) 2024-09 Every curated asset issued on Unichain, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/unichain/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/unichain/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/unichain/contracts) 2025-02 Every contract deployed on Unichain, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/unichain/stablecoins) 2024-11 Every stablecoin issued on Unichain: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/unichain/real-world-assets) 2024-09 Tokenized stocks, funds and commodities issued on Unichain, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/unichain/dex) 2025-01 Trading pools, their daily volume, value locked and fees.
[Bridges](/docs/catalog/chain-verticals/evm/unichain/bridges) 2024-12 Cross-chain transfers that left Unichain or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `unichain` wherever a catalog table has a chain column, so the same filter selects Unichain everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'unichain' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/projects Daily Fees and Revenue for each tracked project, broken out to Unichain. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on Unichain sit on [Apps](/docs/catalog/chain-verticals/evm/unichain/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Unichain fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'unichain' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Unichain's share** **Work out how much of a project runs on Unichain.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/raw The standardized Unichain blocks, transactions, logs and internal calls. The `unichain` dataset holds the standardized Unichain tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-11 One row per block, with its gas and fee totals.
`transactions` 2024-11 One row per transaction, with its receipt fields on the same row.
`logs` 2024-11 One row per event log a contract emitted.
`traces` 2024-11 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `unichain.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `unichain.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x078d782b760474a361dda0af3839290b0ef57ad6' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/real-world-assets Tokenized stocks, funds and commodities issued on Unichain, tracked against their underlying instruments. Unichain real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/unichain/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its Unichain deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Unichain by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'unichain' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Unichain tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'unichain' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/stablecoins Every stablecoin issued on Unichain: supply, holders and transfers. Unichain stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/unichain/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Unichain by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'unichain' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Unichain.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x078d782b760474a361dda0af3839290b0ef57ad6-unichain' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x078d782b760474a361dda0af3839290b0ef57ad6-unichain' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/unichain/tokens Unichain token transfers, holder balances and daily prices. Four surfaces cover token activity on Unichain. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/unichain/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'unichain' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Unichain tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'unichain' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'unichain' and movements.token_address = '0x078d782b760474a361dda0af3839290b0ef57ad6' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Unichain token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'unichain', '0x078d782b760474a361dda0af3839290b0ef57ad6', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'unichain', '0x078d782b760474a361dda0af3839290b0ef57ad6', 'erc20' ) where account_address = '0x1f98400000000000000000000000000000000004' order by balance_date desc limit 20 ``` **Daily price** **Read one Unichain token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x078d782b760474a361dda0af3839290b0ef57ad6-unichain' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/viction/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on Viction that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any Viction table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Viction.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'viction' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Viction.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'viction' and project_id = 'dagora' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on Viction.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'viction' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/viction/bridges Cross-chain transfers that left Viction or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'viction'` for transfers leaving Viction, `destination_chain_id = 'viction'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Viction with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'viction', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'viction', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'viction' or destination_chain_id = 'viction') group by day order by day ``` **Where value went** **Find where the value leaving Viction went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'viction' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Viction value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'viction') as leaving, countif(transfers.destination_chain_id = 'viction') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'viction' or transfers.destination_chain_id = 'viction') group by apps.name order by volume_usd desc ``` # Viction Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/viction/index Everything the catalog holds for Viction, from raw blocks to project activity. The chain's own record is queryable for Viction, with its eligible catalog layers above it. The chain's own record sits in the `viction` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Viction rows are selected with `chain_id = 'viction'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Viction. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/viction/raw) 2018-12 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/viction/projects) 2018-12 Daily Fees and Revenue for each tracked project, broken out to Viction.
[Tokens](/docs/catalog/chain-verticals/evm/viction/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/viction/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Bridges](/docs/catalog/chain-verticals/evm/viction/bridges) 2023-10 Cross-chain transfers that left Viction or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `viction` wherever a catalog table has a chain column, so the same filter selects Viction everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `viction.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/viction/projects Daily Fees and Revenue for each tracked project, broken out to Viction. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Viction fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'viction' and daily.project_id = 'uniswap' order by daily.timestamp ``` **Viction's share** **Work out how much of a project runs on Viction.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/viction/raw The standardized Viction blocks, transactions, logs and internal calls. The `viction` dataset holds the standardized Viction tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2018-12 One row per block, with its gas and fee totals.
`transactions` 2018-12 One row per transaction, with its receipt fields on the same row.
`logs` 2018-12 One row per event log a contract emitted.
`traces` 2018-12 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `viction.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `viction.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xba73e59f11597c1c13b0d9114688efb6a6d430f6' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/viction/tokens Viction token transfers, holder balances and daily prices. Four surfaces cover token activity on Viction. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/assets/registry) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'viction' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest Viction tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'viction' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'viction' and movements.token_address = '0xba73e59f11597c1c13b0d9114688efb6a6d430f6' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Viction token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'viction', '0xba73e59f11597c1c13b0d9114688efb6a6d430f6', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'viction', '0xba73e59f11597c1c13b0d9114688efb6a6d430f6', 'erc20' ) where account_address = '0xcb7d4b81b965535c373d8edd8685ce016a2491f7' order by balance_date desc limit 20 ``` **Daily price** **Read one Viction token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xba73e59f11597c1c13b0d9114688efb6a6d430f6-viction' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on World Chain that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any World Chain table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on World Chain.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'worldchain' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on World Chain.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'worldchain' and project_id = 'circle' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on World Chain.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'worldchain' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/assets Every curated asset issued on World Chain, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what World Chain holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/worldchain/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/worldchain/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on World Chain by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'worldchain' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count World Chain deployments by asset kind, and how many were issued on World Chain itself.** A deployment is native when the issuer minted the token on World Chain, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'worldchain' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one World Chain deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x79a02482a880bce3f13e09da970dc34db4cd24d1-worldchain' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x79a02482a880bce3f13e09da970dc34db4cd24d1-worldchain' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/bridges Cross-chain transfers that left World Chain or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'worldchain'` for transfers leaving World Chain, `destination_chain_id = 'worldchain'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving World Chain with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'worldchain', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'worldchain', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'worldchain' or destination_chain_id = 'worldchain') group by day order by day ``` **Where value went** **Find where the value leaving World Chain went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'worldchain' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the World Chain value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'worldchain') as leaving, countif(transfers.destination_chain_id = 'worldchain') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'worldchain' or transfers.destination_chain_id = 'worldchain') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/contracts Every contract deployed on World Chain, with the account that created it. `dimensions.contracts` holds one row per contract deployed on World Chain, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one World Chain contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'worldchain' and contract_address = '0x95d5fe4b509691112ed6306d4cd84009a02db192' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'worldchain' and creator_address = '0x3e4fa78156285e888d8f2d3ae089c362929b14e8' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on World Chain.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'worldchain' and contracts.first_deployed_at >= timestamp('2024-06-01') order by contracts.first_deployed_at desc limit 100 ``` # World Chain Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/index Everything the catalog holds for World Chain, from raw blocks to project activity. Most of the catalog is queryable for World Chain, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `worldchain` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the World Chain rows are selected with `chain_id = 'worldchain'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on World Chain. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/worldchain/raw) 2024-06 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/worldchain/projects) 2024-06 Daily Fees and Revenue for each tracked project, broken out to World Chain.
[Assets](/docs/catalog/chain-verticals/evm/worldchain/assets) 2024-08 Every curated asset issued on World Chain, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/worldchain/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/worldchain/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/worldchain/contracts) 2024-06 Every contract deployed on World Chain, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/worldchain/stablecoins) 2024-08 Every stablecoin issued on World Chain: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/worldchain/real-world-assets) 2025-06 Tokenized stocks, funds and commodities issued on World Chain, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/worldchain/bridges) 2025-06 Cross-chain transfers that left World Chain or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `worldchain` wherever a catalog table has a chain column, so the same filter selects World Chain everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'worldchain' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/projects Daily Fees and Revenue for each tracked project, broken out to World Chain. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily World Chain fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'worldchain' and daily.project_id = 'uniswap' order by daily.timestamp ``` **World Chain's share** **Work out how much of a project runs on World Chain.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/raw The standardized World Chain blocks, transactions, logs and internal calls. The `worldchain` dataset holds the standardized World Chain tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-06 One row per block, with its gas and fee totals.
`transactions` 2024-06 One row per transaction, with its receipt fields on the same row.
`logs` 2024-06 One row per event log a contract emitted.
`traces` 2024-06 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `worldchain.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `worldchain.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x79a02482a880bce3f13e09da970dc34db4cd24d1' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/real-world-assets Tokenized stocks, funds and commodities issued on World Chain, tracked against their underlying instruments. World Chain real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/worldchain/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its World Chain deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on World Chain by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'worldchain' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List World Chain tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'worldchain' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/stablecoins Every stablecoin issued on World Chain: supply, holders and transfers. World Chain stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/worldchain/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on World Chain by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'worldchain' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on World Chain.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x79a02482a880bce3f13e09da970dc34db4cd24d1-worldchain' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x79a02482a880bce3f13e09da970dc34db4cd24d1-worldchain' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldchain/tokens World Chain token transfers, holder balances and daily prices. Four surfaces cover token activity on World Chain. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/worldchain/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'worldchain' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest World Chain tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'worldchain' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'worldchain' and movements.token_address = '0x79a02482a880bce3f13e09da970dc34db4cd24d1' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one World Chain token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'worldchain', '0x79a02482a880bce3f13e09da970dc34db4cd24d1', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'worldchain', '0x79a02482a880bce3f13e09da970dc34db4cd24d1', 'erc20' ) where account_address = '0x1072a0a713a23a2da9bab99e9cd68187970e89a4' order by balance_date desc limit 20 ``` **Daily price** **Read one World Chain token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x79a02482a880bce3f13e09da970dc34db4cd24d1-worldchain' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldmobilechain/accounts Wallets and contracts labeled with the projects that own them. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool. The accounts registry labels each one with the project that owns it, so a raw address in any World Mobile Chain table resolves to a name. # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldmobilechain/contracts Every contract deployed on World Mobile Chain, with the account that created it. `dimensions.contracts` holds one row per contract deployed on World Mobile Chain, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one World Mobile Chain contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'worldmobilechain' and contract_address = '0x7bbdb7324828f6022f2ed20354fdbe68bd41dc1e' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'worldmobilechain' and creator_address = '0x91474c5f4b01f90a50711e196bb6b8e29fb9052e' order by first_deployed_at limit 100 ``` **Newest contracts** **The newest contracts on World Mobile Chain.** Ordering on `first_deployed_at` returns the latest deployments first. ```sql theme={null} select contract_address, first_deployed_at, deployer_address from `dimensions.contracts` where chain_id = 'worldmobilechain' order by first_deployed_at desc limit 100 ``` # World Mobile Chain Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldmobilechain/index Everything the catalog holds for World Mobile Chain, from raw blocks to project activity. The chain's own record is queryable for World Mobile Chain, with its eligible catalog layers above it. The chain's own record sits in the `worldmobilechain` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the World Mobile Chain rows are selected with `chain_id = 'worldmobilechain'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on World Mobile Chain. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/worldmobilechain/raw) 2025-06 Blocks, transactions, logs and internal calls.
[Tokens](/docs/catalog/chain-verticals/evm/worldmobilechain/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/worldmobilechain/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/worldmobilechain/contracts) 2025-06 Every contract deployed on World Mobile Chain, with the account that created it.
## Filtering `chain_id` reads `worldmobilechain` wherever a catalog table has a chain column, so the same filter selects World Mobile Chain everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select block_timestamp, transaction_hash, from_address, to_address from `worldmobilechain.transactions` where block_timestamp >= timestamp('2026-08-01') and block_timestamp < timestamp('2026-08-02') limit 100 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldmobilechain/raw The standardized World Mobile Chain blocks, transactions, logs and internal calls. The `worldmobilechain` dataset holds the standardized World Mobile Chain tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2025-06 One row per block, with its gas and fee totals.
`transactions` 2025-06 One row per transaction, with its receipt fields on the same row.
`logs` 2025-06 One row per event log a contract emitted.
`traces` 2025-06 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `worldmobilechain.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `worldmobilechain.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x0000000000000000000000000000000000000000' ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/worldmobilechain/tokens World Mobile Chain token transfers, holder balances and daily prices. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on XDC that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any XDC table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on XDC.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'xdc' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on XDC.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'xdc' and project_id = 'primenumbers' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on XDC.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'xdc' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/assets Every curated asset issued on XDC, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what XDC holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/xdc/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/xdc/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on XDC by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'xdc' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count XDC deployments by asset kind, and how many were issued on XDC itself.** A deployment is native when the issuer minted the token on XDC, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'xdc' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one XDC deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xfa2958cb79b0491cc627c1557f441ef849ca8eb1-xdc' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xfa2958cb79b0491cc627c1557f441ef849ca8eb1-xdc' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/bridges Cross-chain transfers that left XDC or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'xdc'` for transfers leaving XDC, `destination_chain_id = 'xdc'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving XDC with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'xdc', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'xdc', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'xdc' or destination_chain_id = 'xdc') group by day order by day ``` **Where value went** **Find where the value leaving XDC went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'xdc' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the XDC value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'xdc') as leaving, countif(transfers.destination_chain_id = 'xdc') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'xdc' or transfers.destination_chain_id = 'xdc') group by apps.name order by volume_usd desc ``` # XDC Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/index Everything the catalog holds for XDC, from raw blocks to project activity. Most of the catalog is queryable for XDC, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `xdc` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the XDC rows are selected with `chain_id = 'xdc'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on XDC. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/xdc/raw) 2019-05 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/xdc/projects) 2019-05 Daily Fees and Revenue for each tracked project, broken out to XDC.
[Assets](/docs/catalog/chain-verticals/evm/xdc/assets) 2022-04 Every curated asset issued on XDC, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/xdc/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/xdc/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Stablecoins](/docs/catalog/chain-verticals/evm/xdc/stablecoins) 2022-10 Every stablecoin issued on XDC: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/xdc/real-world-assets) 2022-04 Tokenized stocks, funds and commodities issued on XDC, tracked against their underlying instruments.
[Bridges](/docs/catalog/chain-verticals/evm/xdc/bridges) 2025-02 Cross-chain transfers that left XDC or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `xdc` wherever a catalog table has a chain column, so the same filter selects XDC everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'xdc' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/projects Daily Fees and Revenue for each tracked project, broken out to XDC. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily XDC fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'xdc' and daily.project_id = 'uniswap' order by daily.timestamp ``` **XDC's share** **Work out how much of a project runs on XDC.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/raw The standardized XDC blocks, transactions, logs and internal calls. The `xdc` dataset holds the standardized XDC tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2019-05 One row per block, with its gas and fee totals.
`transactions` 2019-05 One row per transaction, with its receipt fields on the same row.
`logs` 2019-05 One row per event log a contract emitted.
`traces` 2019-05 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `xdc.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `xdc.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0xfa2958cb79b0491cc627c1557f441ef849ca8eb1' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/real-world-assets Tokenized stocks, funds and commodities issued on XDC, tracked against their underlying instruments. XDC real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/xdc/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its XDC deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on XDC by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'xdc' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List XDC tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'xdc' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/stablecoins Every stablecoin issued on XDC: supply, holders and transfers. XDC stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/xdc/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on XDC by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'xdc' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on XDC.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0xfa2958cb79b0491cc627c1557f441ef849ca8eb1-xdc' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0xfa2958cb79b0491cc627c1557f441ef849ca8eb1-xdc' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xdc/tokens XDC token transfers, holder balances and daily prices. Four surfaces cover token activity on XDC. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/xdc/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'xdc' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest XDC tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'xdc' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'xdc' and movements.token_address = '0xfa2958cb79b0491cc627c1557f441ef849ca8eb1' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one XDC token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'xdc', '0xfa2958cb79b0491cc627c1557f441ef849ca8eb1', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'xdc', '0xfa2958cb79b0491cc627c1557f441ef849ca8eb1', 'erc20' ) where account_address = '0x61b7b0009fced05695ee811b7f8f78ba37c38344' order by balance_date desc limit 20 ``` **Daily price** **Read one XDC token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0xfa2958cb79b0491cc627c1557f441ef849ca8eb1-xdc' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on X Layer that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any X Layer table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on X Layer.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'xlayer' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on X Layer.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'xlayer' and project_id = 'xstocks' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on X Layer.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'xlayer' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/assets Every curated asset issued on X Layer, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what X Layer holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). [Stablecoins](/docs/catalog/chain-verticals/evm/xlayer/stablecoins) scopes this layer further. ## Sample queries **Largest assets** **Rank the assets on X Layer by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'xlayer' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count X Layer deployments by asset kind, and how many were issued on X Layer itself.** A deployment is native when the issuer minted the token on X Layer, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'xlayer' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one X Layer deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x74b7f16337b8972027f6196a17a631ac6de26d22-xlayer' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x74b7f16337b8972027f6196a17a631ac6de26d22-xlayer' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/bridges Cross-chain transfers that left X Layer or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'xlayer'` for transfers leaving X Layer, `destination_chain_id = 'xlayer'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving X Layer with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'xlayer', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'xlayer', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'xlayer' or destination_chain_id = 'xlayer') group by day order by day ``` **Where value went** **Find where the value leaving X Layer went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'xlayer' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the X Layer value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'xlayer') as leaving, countif(transfers.destination_chain_id = 'xlayer') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'xlayer' or transfers.destination_chain_id = 'xlayer') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/contracts Every contract deployed on X Layer, with the account that created it. `dimensions.contracts` holds one row per contract deployed on X Layer, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one X Layer contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'xlayer' and contract_address = '0xf4df97b776875f19c20869f171410088ff3aed3e' ``` **A factory's output** **List the contracts one factory created.** This factory deploys contracts in bulk, so `creator_address` returns its output. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'xlayer' and creator_address = '0x5c328f3b5f117ffc693378a2c5b16c4f80f86295' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on X Layer.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'xlayer' and contracts.first_deployed_at >= timestamp('2024-03-01') order by contracts.first_deployed_at desc limit 100 ``` # X Layer Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/index Everything the catalog holds for X Layer, from raw blocks to project activity. Most of the catalog is queryable for X Layer, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `xlayer` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the X Layer rows are selected with `chain_id = 'xlayer'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on X Layer. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/xlayer/raw) 2024-03 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/xlayer/projects) 2024-03 Daily Fees and Revenue for each tracked project, broken out to X Layer.
[Assets](/docs/catalog/chain-verticals/evm/xlayer/assets) 2024-03 Every curated asset issued on X Layer, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/xlayer/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/xlayer/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/xlayer/contracts) 2024-03 Every contract deployed on X Layer, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/xlayer/stablecoins) 2024-03 Every stablecoin issued on X Layer: supply, holders and transfers.
[Bridges](/docs/catalog/chain-verticals/evm/xlayer/bridges) 2025-10 Cross-chain transfers that left X Layer or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `xlayer` wherever a catalog table has a chain column, so the same filter selects X Layer everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'xlayer' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/projects Daily Fees and Revenue for each tracked project, broken out to X Layer. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap. * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily X Layer fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'xlayer' and daily.project_id = 'uniswap' order by daily.timestamp ``` **X Layer's share** **Work out how much of a project runs on X Layer.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/raw The standardized X Layer blocks, transactions, logs and internal calls. The `xlayer` dataset holds the standardized X Layer tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2024-03 One row per block, with its gas and fee totals.
`transactions` 2024-03 One row per transaction, with its receipt fields on the same row.
`logs` 2024-03 One row per event log a contract emitted.
`traces` 2024-03 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `xlayer.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `xlayer.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x74b7f16337b8972027f6196a17a631ac6de26d22' ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/stablecoins Every stablecoin issued on X Layer: supply, holders and transfers. X Layer stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/xlayer/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on X Layer by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'xlayer' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on X Layer.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x74b7f16337b8972027f6196a17a631ac6de26d22-xlayer' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x74b7f16337b8972027f6196a17a631ac6de26d22-xlayer' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/xlayer/tokens X Layer token transfers, holder balances and daily prices. Four surfaces cover token activity on X Layer. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/xlayer/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'xlayer' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest X Layer tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'xlayer' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'xlayer' and movements.token_address = '0x74b7f16337b8972027f6196a17a631ac6de26d22' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one X Layer token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'xlayer', '0x74b7f16337b8972027f6196a17a631ac6de26d22', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'xlayer', '0x74b7f16337b8972027f6196a17a631ac6de26d22', 'erc20' ) where account_address = '0x5698082771339b2e57da25e7da587afb602c6f82' order by balance_date desc limit 20 ``` **Daily price** **Read one X Layer token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x74b7f16337b8972027f6196a17a631ac6de26d22-xlayer' order by prices.timestamp ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/accounts Wallets and contracts labeled with the projects that own them. `dimensions.accounts` holds one row per address on ZKsync Era that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a contract, such as an exchange wallet or a Uniswap pool, and where it is labeled its row names the project that runs it, so a labeled address in any ZKsync Era table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. A labeled address reaches the table in one of two ways, and `label_source` says which. `curated` is an attribution a person authored; `factory_derived` is an address a known factory emitted, and those rows name that factory in `parent_address`. Factory output is the bulk of the labeled rows, so filter to `curated` for the set somebody has already looked at. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on ZKsync Era.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'zksyncera' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on ZKsync Era.** `contract_name` is the label the attributing project gives an address, such as `Factory` or a pool's pair. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'zksyncera' and project_id = 'tradable' and label_source = 'curated' order by contract_name limit 100 ``` **A factory's output** **Rank the factories by how many addresses they emitted on ZKsync Era.** Every factory-derived row names its factory in `parent_address`, so grouping on that column returns one row per factory. ```sql theme={null} select parent_address, project_id, count(*) as emitted from `dimensions.accounts` where chain_id = 'zksyncera' and label_source = 'factory_derived' group by parent_address, project_id order by emitted desc limit 50 ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to ZKsync Era. An app is one deployed version of a protocol that a project runs, such as `uniswap-v3`. The project level sits on [Projects](/docs/catalog/chain-verticals/evm/zksyncera/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on ZKsync Era for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/evm/zksyncera/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/evm/zksyncera/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on ZKsync Era** **Rank the apps active on ZKsync Era by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'zksyncera' group by apps.name order by trading_volume desc ``` **ZKsync Era's share** **Work out how much of one app runs on ZKsync Era.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'uniswap-v3' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/assets Every curated asset issued on ZKsync Era, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one contract address. The first query below counts what ZKsync Era holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/evm/zksyncera/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/evm/zksyncera/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on ZKsync Era by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'zksyncera' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count ZKsync Era deployments by asset kind, and how many were issued on ZKsync Era itself.** A deployment is native when the issuer minted the token on ZKsync Era, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'zksyncera' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one ZKsync Era deployment's daily supply and holders.** `asset_token_id` is the asset, the token address and the chain with dashes. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment. A bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4-zksyncera' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4-zksyncera' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/bridges Cross-chain transfers that left ZKsync Era or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'zksyncera'` for transfers leaving ZKsync Era, `destination_chain_id = 'zksyncera'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving ZKsync Era with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'zksyncera', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'zksyncera', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'zksyncera' or destination_chain_id = 'zksyncera') group by day order by day ``` **Where value went** **Find where the value leaving ZKsync Era went.** ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'zksyncera' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the ZKsync Era value they moved.** `app_id` names the bridge behind the transfer. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'zksyncera') as leaving, countif(transfers.destination_chain_id = 'zksyncera') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'zksyncera' or transfers.destination_chain_id = 'zksyncera') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/contracts Every contract deployed on ZKsync Era, with the account that created it. `dimensions.contracts` holds one row per contract deployed on ZKsync Era, keyed on `chain_id` and `contract_address`. The row describes the address's first deployment: the time it appeared, the account that signed for it, the account that called `CREATE`, and the size of the deployed bytecode. The list is everything we see onchain, which reaches far past the contracts anyone has labeled: joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** **When one ZKsync Era contract was first deployed, and by whom.** ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'zksyncera' and contract_address = '0x4e59b44847b379578588920ca78fbf26c0b4956c' ``` **A factory's output** **List the contracts one factory created.** Deployments on ZKsync Era route through the ContractDeployer system contract, so `creator_address` returns every contract on the chain; filter `deployer_address` for what one account deployed. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'zksyncera' and creator_address = '0x0000000000000000000000000000000000008006' order by first_deployed_at limit 100 ``` **Token contracts** **Date the token contracts on ZKsync Era.** Joining `dimensions.tokens` on `account_id` gives each token's symbol beside the day its contract first appeared. ```sql theme={null} select tokens.symbol, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.tokens` as tokens on tokens.token_id = contracts.account_id where contracts.chain_id = 'zksyncera' and contracts.first_deployed_at >= timestamp('2023-02-01') order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/dex ZKsync Era trading pools, their daily volume, value locked and fees. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a contract holding a reserve of two tokens that anyone can trade with. ZKsync Era pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. `fee_tier` records a pool's configurable fee level, so it is null on pools whose design fixes the fee. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume and fees are flows, so they add up: a week of daily rows sums to the week, and a set of pools sums to the group. Value locked, in `metrics_dex_pools.tvl_daily`, is a level: the latest row is the answer, and summing it across days gives a meaningless number. Every pool gets a TVL row every day it exists; volume and fee rows land only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank ZKsync Era pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'zksyncera' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.fee_tier, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on ZKsync Era, and how many pools each one trades in.** `dex_pair_id` joins the two token addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'zksyncera' group by dex_pair_id order by trading_volume desc limit 20 ``` # ZKsync Era Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/index Everything the catalog holds for ZKsync Era, from raw blocks to project activity. Most of the catalog is queryable for ZKsync Era, from the blocks themselves to the daily activity of the projects that run on it. The chain's own record sits in the `zksyncera` dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the ZKsync Era rows are selected with `chain_id = 'zksyncera'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on ZKsync Era. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/evm/zksyncera/raw) 2023-02 Blocks, transactions, logs and internal calls.
[Projects](/docs/catalog/chain-verticals/evm/zksyncera/projects) 2023-02 Daily Fees and Revenue for each tracked project, broken out to ZKsync Era.
[Apps](/docs/catalog/chain-verticals/evm/zksyncera/apps) 2023-08 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to ZKsync Era.
[Assets](/docs/catalog/chain-verticals/evm/zksyncera/assets) 2023-03 Every curated asset issued on ZKsync Era, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/evm/zksyncera/tokens) **In progress** Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/evm/zksyncera/accounts) **In progress** Wallets and contracts labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/evm/zksyncera/contracts) 2023-02 Every contract deployed on ZKsync Era, with the account that created it.
[Stablecoins](/docs/catalog/chain-verticals/evm/zksyncera/stablecoins) 2023-03 Every stablecoin issued on ZKsync Era: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/evm/zksyncera/real-world-assets) 2023-09 Tokenized stocks, funds and commodities issued on ZKsync Era, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/evm/zksyncera/dex) 2023-08 Trading pools, their daily volume, value locked and fees.
[Lending](/docs/catalog/chain-verticals/evm/zksyncera/lending) **In progress** The lending markets deployed on ZKsync Era, the asset each one lends, and the lending facts.
[Bridges](/docs/catalog/chain-verticals/evm/zksyncera/bridges) 2023-05 Cross-chain transfers that left ZKsync Era or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `zksyncera` wherever a catalog table has a chain column, so the same filter selects ZKsync Era everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, named by `source_chain_id` and `destination_chain_id`. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'zksyncera' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Lending Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/lending The lending markets deployed on ZKsync Era and the asset each one lends. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A lending protocol lets users deposit one token to earn interest and borrow another against it. The unit it works in is a market: a pool that takes deposits and lends them out. The assets inside a market are its reserves. [`dimensions.lending_markets`](/docs/catalog/lending/registry) lists the ZKsync Era markets with `chain_id = 'zksyncera'`. The reserves inside one market share collateral, so a deposit in one can back a loan in another. The lending facts land keyed to these markets, one row per event: * [Deposits](/docs/catalog/lending/deposits) **In progress** * [Withdrawals](/docs/catalog/lending/withdrawals) **In progress** * [Borrows](/docs/catalog/lending/borrows) **In progress** * [Repayments](/docs/catalog/lending/repayments) **In progress** * [Liquidations](/docs/catalog/lending/liquidations) **In progress** * [Flash loans](/docs/catalog/lending/flash-loans) **In progress** * [Interest rates](/docs/catalog/lending/interest-rates) **In progress** Every column is documented at [Lending](/docs/catalog/lending/index). ## Sample queries **Markets per app** **Count ZKsync Era markets by the app that runs them.** ```sql theme={null} select app_id, count(*) as markets from `dimensions.lending_markets` where chain_id = 'zksyncera' group by app_id order by markets desc ``` **Markets one app runs** **List the markets one app runs on ZKsync Era.** `lending_market_contract_address` is the market's own contract. ```sql theme={null} select lending_market_id, lending_market_name, lending_market_contract_address from `dimensions.lending_markets` where chain_id = 'zksyncera' and app_id = 'aave-v4' order by lending_market_name ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/projects Daily Fees and Revenue for each tracked project, broken out to ZKsync Era. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Uniswap; its apps' figures on ZKsync Era sit on [Apps](/docs/catalog/chain-verticals/evm/zksyncera/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily ZKsync Era fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'zksyncera' and daily.project_id = 'uniswap' order by daily.timestamp ``` **ZKsync Era's share** **Work out how much of a project runs on ZKsync Era.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'uniswap' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/raw The standardized ZKsync Era blocks, transactions, logs and internal calls. The `zksyncera` dataset holds the standardized ZKsync Era tables. Every column is documented at [EVM ▸ Overview](/docs/catalog/chain-verticals/evm/index). ## Tables
Table Since Description
`blocks` 2023-02 One row per block, with its gas and fee totals.
`transactions` 2023-02 One row per transaction, with its receipt fields on the same row.
`logs` 2023-02 One row per event log a contract emitted.
`traces` 2023-02 One row per internal call recorded during execution.
## Sample queries > [!WARNING] > > The partition column differs by table: `transactions`, `logs` and `traces` split on `block_timestamp`, `blocks` splits on `timestamp`. Bound the right column in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. **Daily transactions** **Count daily transactions and the accounts that sent them.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, count(distinct from_address) as senders from `zksyncera.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One contract's logs** **Count the logs one contract emitted on a single day.** A log is the record a contract writes when something happens inside it, and `address` is the contract that wrote it. ```sql theme={null} select count(*) as usdc_logs, count(distinct transaction_hash) as transactions from `zksyncera.logs` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and address = '0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/real-world-assets Tokenized stocks, funds and commodities issued on ZKsync Era, tracked against their underlying instruments. ZKsync Era real-world assets are the [Assets](/docs/catalog/chain-verticals/evm/zksyncera/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` has the daily supply and holders of its ZKsync Era deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on ZKsync Era by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'zksyncera' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List ZKsync Era tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'zksyncera' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/stablecoins Every stablecoin issued on ZKsync Era: supply, holders and transfers. ZKsync Era stablecoins are the [Assets](/docs/catalog/chain-verticals/evm/zksyncera/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` has their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on ZKsync Era by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'zksyncera' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on ZKsync Era.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4-zksyncera' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4-zksyncera' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/evm/zksyncera/tokens ZKsync Era token transfers, holder balances and daily prices. Four surfaces cover token activity on ZKsync Era. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns contracts whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/evm/zksyncera/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'zksyncera' and token_type = 'erc20' ``` **Busiest tokens** **Rank the busiest ZKsync Era tokens on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each contract. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'zksyncera' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the accounts that gained and lost the most of one token on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per account nets the day; dividing by `10^decimals` converts to token amounts. The token is named by `token_address` and `chain_id`, and those two hold the read to one token's blocks. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(movements.to_address as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'zksyncera' and movements.token_address = '0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one ZKsync Era token.** The returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'zksyncera', '0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4', 'erc20' ) order by balance desc limit 20 ``` **Balance history** **Trace one account's balance in one token over time.** The function returns a row only on the days the balance moved; the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} select balance_date, balance from `functions.calculate_historical_eod_token_balances`( 'zksyncera', '0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4', 'erc20' ) where account_address = '0x133e45b1c6d385a0226170c3418a37c637e86ca6' order by balance_date desc limit 20 ``` **Daily price** **Read one ZKsync Era token's daily price.** Each row is the midnight UTC price in USD. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = '0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4-zksyncera' order by prices.timestamp ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/hyperliquid/apps Daily Notional volume, Trading volume, Fees and Revenue for each tracked app, broken out to HyperCore. An app is one deployed version of a protocol that a project runs, such as `hyperliquid-perps` or `hyperliquid-spot`. The project level sits on [Projects](/docs/catalog/chain-verticals/hyperliquid/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on HyperCore for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: perpetual volume breaks down market by market, and spot and outcome-market volume breaks down book by book, both on [Perpetuals](/docs/catalog/chain-verticals/hyperliquid/perpetuals). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on HyperCore** **Rank the apps active on HyperCore by the fees their users paid over one week.** Fees is the measure the venue apps and the builder apps both report, so it ranks them on one scale. ```sql theme={null} select apps.name, sum(daily.fees) as fees from `metrics_apps_by_chain.fees_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'hypercore' group by apps.name order by fees desc ``` **What the venue kept** **Split one app's fees into what it retained and what it passed on.** Revenue plus supply-side fees is total fees, and on HyperCore the supply side is the builder tip plus a HIP-3 deployer's cut. ```sql theme={null} select charged.timestamp, charged.fees, retained.revenue, passed_on.fees_supply_side from `metrics_apps_by_chain.fees_daily` as charged join `metrics_apps_by_chain.revenue_daily` as retained using (timestamp, app_id, chain_id) join `metrics_apps_by_chain.fees_supply_side_daily` as passed_on using (timestamp, app_id, chain_id) where charged.timestamp >= timestamp('2026-08-16') and charged.timestamp < timestamp('2026-08-23') and charged.chain_id = 'hypercore' and charged.app_id = 'hyperliquid-perps' order by charged.timestamp ``` # Hyperliquid Source: https://tokenterminal.com/docs/catalog/chain-verticals/hyperliquid/index Everything the catalog holds for HyperCore, from the raw exchange streams to the markets that trade on it. Hyperliquid runs two chains. HyperCore is the exchange itself: the matching engine, the perpetual markets and the spot order books, keyed `chain_id = 'hypercore'`. HyperEVM is its general-purpose EVM chain, keyed `chain_id = 'hyperevm'`, and it has its own section at [HyperEVM](/docs/catalog/chain-verticals/evm/hyperevm). This section covers HyperCore. The chain's own record sits in the `hypercore` dataset: one row per block, fill, order, book change and funding settlement. Everything above that sits in the catalog, where the HyperCore rows are selected with `chain_id = 'hypercore'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on HyperCore. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/hyperliquid/raw) 2025-03 Blocks and the exchange streams beneath them: fills, orders, book changes, funding and TWAPs.
[Projects](/docs/catalog/chain-verticals/hyperliquid/projects) 2025-05 Daily Notional volume, Fees and Revenue for each tracked project, broken out to HyperCore.
[Apps](/docs/catalog/chain-verticals/hyperliquid/apps) 2025-05 Daily Notional volume, Trading volume, Fees and Revenue for each tracked app, broken out to HyperCore.
[Perpetuals](/docs/catalog/chain-verticals/hyperliquid/perpetuals) 2025-05 Perpetual markets and the spot and outcome-market order books, with their volume, open interest, funding and fees.
## Filtering `chain_id` reads `hypercore` wherever a catalog table has a chain, so the same filter selects HyperCore everywhere. Some shapes ask for something else. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. The perpetual position and trader tables key on the market alone, so the chain comes from `dimensions.perp_markets`, as the query below does. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, markets.name, daily.open_interest from `metrics_perp_markets.open_interest_daily` as daily join `dimensions.perp_markets` as markets using (perp_market_id) where markets.chain_id = 'hypercore' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') order by daily.open_interest desc limit 100 ``` # Perpetuals Source: https://tokenterminal.com/docs/catalog/chain-verticals/hyperliquid/perpetuals HyperCore perpetual markets and order books, their volume, open interest, funding and fees. HyperCore runs two kinds of market and the Perpetuals band documents both. A perpetual market is a contract that tracks a price and never expires, such as `BTC Perpetual`. An order-book market is a cash market where the token itself changes hands through a book of resting orders, such as the `HYPE/USDC` spot book or an outcome market. Each kind has its own registry, its own daily tables and its own trade table. * [`dimensions.perp_markets`](/docs/catalog/perpetuals/registry) and [`dimensions.order_book_markets`](/docs/catalog/perpetuals/registry): one row per market. * [`metrics_perp_markets`](/docs/catalog/perpetuals/metrics) and [`metrics_order_book_markets`](/docs/catalog/perpetuals/metrics): one table per measure, one row per market per day. `metrics_perp_markets_by_token` and `metrics_order_book_markets_by_token` split a market by the token it settles or quotes in. * [`facts_perp_markets.trades`](/docs/catalog/perpetuals/trades), [`facts_perp_markets.liquidations`](/docs/catalog/perpetuals/liquidations) and [`facts_order_book_markets.trades`](/docs/catalog/perpetuals/trades): one row per fill. A perpetual market credits two apps. `exchange_app_id` is the venue whose matching engine settled the trade, and `interface_app_id` is the builder the market is listed under. The two hold the same value on a venue's own markets and differ on a builder-deployed HIP-3 market, where `hyperliquid-perps` is the engine. An order-book market runs under a single app and has one `app_id` where a perpetual market has the pair. The money tables on both kinds have `chain_id`, `project_id` and `app_id`, so a HyperCore filter reads straight off them. The perpetual position and trader tables, such as `open_interest_daily` and `funding_rate_daily`, key on `perp_market_id` alone, so filter those through `dimensions.perp_markets`. Every column is documented at [Perpetuals](/docs/catalog/perpetuals/index). ## Sample queries **Top perpetual markets** **Rank HyperCore perpetual markets by the notional settled on one day.** The exchange lens credits the matching engine, so it totals the venue's own markets and the HIP-3 markets it settles for builders in one figure. ```sql theme={null} select markets.name, markets.interface_app_id, sum(daily.notional_trading_volume) as notional_trading_volume from `metrics_perp_markets.notional_trading_volume_exchange_daily` as daily join `dimensions.perp_markets` as markets using (perp_market_id) where daily.timestamp >= timestamp('2026-08-20') and daily.timestamp < timestamp('2026-08-21') and daily.chain_id = 'hypercore' group by markets.name, markets.interface_app_id order by notional_trading_volume desc limit 20 ``` **Open interest and funding** **Follow one perpetual market's open interest and funding rate day by day.** Both tables key on `perp_market_id` alone, so the market identifier is the whole filter. ```sql theme={null} select positions.timestamp, positions.open_interest, funding.funding_rate from `metrics_perp_markets.open_interest_daily` as positions join `metrics_perp_markets.funding_rate_daily` as funding using (timestamp, perp_market_id) where positions.timestamp >= timestamp('2026-08-16') and positions.timestamp < timestamp('2026-08-23') and positions.perp_market_id = 'hlbtc-hypercore' order by positions.timestamp ``` **Top order books** **Rank the HyperCore order books by the value traded over one week.** Every book here quotes in a dollar stablecoin, so the volume figure is already a dollar figure. ```sql theme={null} select markets.name, markets.app_id, sum(daily.trading_volume) as trading_volume from `metrics_order_book_markets.trading_volume_daily` as daily join `dimensions.order_book_markets` as markets using (order_book_market_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'hypercore' group by markets.name, markets.app_id order by trading_volume desc limit 20 ``` **HIP-3 markets** **Find the HyperCore markets a builder deployed rather than the venue, and the fees they produced.** A HIP-3 market is one where the matching engine and the listing builder are different apps, so comparing the two credit columns separates them. ```sql theme={null} select markets.name, markets.interface_app_id, sum(daily.fees) as fees from `metrics_perp_markets.fees_daily` as daily join `dimensions.perp_markets` as markets using (perp_market_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'hypercore' and markets.exchange_app_id != markets.interface_app_id group by markets.name, markets.interface_app_id order by fees desc limit 20 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/hyperliquid/projects Daily Notional volume, Fees and Revenue for each tracked project, broken out to HyperCore. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Hyperliquid itself or a builder listing its own markets; its apps' figures on HyperCore sit on [Apps](/docs/catalog/chain-verticals/hyperliquid/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Notional volume comes in two lenses. `notional_trading_volume_exchange_daily` credits the project whose matching engine settled the trade, and `notional_trading_volume_interface_daily` credits the project whose interface it was placed through. Pick one lens and stay in it. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily HyperCore fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'hypercore' and daily.project_id = 'hyperliquid' order by daily.timestamp ``` **Builders on HyperCore** **Rank the projects listing markets on HyperCore by the notional traded through their interfaces.** The interface lens is the one that separates the builders, since the matching engine behind them is the same one. ```sql theme={null} select projects.name, sum(daily.notional_trading_volume) as notional_trading_volume from `metrics_projects_by_chain.notional_trading_volume_interface_daily` as daily join `dimensions.projects` as projects using (project_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'hypercore' group by projects.name order by notional_trading_volume desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/hyperliquid/raw The standardized HyperCore blocks, fills, orders, book changes and funding settlements. The `hypercore` dataset holds the standardized HyperCore tables. HyperCore is an exchange rather than a general-purpose chain, so where an EVM chain publishes logs and internal calls, HyperCore publishes the streams its matching engine emits: what filled, what was ordered, how the book moved, and what funding was settled. ## Tables
Table Since Description
`blocks` 2025-07 One row per block, with the number of records each stream emitted in it.
`node_trades` 2025-03 One row per side of a trade, the taker's and the maker's, in a slim shape: the account, market, side, price, size and whether that side was the taker.
`node_fills` 2025-07 One row per fill, in the full shape: the fee and the token it was paid in, the builder credited, the position direction and the liquidation fields where the fill closed a position.
`node_fills_without_block_number` 2025-05 to 2025-07 The fills the node recorded before block numbers were attached to them, in the same shape as `node_fills`.
`node_funding` 2025-09 One row per market per funding settlement, with the rate it applied and the amount settled on each side.
`events` 2025-09 One row per exchange event outside trading, typed by `event_kind` and, for ledger updates, by `ledger_type`.
`orders` 2025-11 One row per order status change, with the limit price, the size, the order type and the time in force.
`book` 2025-11 One row per change to a resting order level, with the price and the level size before and after.
`twap` 2025-11 One row per state change of a TWAP order, with the size and notional executed so far, and the stop price and trigger where the order sets them.
`writer_actions` 2025-12 One row per action written into HyperCore from HyperEVM, such as a spot send or a delegation, with the EVM transaction that sent it.
Blocks are keyed on `block_number`, fills on `block_number`, `coin` and `trade_id` together with the account and side, trades on `trade_timestamp`, `coin`, `trade_id` and `is_taker` from 2025-05-25, orders and TWAPs on `order_id` and `twap_id`, and funding on the market and settlement time. `coin` is the market symbol as the venue lists it, and it is the join back to the market registries on [Perpetuals](/docs/catalog/chain-verticals/hyperliquid/perpetuals). Three columns hold JSON, because their shape depends on a type column: `event_json` in `events`, `children` in `orders` and `action` in `writer_actions`. Read the type column first, then extract the fields that type defines. ## Sample queries > [!WARNING] > > Every table splits by day on `block_timestamp`. Bound it in every query and keep it bare on the left of the comparison; wrapping it in a function reads every partition. `book` and `orders` hold every resting-order change and every order state change, so they are the two largest tables here: bound them to a single day. **Daily trading** **Count daily trades and the accounts behind them.** `node_trades` holds one row per side of a trade, and the taker row counts each trade once. It is the slim trade stream, the lowest-cost table for volume and participation questions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, countif(is_taker) as trades, count(distinct account_address) as accounts from `hypercore.node_trades` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **Busiest markets** **Rank markets by notional traded on one day, with the fees they produced.** A fill's notional is its price times its size, and both are BIGNUMERIC, so the multiplication stays exact. ```sql theme={null} select coin, count(*) as fills, sum(price * size) as notional, sum(fee) as fees from `hypercore.node_fills` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by coin order by notional desc limit 20 ``` **Funding settlements** **Read the funding paid on each market over one week.** `funding_rate` is the rate the settlement applied, and the long and short amount columns split the settled amount by the side of the position. ```sql theme={null} select coin, count(*) as settlements, avg(funding_rate) as average_rate, sum(long_funding_amount) as long_amount, sum(short_funding_amount) as short_amount from `hypercore.node_funding` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by coin order by abs(sum(total_funding_amount)) desc limit 20 ``` # Aptos Source: https://tokenterminal.com/docs/catalog/chain-verticals/move/aptos Standardized Aptos tables from the chain's 2022 mainnet launch. `aptos` holds the standardized Aptos tables, following the Aptos-style schema documented in [the family overview](/docs/catalog/chain-verticals/move/index) exactly, with no differences. The same schema applies to Movement, which uses the same tables. A **module** is a published unit of Move code, the equivalent of a contract elsewhere. A **resource** is a piece of data stored under an account, such as its balance of a particular coin; the changes tables record what a transaction wrote to those. Above the raw tables sits the rest of the catalog, and Aptos shows up in two parts of it: the list of tokens we know about with their daily prices, and the tokenized assets issued on the chain. [Real-world assets](/docs/catalog/real-world-assets/index) and [Stablecoins](/docs/catalog/stablecoins/index) cover the tokenized assets and their daily tables. [Tokens](/docs/catalog/tokens/index) covers the token list and the daily price table. ## Tables
Table Since Description
`blocks` 2022-10 One row per block, with the first and last transaction version in it.
`transactions` 2022-10 One row per transaction version, keyed on `version`.
`events` 2022-10 One row per event a transaction emitted.
`changes` 2022-10 One row per state change a transaction wrote.
`resources` 2022-10 One row per account resource write or delete.
`modules` 2022-10 One row per Move module publish or update.
`table_items` 2022-10 One row per onchain table item write or delete.
`resources`, `modules` and `table_items` are slices of `changes`: the writes that touched data stored under an account, the ones that published or upgraded code, and the ones that wrote to a contract's own key-value store. > [!WARNING] > > Every table except `blocks` splits by day on `block_timestamp`, and `blocks` on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. **blocks** A block is a batch of transactions added to the chain. Aptos also numbers every transaction it has ever run, and that number is the transaction's version, so each block covers a range of versions. `blocks` contains one row per block, with the first and last version in it.
Column Type Description
`timestamp` TIMESTAMP The time the block was produced. Partition column.
`block_height` INT64 The block height.
`first_version` STRING The first transaction version in the block.
`last_version` STRING The last transaction version in the block.
`block_hash` STRING The hash of the block.
**Daily blocks and version range** **Count blocks per day and the version range they cover.** ```sql theme={null} select date(timestamp) as day, count(*) as blocks, min(first_version) as first_version, max(last_version) as last_version from `aptos.blocks` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') group by day ``` **transactions** Not every transaction comes from a user: the chain writes its own bookkeeping entries into the same numbered sequence. `transactions` contains one row per transaction, identified by its version number, whichever kind it is: a user transaction, a block metadata entry, or a state checkpoint. The `type` column says which.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing block. Partition column.
`block_height` INT64 The height of the containing block.
`hash` STRING The hash of the transaction.
`timestamp` STRING The onchain transaction timestamp, in microseconds.
`accumulator_root_hash` STRING The accumulator root hash after the transaction.
`epoch` STRING The epoch of the transaction.
`event_root_hash` STRING The root hash of the transaction's events.
`expiration_timestamp_secs` STRING The expiration time set by the sender, in seconds.
`failed_proposer_indices` ARRAY\ The indices of proposers that failed in the round.
`gas_unit_price` STRING The gas unit price, in octas.
`gas_used` STRING The gas units consumed.
`id` STRING The identifier of block metadata transactions.
`max_gas_amount` STRING The gas limit set by the sender.
`previous_block_votes_bitvec` ARRAY\ The vote bitvector for the previous block.
`proposer` STRING The proposer of the block, for block metadata transactions.
`round` STRING The consensus round.
`sender` STRING The sending account.
`sequence_number` STRING The sender's sequence number.
`state_change_hash` STRING The hash of the transaction's state changes.
`state_checkpoint_hash` STRING The state checkpoint hash, when present.
`success` BOOL Whether the transaction succeeded.
`type` STRING The transaction type, such as user or block metadata.
`version` STRING The global transaction version, the identifier used everywhere else.
`vm_status` STRING The VM execution status.
`signature_type` STRING The signature scheme used.
`signature_public_key` STRING The signing public key.
`signature` STRING The transaction signature.
`payload` JSON The full transaction payload.
`payload_function` STRING The entry function called, as address::module::function.
`payload_type` STRING The payload type.
`payload_type_arguments` JSON The generic type arguments of the call.
`payload_arguments` JSON The arguments of the call.
**Daily success rate** **Count daily Aptos transactions and their success rate over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, countif(success) as successful from `aptos.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **events** An event is a note that published code writes when something happens inside it: a transfer, a swap, a deposit. `events` contains one row per event a transaction produced.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing block. Partition column.
`block_height` INT64 The height of the containing block.
`sequence_number` STRING The sequence number of the event in its stream.
`transaction_hash` STRING The hash of the emitting transaction.
`event_type` STRING The Move type of the event.
`event_index` INT64 The position of the event within the transaction.
`event_guid_account_address` STRING The account address of the event stream.
`event_guid_creation_number` INT64 The creation number of the event stream.
`data` JSON The event payload.
**Events by type** **Count events by type on one day.** ```sql theme={null} select event_type, count(*) as events from `aptos.events` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by event_type order by events desc limit 20 ``` **changes** Everything a transaction actually altered on the chain is recorded here. `changes` contains one row per alteration, of any kind. The tables that follow are slices of this one.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing block. Partition column.
`block_height` INT64 The height of the containing block.
`transaction_hash` STRING The hash of the writing transaction.
`changes_index` INT64 The position of the change within the transaction.
`changes_type` STRING The change type, such as write resource or delete resource.
`changes_address` STRING The account address the change applies to.
`data_type` STRING The Move type of the changed data.
`data` JSON The changed data.
`changes` JSON The raw change record.
**Changes by type** **Count changes by type on one day.** ```sql theme={null} select changes_type, count(*) as changes from `aptos.changes` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by changes_type order by changes desc ``` **resources** `resources` is the part of `changes` that touched data stored under an account, a coin balance for instance. One row per write or delete.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing block. Partition column.
`block_height` INT64 The height of the containing block.
`transaction_hash` STRING The hash of the writing transaction.
`changes_type` STRING The change type.
`changes_index` INT64 The position of the change within the transaction.
`changes_address` STRING The account address the change applies to.
`resource_address` STRING The address of the resource.
`data` JSON The resource contents after the change.
`data_type` STRING The Move type of the resource.
`state_key_hash` STRING The state key hash of the resource slot.
**Most-written resource types** **Rank resource types by writes on one day.** ```sql theme={null} select data_type, count(*) as writes from `aptos.resources` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by data_type order by writes desc limit 20 ``` **modules** `modules` contains one row per time Move code was published or upgraded, along with the functions and data types that code exposes.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing block. Partition column.
`block_height` INT64 The height of the containing block.
`transaction_hash` STRING The hash of the publishing transaction.
`changes_type` STRING The change type.
`changes_index` INT64 The position of the change within the transaction.
`changes_address` STRING The account address the change applies to.
`module_address` STRING The address the module lives under.
`module_name` STRING The name of the module.
`exposed_functions` JSON The public functions of the module.
`friends` JSON The friend modules.
`structs` JSON The struct definitions of the module.
`bytecode` STRING The compiled module bytecode.
`state_key_hash` STRING The state key hash of the module slot.
**Daily module publishes** **Count module publishes and upgrades per day over one week.** ```sql theme={null} select date(block_timestamp) as day, count(*) as modules_published from `aptos.modules` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **table\_items** Move code can keep its own key-value store on the chain, and each entry in one is a table item. `table_items` contains one row per entry written or deleted.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing block. Partition column.
`block_height` INT64 The height of the containing block.
`transaction_hash` STRING The hash of the writing transaction.
`changes_type` STRING The change type.
`changes_index` INT64 The position of the change within the transaction.
`data` JSON The raw item record.
`handle` STRING The handle of the table.
`key` STRING The key of the item.
`value` STRING The value of the item after the change.
`state_key_hash` STRING The state key hash of the item slot.
**Daily table item writes** **Count table item writes and deletes per day over one week.** ```sql theme={null} select date(block_timestamp) as day, count(*) as items from `aptos.table_items` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` ## Sample queries **Entry functions by usage** **Rank entry functions by user transactions on one day.** ```sql theme={null} select payload_function, count(*) as transactions from `aptos.transactions` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and type = 'user_transaction' group by payload_function order by transactions desc limit 20 ``` **Tokenized assets by market cap** **Rank the tokenized assets deployed on Aptos by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'aptos' order by daily.market_cap_circulating desc limit 20 ``` **Priced tokens** **List the Aptos tokens that had a daily price over one week.** ```sql theme={null} with priced as ( select token_id, avg(price) as avg_price, count(*) as price_days from `metrics_tokens.price_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'aptos' group by token_id ) select tokens.symbol, tokens.name, priced.avg_price, priced.price_days from priced join `dimensions.tokens` as tokens using (token_id) order by priced.avg_price desc limit 20 ``` # Move ecosystem Source: https://tokenterminal.com/docs/catalog/chain-verticals/move/index Standardized tables for the Move chains Aptos, Movement and Sui. Move is the programming language these three chains run their contracts in, and that shared language is what makes them a family. They record what a transaction changed in two different ways, so their tables come in two shapes. Aptos and Movement list the changes themselves, in `blocks`, `transactions`, `events`, `changes`, `resources`, `modules` and `table_items`. Sui treats everything on the chain as an object with an owner and records the objects a transaction touched, in `blocks`, `transactions`, `events`, `move_calls`, `move_packages`, `objects`, `transaction_objects` and `wrapped_objects`. The [Tables](#tables) section below says which tables each shape has and where their columns are documented. ## Chains
Chain `chain_id` blocks transactions events
Aptos `aptos` ✓ ✓ ✓
Movement `movement` ✓ ✓ ✓
Sui `sui` ✓ ✓ ✓
## Tables All three chains have `blocks`, `transactions` and `events`: the blocks the network agreed on, the transactions inside them, and the notes the chain wrote while running each one. On top of those, each shape adds tables of its own. The Aptos shape adds `changes`, `resources`, `modules` and `table_items`, which record what a transaction wrote. Its columns are documented on the [Aptos](/docs/catalog/chain-verticals/move/aptos) page, and Movement uses those same tables exactly. The Sui shape adds `move_calls`, `move_packages`, `objects`, `transaction_objects` and `wrapped_objects`, which record the objects a transaction touched and the code it called. Its columns are documented on the [Sui](/docs/catalog/chain-verticals/move/sui) page. > [!WARNING] > > On both shapes every table except `blocks` splits by day on `block_timestamp`, and `blocks` on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ## Exceptions Sui is where the family splits, and it splits because the chain itself works differently. * Sui's `blocks` rows are checkpoints, the groups it batches transactions into, rather than blocks in the usual sense. * Sui's `transactions` and `events` hold gas costs and execution effects where the Aptos ones hold Move-style changes. * Sui's object tables stand in for the Aptos change tables: `objects`, `transaction_objects` and `wrapped_objects` record every version of every object a transaction touched. # Sui Source: https://tokenterminal.com/docs/catalog/chain-verticals/move/sui Standardized Sui tables, built around checkpoints and object versions. `sui` holds the standardized Sui tables, following the Sui schema documented in [the family overview](/docs/catalog/chain-verticals/move/index). Sui treats everything on the chain as an object with an owner, which sets it apart from the other Move chains. Its `blocks` rows are checkpoints, the groups it batches transactions into, rather than blocks in the usual sense. The `objects`, `transaction_objects` and `wrapped_objects` tables record every version of every object a transaction touched. Above the raw tables sits the rest of the catalog, and Sui shows up in two parts of it: the list of tokens we know about with their daily prices, and the tokenized assets issued on the chain. [Tokens](/docs/catalog/tokens/index) covers the token list and the daily price table. [Real-world assets](/docs/catalog/real-world-assets/index) and [Stablecoins](/docs/catalog/stablecoins/index) cover the tokenized assets and their daily tables. ## Tables
Table Since Description
`blocks` 2023-05 One row per checkpoint.
`transactions` 2023-05 One row per transaction, with its gas costs and effects attached.
`events` 2023-05 One row per event a transaction emitted.
`move_calls` 2023-05 One row per Move call command a transaction executed.
`move_packages` 2023-05 One row per package version published on chain.
`objects` 2023-04 One row per object version a transaction wrote, with the object contents.
`transaction_objects` 2023-05 One row per object a transaction touched, without the contents.
`wrapped_objects` 2023-05 One row per object wrapped inside another object.
`objects` starts a few weeks earlier than the rest, on 2023-04-12. Use `transaction_objects` when the question is which objects a transaction touched, and `objects` when what was in them matters. > [!WARNING] > > Every table except `blocks` splits by day on `block_timestamp`, and `blocks` on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. **blocks** Sui groups its transactions into checkpoints rather than blocks, and a checkpoint is what this table holds. `blocks` contains one row per checkpoint.
Column Type Description
`timestamp` TIMESTAMP The time of the checkpoint. Partition column.
`number` INT64 The checkpoint sequence number.
`digest` STRING The digest of the checkpoint.
`previous_digest` STRING The digest of the previous checkpoint.
`epoch` STRING The epoch of the checkpoint.
`network_total_transactions` INT64 The cumulative network transaction count at the checkpoint.
`timestamp_ms` STRING The checkpoint timestamp, in milliseconds.
`sequence_number` STRING The checkpoint sequence number as a string.
`validator_signature` STRING The combined signature of the validators that approved the checkpoint.
`transaction_count` INT64 The number of transactions in the checkpoint.
**Daily checkpoints and transactions** **Count checkpoints and the transactions in them per day.** ```sql theme={null} select date(timestamp) as day, count(*) as checkpoints, sum(transaction_count) as transactions from `sui.blocks` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') group by day ``` **transactions** `transactions` contains one row per transaction, with what it cost to run and its effects, the chain's own record of everything the transaction changed, attached to the row.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing checkpoint. Partition column.
`block_number` INT64 The sequence number of the containing checkpoint.
`digest` STRING The digest of the transaction, the identifier used everywhere else.
`checkpoint` STRING The checkpoint sequence number as a string.
`timestamp_ms` STRING The transaction timestamp, in milliseconds.
`sender` STRING The sending address.
`transaction_kind` STRING The transaction kind, such as programmable transaction.
`is_system_txn` BOOL Whether the transaction is a system transaction.
`is_sponsored_tx` BOOL Whether the gas was paid by a sponsor.
`status` STRING The execution status.
`computation_cost` BIGNUMERIC The computation cost, in MIST.
`storage_cost` BIGNUMERIC The storage cost, in MIST.
`storage_rebate` BIGNUMERIC The storage rebate, in MIST.
`non_refundable_storage_fee` BIGNUMERIC The non-refundable part of the storage fee, in MIST.
`total_gas_cost` BIGNUMERIC The total gas cost, in MIST.
`gas_budget` BIGNUMERIC The gas budget set by the sender.
`gas_price` BIGNUMERIC The gas price paid.
`gas_owner` STRING The address paying the gas.
`executed_epoch` STRING The epoch the transaction executed in.
`transaction_json` STRING The full transaction, as JSON text.
`effects_json` STRING The full execution effects, as JSON text.
`balance_changes_json` STRING The balance changes, as JSON text.
**Daily transactions by kind** **Count transactions and successes by transaction kind on one day.** ```sql theme={null} select transaction_kind, count(*) as transactions, countif(status = 'success') as successful from `sui.transactions` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by transaction_kind order by transactions desc ``` **events** An event is a note that published code writes when something happens inside it. `events` contains one row per event a transaction produced.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing checkpoint. Partition column.
`block_number` INT64 The sequence number of the containing checkpoint.
`transaction_digest` STRING The digest of the emitting transaction.
`checkpoint` STRING The checkpoint sequence number as a string.
`epoch` STRING The epoch of the event.
`event_index` INT64 The position of the event within the transaction.
`package_id` STRING The package that defines the event type.
`module` STRING The module that defines the event type.
`sender` STRING The sender of the emitting transaction.
`event_type` STRING The Move type of the event.
`event_json` STRING The event payload, as JSON text.
**Events by module** **Rank the modules emitting the most events on one day.** ```sql theme={null} select module, count(*) as events from `sui.events` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by module order by events desc limit 20 ``` **move\_calls** A Sui transaction is a list of commands, and a Move call is the command that runs a function in published code. `move_calls` contains one row per such call, naming the code and function it ran.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing checkpoint. Partition column.
`block_number` INT64 The sequence number of the containing checkpoint.
`transaction_digest` STRING The digest of the calling transaction.
`checkpoint` STRING The checkpoint sequence number as a string.
`epoch` STRING The epoch of the call.
`cmd_index` INT64 The position of the command within the transaction.
`package` STRING The called package.
`module` STRING The called module.
`function` STRING The called function.
**Most-called functions** **Rank the most-called package functions on one day.** ```sql theme={null} select package, module, function, count(*) as calls from `sui.move_calls` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by package, module, function order by calls desc limit 20 ``` **move\_packages** A package is a published bundle of Move code, and upgrading one publishes a new version of it rather than replacing what was there. `move_packages` contains one row per version.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing checkpoint. Partition column.
`block_number` INT64 The sequence number of the containing checkpoint.
`transaction_digest` STRING The digest of the publishing transaction.
`checkpoint` STRING The checkpoint sequence number as a string.
`epoch` STRING The epoch of the publish.
`package_id` STRING The identifier of the package version.
`package_version` INT64 The version number of the package.
`original_package_id` STRING The identifier of the first version of the package.
**Daily package publishes** **Count package versions published per day over one week.** ```sql theme={null} select date(block_timestamp) as day, count(*) as packages_published from `sui.move_packages` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **objects** On Sui, everything a user holds is an object with an owner, and changing one produces a new version of it rather than editing it in place. `objects` contains one row per object version a transaction wrote, with the object's contents on the row.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing checkpoint. Partition column.
`block_number` INT64 The sequence number of the containing checkpoint.
`transaction_digest` STRING The digest of the writing transaction.
`checkpoint` STRING The checkpoint sequence number as a string.
`object_id` STRING The identifier of the object.
`version` INT64 The version of the object after the write.
`digest_hash` STRING The digest of the object version.
`object_status` STRING The status of the write, such as created or mutated.
`owner_type` STRING The ownership kind, such as address, object or shared.
`owner_address` STRING The owning address, when address-owned.
`initial_shared_version` INT64 The version at which the object became shared.
`storage_rebate` INT64 The storage rebate held by the object.
`has_public_transfer` BOOL Whether the object can be transferred publicly.
`object_type` STRING The Move type of the object.
`object_json` STRING The object contents, as JSON text.
**Object writes by status** **Count object writes by status on one day.** ```sql theme={null} select object_status, count(*) as objects from `sui.objects` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by object_status order by objects desc ``` **transaction\_objects** `transaction_objects` contains one row per object a transaction touched, without the contents. Use it when the question is which objects were involved rather than what was in them.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing checkpoint. Partition column.
`block_number` INT64 The sequence number of the containing checkpoint.
`transaction_digest` STRING The digest of the touching transaction.
`checkpoint` STRING The checkpoint sequence number as a string.
`object_id` STRING The identifier of the object.
`version` INT64 The version of the object after the transaction.
`object_status` STRING The status of the touch, such as created, mutated or deleted.
**Touched objects by status** **Count objects touched by status on one day.** ```sql theme={null} select object_status, count(*) as touches from `sui.transaction_objects` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by object_status order by touches desc ``` **wrapped\_objects** An object can be placed inside another object, which is called wrapping: a card held in a deck, say. The inner one then belongs to the outer one instead of to an address. `wrapped_objects` contains one row per object a transaction wrapped.
Column Type Description
`block_timestamp` TIMESTAMP The time of the containing checkpoint. Partition column.
`block_number` INT64 The sequence number of the containing checkpoint.
`transaction_digest` STRING The digest of the wrapping transaction.
`checkpoint` STRING The checkpoint sequence number as a string.
`object_id` STRING The identifier of the wrapped object.
`root_object_id` STRING The identifier of the object it is wrapped inside.
`root_object_version` INT64 The version of the enclosing object.
**Daily wraps** **Count objects wrapped per day over one week.** ```sql theme={null} select date(block_timestamp) as day, count(*) as wrapped from `sui.wrapped_objects` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` ## Sample queries **Transactions by kind** **Count transactions and gas costs by transaction kind on one day.** ```sql theme={null} select transaction_kind, count(*) as transactions, sum(total_gas_cost) as total_gas_cost_mist from `sui.transactions` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by transaction_kind order by transactions desc ``` **Priced tokens, daily** **Count the Sui tokens that have a daily USD price, day by day.** ```sql theme={null} select date(timestamp) as day, count(distinct token_id) as priced_tokens from `metrics_tokens.price_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'sui' group by day order by day ``` **Tokenized assets by market cap** **Rank the tokenized assets deployed on Sui by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'sui' order by daily.market_cap_circulating desc limit 20 ``` # Algorand Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/algorand The standardized Algorand tables. The `algorand` dataset holds the standardized Algorand tables. History starts 2019-06. ## Tables
Table Since
`blocks` 2019-06
`global_state_deltas` 2020-10
`inner_transactions` 2021-11
`local_state_deltas` 2020-12
`logs` 2021-11
`transactions` 2019-06
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `algorand.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Cardano Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/cardano The standardized Cardano tables. The `cardano` dataset holds the standardized Cardano tables. History starts 2017-09. ## Tables
Table Since
`blocks` 2017-09
`transactions` 2017-09
`transactions_utxos` 2017-09
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `cardano.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Flow Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/flow The standardized Flow tables. The `flow` dataset holds the standardized Flow tables. History starts 2018-12. ## Tables
Table Since
`blocks` 2018-12
`events` 2018-12
`fee_events` 2024-09
`transactions` 2018-12
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `flow.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Hedera Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/hedera The standardized Hedera tables. The `hedera` dataset holds the standardized Hedera tables. History starts 2019-09. ## Tables
Table Since
`assessed_custom_fees` 2019-09
`blocks` 2019-09
`hbar_transfers` 2019-09
`nft_transfers` 2021-09
`staking_reward_transfers` 2022-10
`token_transfers` 2021-01
`transactions` 2019-09
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `hedera.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Other ecosystems Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/index Standardized tables for chains that match none of the other families. These chains work differently enough inside that they match none of the other families, and what they have in common with each other is that and little else. Each one keeps its own set of tables. The [Tables](#tables) section below says where each chain's tables are documented and names the two conventions that hold across all of them. ## Chains
Chain `chain_id`
[Algorand](/docs/catalog/chain-verticals/other/algorand) `algorand`
[Cardano](/docs/catalog/chain-verticals/other/cardano) `cardano`
[Flow](/docs/catalog/chain-verticals/other/flow) `flow`
[Hedera](/docs/catalog/chain-verticals/other/hedera) `hedera`
[NEAR](/docs/catalog/chain-verticals/other/near) `near`
[Ripple](/docs/catalog/chain-verticals/other/ripple) `ripple`
[Starknet](/docs/catalog/chain-verticals/other/starknet) `starknet`
[Stellar](/docs/catalog/chain-verticals/other/stellar) `stellar`
[TON](/docs/catalog/chain-verticals/other/ton) `ton`
[Tron](/docs/catalog/chain-verticals/other/tron) `tron`
## Tables Each chain's tables are listed on its own page above, with every column and the month its history starts. Two habits hold across every chain here, whatever its tables are called. A table with one row per transaction or per event is split by day on `block_timestamp`, and a table of blocks on `timestamp`. Filter on that column in every query: without a filter the query reads the whole table. Identifiers reuse the familiar names wherever the chain has a matching idea: `block_number`, `transaction_hash`, and `*_index` for a position within something. ## Exceptions * Ripple and Stellar call their blocks ledgers; on both chains the ledgers land in `blocks`. * Stellar splits a transaction into a list of operations, so `operations` holds what a transaction did and `effects` holds what each operation changed. * TON's `block_headers` and `shards` are unpartitioned, so a query against either reads the whole table. Its `transactions` and `messages` split by day on `block_timestamp`, and `blocks` on `timestamp`, as usual. * Tron writes each address in two forms and both are here: the `*_hex` columns hold the form that looks like an Ethereum address, and the plain `address`-style columns hold the base58 form that starts with a T. Pick whichever matches the addresses you are joining against. # NEAR Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/near The standardized NEAR tables. The `near` dataset holds the standardized NEAR tables. History starts 2020-07. ## Tables
Table Since
`account_changes` 2020-07
`block_chunks` 2020-07
`ft_events` 2022-02
`logs` 2020-07
`receipt_actions` 2020-07
`receipts` 2020-07
`transactions` 2020-07
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `near.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Ripple Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/ripple Standardized XRP Ledger tables from January 2013. `ripple` holds the standardized XRP Ledger tables. The XRP Ledger calls its blocks ledgers, and they land in `blocks`. Transactions land in `transactions`, which is wide: it has a column for every field any kind of transaction can hold, and only the ones that apply to that kind are filled in. Everything a transaction changed lands in `affected_nodes`. Above the raw tables sits the rest of the catalog, and the XRP Ledger shows up in two parts of it: the tokenized assets issued on it, and the list of tokens we know about with their daily prices. Tokenized funds, stablecoins and tokenized commodities make up the asset side. The market pages go deeper on each of these. [Stablecoins](/docs/catalog/stablecoins/index) and [Real-world assets](/docs/catalog/real-world-assets/index) cover the tokenized assets and their daily tables. [Tokens](/docs/catalog/tokens/index) covers the token list and the daily price table. ## Tables
Table Since Description
`blocks` 2013-01 One row per ledger, with close times and total XRP in existence.
`transactions` 2013-01 One row per transaction, with the columns its `transaction_type` populates.
`affected_nodes` 2013-01 One row per ledger entry a transaction created, modified or deleted.
Ledgers are keyed on `number` and transactions on `transaction_hash`. Each `affected_nodes` row has `new_fields`, `final_fields` and `previous_fields` as JSON, so you can see what a record held before the change and after it. The columns that hold amounts, `amount`, `deliver_max` and `delivered_amount`, are JSON rather than numbers. An amount on this chain is one of two things: a plain count of drops if it is XRP, one drop being a millionth of an XRP, or a small record naming the currency, its issuer and the value if it is anything else. For payments, read `delivered_amount`: it says what arrived, which is not always what was asked for, because the chain allows a payment to deliver less than its stated amount. ## Sample queries **Transaction success rate** **Count transactions by type and their success rate on one day.** `tesSUCCESS` is the result code of a successful transaction. ```sql theme={null} select transaction_type, count(*) as transactions, countif(transaction_result = 'tesSUCCESS') as successful from `ripple.transactions` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by transaction_type order by transactions desc ``` **Tokenized assets ranked** **Rank the tokenized assets issued on the XRP Ledger by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'ripple' order by daily.market_cap_circulating desc limit 20 ``` **Priced tokens** **List the XRP Ledger tokens that had a daily price over one week.** ```sql theme={null} with priced as ( select token_id, avg(price) as avg_price, count(*) as price_days from `metrics_tokens.price_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'ripple' group by token_id ) select tokens.symbol, tokens.name, priced.avg_price, priced.price_days from priced join `dimensions.tokens` as tokens using (token_id) order by priced.avg_price desc limit 20 ``` # Starknet Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/starknet The standardized Starknet tables. The `starknet` dataset holds the standardized Starknet tables. History starts 2021-11. ## Tables
Table Since
`blocks` 2021-11
`events` 2022-01
`traces` 2021-11
`traces_summary` 2021-11
`transactions` 2021-11
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `starknet.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Stellar Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/stellar Standardized Stellar tables from September 2015. `stellar` holds the standardized Stellar tables. Stellar calls its blocks ledgers, and they land in `blocks`. A transaction here is a wrapper: what it does sits in a list of operations. So transactions land in `transactions`, the operations inside them in `operations`, and what each operation changed in `effects`. Above the raw tables sits the rest of the catalog, and Stellar shows up in two parts of it: the tokenized assets issued on it, and the list of tokens we know about with their daily prices. Tokenized funds and stablecoins make up most of the asset side. The market pages go deeper on each of these. [Real-world assets](/docs/catalog/real-world-assets/index) and [Stablecoins](/docs/catalog/stablecoins/index) cover the tokenized assets and their daily tables. [Tokens](/docs/catalog/tokens/index) covers the token list and the daily price table. ## Tables
Table Since Description
`blocks` 2015-09 One row per ledger, with transaction counts, fee pool and total lumens.
`transactions` 2015-09 One row per transaction, with its fees, the account that sent it, and the original encoded form.
`operations` 2015-09 One row per operation, typed by `operation_type`.
`effects` 2015-09 One row per state change an operation produced.
Ledgers are keyed on `number`, transactions on `transaction_hash`, operations on `operation_id` and effects on `effect_id`. The tables get finer as you go down: a transaction holds one or more operations, and an operation produces any number of effects, including none. For payments and trades, start from `operations` and filter on `operation_type`. Use `effects` when the question is who was credited and who was debited. ## Sample queries **Operations by type** **Count operations by type on one day.** ```sql theme={null} select operation_type, count(*) as operations from `stellar.operations` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by operation_type order by operations desc limit 20 ``` **Tokenized assets ranked** **Rank the tokenized assets issued on Stellar by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'stellar' order by daily.market_cap_circulating desc limit 20 ``` **Priced tokens** **List the Stellar tokens that had a daily price over one week.** ```sql theme={null} with priced as ( select token_id, avg(price) as avg_price, count(*) as price_days from `metrics_tokens.price_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'stellar' group by token_id ) select tokens.symbol, tokens.name, priced.avg_price, priced.price_days from priced join `dimensions.tokens` as tokens using (token_id) order by priced.avg_price desc limit 20 ``` # TON Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/ton The standardized TON tables. The `ton` dataset holds the standardized TON tables. History starts 2019-11. ## Tables
Table Since
`block_headers` Not partitioned
`blocks` 2019-11
`messages` 2019-11
`shards` Not partitioned
`transactions` 2019-11
## Sample queries > [!WARNING] > > `transactions` and `messages` split by day on `block_timestamp`, and `blocks` on `timestamp`. Bound that column in every query against them. `block_headers` and `shards` are unpartitioned, so every query against those two reads the whole table. **Daily transactions** **Count daily transactions over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions from `ton.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Tron Source: https://tokenterminal.com/docs/catalog/chain-verticals/other/tron Standardized Tron tables from June 2018. `tron` holds the standardized Tron tables. They look much like the tables for the EVM chains, the ones running the Ethereum Virtual Machine: `blocks`, `transactions` and `logs`, plus two more for the transfers Tron handles in its own way rather than through contracts: `internal_transactions` and `wallet_blocks`. Tron writes an address in two forms, and both are here. The columns named `*_hex` hold the form that looks like an Ethereum address; the plain `address`-style columns hold the base58 form, the one that starts with a T and appears in wallets and explorers. Pick whichever matches the addresses you are joining against. Above the raw tables sits the rest of the catalog, and Tron shows up in two parts of it: the tokenized assets issued on it, and the list of tokens we know about with their daily prices. Stablecoins dominate the asset side. The market pages go deeper on each of these. [Stablecoins](/docs/catalog/stablecoins/index) and [Real-world assets](/docs/catalog/real-world-assets/index) cover the tokenized assets and their daily tables. [Tokens](/docs/catalog/tokens/index) covers the token list and the daily price table. ## Tables
Table Since Description
`blocks` 2018-06 One row per block, following the EVM block shape.
`transactions` 2018-06 One row per transaction, with what it cost and the resources it used on the same row.
`logs` 2018-10 One row per contract event log, following the EVM log shape.
`internal_transactions` 2018-10 One row per internal transaction, with per-token values in `call_value_info`.
`wallet_blocks` 2018-06 One row per native wallet action, linked to its transaction.
Blocks are keyed on `number`, transactions on `transaction_hash`, and logs on `block_number` with `log_index`. Tron meters two resources in place of a single gas fee: energy for running contracts and bandwidth for the size of a transaction, and an account can hold an allowance of either. The `receipt_info_energy_fee`, `receipt_info_energy_usage_total` and `receipt_info_net_fee` columns on `transactions` record that, a set of columns particular to Tron. ## Sample queries **Daily transactions and fees** **Sum daily transactions and energy fees over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as transactions, sum(receipt_info_energy_fee) as energy_fee_sun from `tron.transactions` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **Tokenized assets ranked** **Rank the tokenized assets issued on Tron by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'tron' order by daily.market_cap_circulating desc ``` **Priced tokens, daily** **Count the Tron tokens that have a daily USD price, day by day.** ```sql theme={null} select date(timestamp) as day, count(distinct token_id) as priced_tokens from `metrics_tokens.price_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'tron' group by day order by day ``` # Accounts Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/accounts Wallets and programs labeled with the projects that own them. `dimensions.accounts` holds one row per address on Solana that is labeled or that a `facts_accounts` table holds a row for, keyed on `chain_id` and `address`. An account is a wallet or a program, such as an exchange wallet or an Orca pool, and where it is labeled its row names the project that runs it, so a labeled address in any Solana table resolves to the project behind it. An address nobody has labeled has a null `label_source` and null label columns beside its region and funding. `label_source` says how a labeled address reached the table. The Solana rows are `curated`, an attribution a person authored; `factory_derived` marks an address a known factory emitted and names that factory in `parent_address`. Every column is documented at [Accounts](/docs/catalog/accounts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` then `address`. Filter on `chain_id` to read one chain, and add `address` for a single account; a query filtered only on `project_id` or `label_source` reads every row of a table that spans every account the facts hold, so keep the select list to the columns you need. **Labeled projects** **Rank the projects with the most labeled addresses on Solana.** Joining `dimensions.projects` on `project_id` adds each project's name and its market sector. ```sql theme={null} select projects.name, projects.primary_market_sector, count(*) as addresses from `dimensions.accounts` as accounts join `dimensions.projects` as projects using (project_id) where accounts.chain_id = 'solana' and accounts.label_source = 'curated' group by projects.name, projects.primary_market_sector order by addresses desc limit 50 ``` **What one project runs** **List the addresses one project runs on Solana.** `contract_name` is the label the attributing project gives an address, and `account_type` reads `smartcontract` for a program. ```sql theme={null} select address, contract_name, account_type from `dimensions.accounts` where chain_id = 'solana' and project_id = 'jupiter' and label_source = 'curated' order by contract_name limit 100 ``` **Look up one address** **Resolve one Solana address to the project that runs it.** Filter on `chain_id` and `address`, and paste the address exactly as it appears: Solana spells it in case-sensitive base58. ```sql theme={null} select address, project_id, contract_name, account_type from `dimensions.accounts` where chain_id = 'solana' and address = 'JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4' ``` # Apps Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/apps Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Solana. An app is one deployed version of a protocol that a project runs, such as `orca-whirlpools`. The project level sits on [Projects](/docs/catalog/chain-verticals/solana/projects). * `metrics_apps_by_chain`: one table per measure, one row per app per chain per day. An app's figure on Solana for one day rolls into its project's figure on the Projects page, worked out once and served at both levels. An app's chain rows for one day sum to what `metrics_apps` serves without the chain breakout, so use these tables when the chain breakdown is the question. An app's activity has a finer table beneath it: a DEX's volume breaks down pool by pool on [DEX](/docs/catalog/chain-verticals/solana/dex), and bridge volume breaks down transfer by transfer on [Bridges](/docs/catalog/chain-verticals/solana/bridges). Start with the daily figures and drop down when the question needs the detail. Every column is documented at [Apps ▸ Metrics](/docs/catalog/apps/metrics). ## Sample queries **Apps on Solana** **Rank the apps active on Solana by trading volume over one week.** ```sql theme={null} select apps.name, sum(daily.trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` as daily join `dimensions.apps` as apps using (app_id) where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'solana' group by apps.name order by trading_volume desc ``` **Solana's share** **Work out how much of one app runs on Solana.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the app runs on. ```sql theme={null} with by_chain as ( select chain_id, sum(trading_volume) as trading_volume from `metrics_apps_by_chain.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and app_id = 'orca-whirlpools' group by chain_id ) select chain_id, trading_volume, trading_volume / sum(trading_volume) over () as share from by_chain order by trading_volume desc limit 20 ``` # Assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/assets Every curated asset issued on Solana, with daily supply, holders and transfer activity. An asset is a financial instrument someone has put onchain, and a deployment is one asset on one chain at one mint address. The first query below counts what Solana holds, by kind. * [`dimensions.asset_tokens`](/docs/catalog/assets/registry): one row per deployment. * [`metrics_asset_tokens`](/docs/catalog/assets/metrics): one table per measure, one row per deployment per day. Every column is documented at [Assets](/docs/catalog/assets/index). Market verticals scope this layer further: [Stablecoins](/docs/catalog/chain-verticals/solana/stablecoins) and [Real-world assets](/docs/catalog/chain-verticals/solana/real-world-assets). ## Sample queries **Largest assets** **Rank the assets on Solana by circulating market cap.** Circulating market cap is the supply held by the public, valued in USD, with tokens the issuer has minted but not released left out. ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'solana' order by daily.market_cap_circulating desc limit 20 ``` **Deployments by kind** **Count Solana deployments by asset kind, and how many were issued on Solana itself.** A deployment is native when the issuer minted the token on Solana, and bridged when the token stands in for supply issued somewhere else. ```sql theme={null} select assets.asset_type, count(*) as deployments, countif(deployments.bridged_status = 'native') as native from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'solana' group by assets.asset_type order by deployments desc ``` **One deployment's series** **Read one Solana deployment's daily supply and holders.** `asset_token_id` is the asset, the mint address and the chain with dashes, and the mint address keeps its base58 spelling. Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. Both tables here read the native side of the deployment; a bridged deployment reads the `_bridged` pair instead. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v-solana' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v-solana' and timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Bridges Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/bridges Cross-chain transfers that left Solana or arrived on it, matched leg to leg. A bridge moves value from one chain to another. Each move leaves an event on the chain it departs from and another on the chain it arrives at, and [`facts_bridge_tokens.transfers`](/docs/catalog/bridges/transfers) pairs those two events into one row. One transfer belongs to two chains, so each side is keyed on its own column: filter `source_chain_id = 'solana'` for transfers leaving Solana, `destination_chain_id = 'solana'` for transfers arriving, or either for every transfer that touched the chain. Every row has a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed `source_` or `destination_`. A transfer matched on one side only still appears, with the leg it has and an `unmatched_reason` saying why the other side stayed unmatched. To count matched pairs alone, require both chain columns to be present. Every column is documented at [Bridges ▸ Transfers](/docs/catalog/bridges/transfers), including how an unmatched leg is recorded. ## Sample queries For any sum of value, use `transfer_amount_usd`: it prices the transfer once. `source_transfer_amount_usd` and `destination_transfer_amount_usd` price each leg on its own chain, and adding them counts one transfer twice; reach for them only when the question is the difference between the two ends. > [!WARNING] > > The table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. For a daily total per token, `metrics_bridge_tokens.transfer_volume_source_daily` and `metrics_bridge_tokens.transfer_volume_destination_daily` answer the same question at a fraction of the cost. **Daily in and out** **Compare the value leaving Solana with the value arriving each day.** Testing the source and destination columns separately inside the sum splits the same measure into the two directions. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(if(source_chain_id = 'solana', transfer_amount_usd, 0)) as leaving_usd, sum(if(destination_chain_id = 'solana', transfer_amount_usd, 0)) as arriving_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and (source_chain_id = 'solana' or destination_chain_id = 'solana') group by day order by day ``` **Where value went** **Find where the value leaving Solana went.** Each row already holds both ends, so grouping on `destination_chain_id` needs no second pass over the table. ```sql theme={null} select destination_chain_id, count(*) as transfers, sum(transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') and source_chain_id = 'solana' group by destination_chain_id order by volume_usd desc limit 20 ``` **By bridge** **Rank the bridges by the Solana value they moved.** `app_id` names the bridge behind the transfer, and joining `dimensions.apps` turns it into a readable name. ```sql theme={null} select apps.name, countif(transfers.source_chain_id = 'solana') as leaving, countif(transfers.destination_chain_id = 'solana') as arriving, sum(transfers.transfer_amount_usd) as volume_usd from `facts_bridge_tokens.transfers` as transfers join `dimensions.apps` as apps using (app_id) where transfers.block_timestamp >= timestamp('2026-08-16') and transfers.block_timestamp < timestamp('2026-08-23') and (transfers.source_chain_id = 'solana' or transfers.destination_chain_id = 'solana') group by apps.name order by volume_usd desc ``` # Contracts Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/contracts Every program deployed on Solana, with the account that deployed it. `dimensions.contracts` holds one row per program deployed on Solana, keyed on `chain_id` and `contract_address`. Solana calls a smart contract a program, and the row describes the address's first deployment: the time it appeared and the account that signed for it. The list is everything we see onchain, which reaches far past the programs anyone has labeled. Joining [`dimensions.accounts`](/docs/catalog/accounts/registry) on `account_id` keeps the result to addresses a project has been attributed, and names them. Every column is documented at [Contracts](/docs/catalog/contracts/registry). ## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and those two columns are all that prunes a scan of it. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a program** **When one Solana program was first deployed, and by whom.** The address is Orca's Whirlpools program, spelled in base58 exactly as the chain writes it. ```sql theme={null} select first_deployed_at, deployer_address from `dimensions.contracts` where chain_id = 'solana' and contract_address = 'whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc' ``` **One deployer's programs** **List the programs one account deployed.** `deployer_address` is the account that signed the deployment, so an account that ships many programs returns all of them in one read. ```sql theme={null} select contract_address, first_deployed_at from `dimensions.contracts` where chain_id = 'solana' and deployer_address = '9ZqQnmRNWDePm9d8SG4mymFRXArwBTPKkSTW6CbZhcCh' order by first_deployed_at desc limit 100 ``` **Named programs, newest first** **Date the labeled Solana programs.** Joining `dimensions.accounts` on `account_id` adds the project the address is attributed to and the name that project gives it, which turns a list of base58 strings into a readable one. ```sql theme={null} select accounts.project_id, accounts.contract_name, contracts.contract_address, contracts.first_deployed_at from `dimensions.contracts` as contracts join `dimensions.accounts` as accounts using (account_id) where contracts.chain_id = 'solana' order by contracts.first_deployed_at desc limit 100 ``` # DEX Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/dex Solana trading pools and their daily volume. A decentralized exchange, or DEX, lets users swap one token for another against a pool: a program-owned account holding a reserve of two tokens that anyone can trade with. The Solana venues in the pool tables include Raydium's OpenBook, CLMM, CPMM and stable-swap pools, Orca's Whirlpools, Meteora's liquidity pools, Pump.fun's launchpad and PumpSwap, the AMM its graduated tokens trade on. Their pools appear in three tables. * [`dimensions.dex_pools`](/docs/catalog/dex/registry): one row per pool. * [`metrics_dex_pools`](/docs/catalog/dex/metrics): one table per measure, one row per pool per day. * [`metrics_dex_pools_by_pair`](/docs/catalog/dex/metrics): one row per pool and traded token pair per day, in `trading_volume_daily`. Trading volume is a flow, so it adds up: a week of daily rows sums to the week, and a set of pools sums to the group. A volume row lands only on the days a pool saw trading. Every column is documented at [DEX](/docs/catalog/dex/index). ## Sample queries > [!WARNING] > > The daily pool tables are among the largest in the catalog. Bound `timestamp` and filter `chain_id` in every query; without them the query reads the whole table. **Top pools, one day** **Rank Solana pools by trading volume on one day.** Reading the day from the volume table and joining the pool list afterwards keeps the join small. ```sql theme={null} with top_pools as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'solana' order by trading_volume desc limit 20 ) select pools.pool_display_name, pools.app_id, top_pools.trading_volume from top_pools join `dimensions.dex_pools` as pools using (dex_pool_id) order by top_pools.trading_volume desc ``` **Volume by venue** **Split one day of Solana volume across the venues that ran it.** The pool grain is the only place the split exists, since one venue's pools number in the millions. ```sql theme={null} with day_volume as ( select dex_pool_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-21') and chain_id = 'solana' ) select pools.app_id, count(*) as pools_traded, sum(day_volume.trading_volume) as trading_volume from day_volume join `dimensions.dex_pools` as pools using (dex_pool_id) group by app_id order by trading_volume desc ``` **Busiest pairs** **Find the busiest traded token pairs on Solana, and how many pools each one trades in.** `dex_pair_id` joins the two mint addresses and the chain in sorted address order, so the same two tokens produce the same identifier whichever way round the trade went. ```sql theme={null} select dex_pair_id, count(distinct dex_pool_id) as pools, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and chain_id = 'solana' group by dex_pair_id order by trading_volume desc limit 20 ``` # Solana Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/index Everything the catalog holds for Solana, from raw blocks to project activity. Most of the catalog is queryable for Solana, from the slots themselves to the daily activity of the projects that run on it. The chain's own record sits in the `solana` dataset: one row per slot, transaction, instruction, account touched and reward paid. Everything above that sits in the catalog, where the Solana rows are selected with `chain_id = 'solana'`. The section mirrors the catalog itself: the core entities, then the market verticals with data on Solana. ## Layers
Layer Since What it holds
[Raw](/docs/catalog/chain-verticals/solana/raw) 2020-10 Slots, transactions, instructions, account balance moves and rewards.
[Projects](/docs/catalog/chain-verticals/solana/projects) 2020-10 Daily Fees and Revenue for each tracked project, broken out to Solana.
[Apps](/docs/catalog/chain-verticals/solana/apps) 2021-04 Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Solana.
[Assets](/docs/catalog/chain-verticals/solana/assets) 2020-10 Every curated asset issued on Solana, with daily supply, holders and transfer activity.
[Tokens](/docs/catalog/chain-verticals/solana/tokens) 2020-03 Every SPL transfer, both sides of every balance move, holder balances at query time, and daily prices.
[Accounts](/docs/catalog/chain-verticals/solana/accounts) **In progress** Wallets and programs labeled with the projects that own them.
[Contracts](/docs/catalog/chain-verticals/solana/contracts) 2021-01 Every program deployed on Solana, with the account that deployed it.
[Stablecoins](/docs/catalog/chain-verticals/solana/stablecoins) 2020-10 Every stablecoin issued on Solana: supply, holders and transfers.
[Real-world assets](/docs/catalog/chain-verticals/solana/real-world-assets) 2023-03 Tokenized stocks, funds and commodities issued on Solana, tracked against their underlying instruments.
[DEX](/docs/catalog/chain-verticals/solana/dex) 2022-03 Trading pools and their daily volume, per pool and per traded token pair.
[Bridges](/docs/catalog/chain-verticals/solana/bridges) 2025-05 Cross-chain transfers that left Solana or arrived on it, matched leg to leg.
## Filtering `chain_id` reads `solana` wherever a catalog table has a chain column, so the same filter selects Solana everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from `dimensions.asset_tokens`, as the query below does. Project and app totals span every chain a project runs on, so one chain's share reads from `metrics_projects_by_chain` and `metrics_apps_by_chain`. A bridge transfer has a chain on each end, in `source_chain_id` and `destination_chain_id`. Solana addresses are base58 and case-sensitive, so they are matched exactly as the chain writes them. An EVM address is lowercased before it is stored; a Solana mint, program or wallet address is not, and `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` matches only in that spelling. > [!WARNING] > > Every table splits by day: the raw and event tables on `block_timestamp`, the daily tables on `timestamp`. Bound that column in every query; without a bound the query reads the whole table. ```sql theme={null} select daily.timestamp, deployments.asset_id, assets.symbol, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where deployments.chain_id = 'solana' and daily.timestamp >= timestamp('2026-08-01') and daily.timestamp < timestamp('2026-08-02') limit 100 ``` # Projects Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/projects Daily Fees and Revenue for each tracked project, broken out to Solana. The top of the catalog breaks activity down by who ran it. A project is the entity behind a protocol, such as Jupiter; its apps' figures on Solana sit on [Apps](/docs/catalog/chain-verticals/solana/apps). * [`metrics_projects_by_chain`](/docs/catalog/projects/metrics): one table per measure, one row per project per chain per day. A project figure for one chain and one day is the sum of its apps on that chain and day, worked out once and served at both levels. The same holds across chains: a project's chain rows for one day sum to what `metrics_projects` serves without the chain breakout, so use these tables when the chain breakdown is the question. Every column is documented at [Projects ▸ Metrics](/docs/catalog/projects/metrics). ## Sample queries **One project's series** **Read one project's daily Solana fees.** ```sql theme={null} select daily.timestamp, daily.fees from `metrics_projects_by_chain.fees_daily` as daily where daily.timestamp >= timestamp('2026-08-16') and daily.timestamp < timestamp('2026-08-23') and daily.chain_id = 'solana' and daily.project_id = 'jupiter' order by daily.timestamp ``` **Solana's share** **Work out how much of a project runs on Solana.** Dropping the chain filter and grouping by chain turns the same table into a comparison across every chain the project operates on. ```sql theme={null} with by_chain as ( select chain_id, sum(fees) as fees from `metrics_projects_by_chain.fees_daily` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') and project_id = 'jupiter' group by chain_id ) select chain_id, fees, fees / sum(fees) over () as share from by_chain order by fees desc limit 20 ``` # Raw Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/raw The standardized Solana blocks, transactions, instructions, account activity and rewards. The `solana` dataset holds the standardized Solana tables. A Solana transaction is a list of instructions run in order, and it has to name up front every account it will touch. The tables follow that shape. `blocks` summarizes each slot, which is Solana's word for a block. `transactions` holds one row per transaction. `instructions` breaks each transaction into its individual instructions, one per row. `account_activity` shows what each account held before and after. `rewards` holds the payouts to validators and stakers. Transactions and instructions that failed sit apart, in `failed_transactions` and `failed_instructions`, in the same shape as the two tables they mirror. Two Solana words show up throughout. A **program** is what other chains call a smart contract. An **account** is a slot of storage on the chain, and everything is one: a wallet, a token balance, a program's own code. Amounts below are in lamports, the smallest unit of SOL: one SOL is a billion lamports. ## Tables
Table Since Description
`blocks` 2020-10 One row per slot, with transaction counts and fee totals.
`transactions` 2020-10 One row per transaction, with its fee and signatures.
`instructions` 2020-10 One row per executed instruction, inner instructions included.
`account_activity` 2020-10 One row per account a transaction touched, with balances before and after.
`rewards` 2020-10 One row per reward credited to an account in a block.
`failed_transactions` 2025-01 Transactions that failed, in the same shape as `transactions`.
`failed_instructions` 2025-01 Instructions that failed, in the same shape as `instructions`.
`instructions` and `account_activity` are among the largest tables we publish anywhere, so keep the `block_timestamp` range narrow and filter on `executing_account` or `account_key` as early in the query as you can. **blocks** A slot is Solana's block: one batch of transactions added to the chain. Vote transactions are validators keeping the network in agreement rather than users doing anything, so the counts and fee totals here are split into vote and non-vote. `blocks` contains one row per slot.
Column Type Description
`block_slot` `INT64` The slot number.
`block_hash` `STRING` The hash of the block.
`block_height` `INT64` The block height.
`block_timestamp` `TIMESTAMP` The time the block was produced. Partition column.
`parent_slot` `INT64` The slot of the parent block.
`previous_block_hash` `STRING` The hash of the parent block.
`total_transaction_count` `INT64` The number of transactions in the block.
`successful_transaction_count` `INT64` The number of successful transactions.
`failed_transaction_count` `INT64` The number of failed transactions.
`vote_transaction_count` `INT64` The number of vote transactions.
`non_vote_transaction_count` `INT64` The number of non-vote transactions.
`successful_vote_transaction_count` `INT64` The number of successful vote transactions.
`successful_non_vote_transaction_count` `INT64` The number of successful non-vote transactions.
`failed_vote_transaction_count` `INT64` The number of failed vote transactions.
`failed_non_vote_transaction_count` `INT64` The number of failed non-vote transactions.
`total_fee` `INT64` The total fees paid in the block, in lamports.
`successful_vote_transactions_fee` `INT64` The fees paid by successful vote transactions, in lamports.
`successful_non_vote_transactions_fee` `INT64` The fees paid by successful non-vote transactions, in lamports.
`failed_vote_transactions_fee` `INT64` The fees paid by failed vote transactions, in lamports.
`failed_non_vote_transactions_fee` `INT64` The fees paid by failed non-vote transactions, in lamports.
`successful_non_vote_transactions_priority_fee` `INT64` The priority fees paid by successful non-vote transactions, in lamports.
`failed_non_vote_transactions_priority_fee` `INT64` The priority fees paid by failed non-vote transactions, in lamports.
**transactions** A transaction is one signed bundle of instructions, naming every account it will touch. `transactions` contains one row per transaction.
Column Type Description
`block_timestamp` `TIMESTAMP` The time of the block containing the transaction. Partition column.
`block_slot` `INT64` The slot of the containing block.
`transaction_index` `INT64` The position of the transaction within the block.
`transaction_id` `STRING` The first signature of the transaction, the identifier used everywhere else.
`account_keys` `ARRAY` The accounts referenced by the transaction.
`executing_accounts` `ARRAY` The programs invoked by the transaction.
`fee` `INT64` The fee paid, in lamports.
`signatures` `ARRAY` All signatures on the transaction.
`return_data` `STRUCT` The program return data: program id and data.
`compute_units_consumed` `INT64` The compute units consumed.
`required_signatures_count` `INT64` The number of required signatures.
`readonly_signed_accounts_count` `INT64` The number of read-only signed accounts.
`readonly_unsigned_accounts_count` `INT64` The number of read-only unsigned accounts.
`log_messages` `ARRAY` The program log messages.
`signer` `STRING` The fee-paying signer.
`version` `STRING` The transaction version.
`logs_truncated` `BOOL` Whether the log output was truncated by the node.
`success` `BOOL` Whether the transaction succeeded.
`error` `STRING` The error raised, when the transaction failed.
**instructions** An instruction is one call into a program, the unit of work inside a transaction. A transaction runs its instructions in order, and a program can make further calls of its own: those are the inner instructions. `instructions` contains one row per executed instruction, inner instructions included.
Column Type Description
`block_slot` `INT64` The slot of the containing block.
`block_timestamp` `TIMESTAMP` The time of the containing block. Partition column.
`transaction_id` `STRING` The identifier of the containing transaction.
`transaction_index` `INT64` The position of the transaction within the block.
`transaction_signer` `STRING` The fee-paying signer of the transaction.
`instruction_index` `INT64` The position of the instruction within the transaction.
`outer_instruction_index` `INT64` The index of the enclosing top-level instruction, for inner instructions.
`executing_account` `STRING` The program executing the instruction.
`outer_executing_account` `STRING` The program executing the enclosing instruction.
`account_arguments` `ARRAY` The accounts passed to the instruction.
`instruction_data` `STRING` The instruction payload.
`stack_height` `INT64` The invocation depth of the instruction.
`surrogate_key` `STRING` A unique identifier we build for the row, because the chain gives an instruction none of its own.
**account\_activity** `account_activity` contains one row per account a transaction touched, showing what it held before the transaction and after it: SOL for every account, plus the token amount for accounts that hold a token. This is where you see who gained and who lost.
Column Type Description
`block_timestamp` `TIMESTAMP` The time of the containing block. Partition column.
`block_slot` `INT64` The slot of the containing block.
`transaction_index` `INT64` The position of the transaction within the block.
`transaction_id` `STRING` The identifier of the containing transaction.
`signer` `STRING` The fee-paying signer of the transaction.
`account_key` `STRING` The account touched.
`account_index` `INT64` The position of the account in the transaction's account list.
`pre_balance` `INT64` The native balance before the transaction, in lamports.
`post_balance` `INT64` The native balance after the transaction, in lamports.
`pre_token_amount` `FLOAT64` The token balance before the transaction, for token accounts.
`pre_token_mint` `STRING` The mint of the token balance before the transaction.
`pre_token_owner` `STRING` The owner of the token account before the transaction.
`pre_token_program` `STRING` The token program of the account before the transaction.
`post_token_amount` `FLOAT64` The token balance after the transaction, for token accounts.
`post_token_mint` `STRING` The mint of the token balance after the transaction.
`post_token_owner` `STRING` The owner of the token account after the transaction.
`post_token_program` `STRING` The token program of the account after the transaction.
**rewards** A reward is a payout the chain credits to an account: for staking, for voting, or as a rent refund. `rewards` contains one row per reward credited in a block.
Column Type Description
`block_slot` `INT64` The slot of the block crediting the reward.
`block_hash` `STRING` The hash of the block.
`block_timestamp` `TIMESTAMP` The time of the block. Partition column.
`pubkey` `STRING` The account credited.
`lamports` `NUMERIC` The reward amount, in lamports.
`commission` `NUMERIC` The validator commission applied.
`post_balance` `NUMERIC` The account balance after the reward, in lamports.
`reward_type` `STRING` The reward type, such as fee, rent, staking or voting.
`commission_bps` `INT64` The validator commission in basis points.
## Sample queries > [!WARNING] > > Every table splits by day on `block_timestamp`. Bound that column in every query; without a bound the query reads the whole table. `instructions` clusters on `executing_account`, `account_activity` on `account_key` and `transaction_id`, and `rewards` on `pubkey`, so naming one of those beside the date bound is what keeps a read on the two biggest tables small. **Daily fees** **Sum daily non-vote transactions and total fees over one week.** Vote transactions are validators keeping the network in agreement, so `non_vote_transaction_count` is the figure closest to user activity; `total_fee` is in lamports and covers both kinds. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, sum(non_vote_transaction_count) as non_vote_transactions, sum(total_fee) as total_fee_lamports from `solana.blocks` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **One program's day** **Measure how much work one program did on one day.** The program is Orca's Whirlpools, and `executing_account` is both the program that ran the instruction and the cluster key, so this reads a slice of the day rather than all of it. Inner instructions are counted here too, which is why the instruction count runs ahead of the transaction count. ```sql theme={null} select count(*) as instructions, count(distinct transaction_id) as transactions, count(distinct transaction_signer) as signers from `solana.instructions` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and executing_account = 'whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc' ``` **One account's balance moves** **Follow the SOL moving in and out of one account across a day.** `account_key` is the cluster key, so naming the account holds the read down. The balances are lamports before and after each transaction, and their difference is what that transaction did to the account. ```sql theme={null} select block_timestamp, transaction_id, (post_balance - pre_balance) / 1e9 as sol_change from `solana.account_activity` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and account_key = 'CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C' order by block_timestamp limit 100 ``` **Daily rewards by type** **Split a week of rewards by what the chain paid them for.** `reward_type` separates staking from voting, fees and rent refunds, and `lamports` divided by a billion gives SOL. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, reward_type, count(*) as rewards, sum(lamports) / 1e9 as sol from `solana.rewards` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day, reward_type order by day, reward_type ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/real-world-assets Tokenized stocks, funds and commodities issued on Solana, tracked against their underlying instruments. Solana real-world assets are the [Assets](/docs/catalog/chain-verticals/solana/assets) layer under the tokenized instrument types: stocks, funds and commodities. Each one tracks an underlying instrument named in `dimensions.reference_assets`, and `metrics_asset_tokens` holds the daily supply and holders of its Solana deployments, one table per measure. Every column is documented at [Real-world assets](/docs/catalog/real-world-assets/index). ## Sample queries **Largest real-world assets** **Rank the real-world assets issued on Solana by circulating market cap.** ```sql theme={null} select assets.symbol, assets.asset_type, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'solana' and assets.asset_type in ('tokenized-stocks', 'tokenized-funds', 'tokenized-commodities') order by daily.market_cap_circulating desc limit 20 ``` **What each one tracks** **List Solana tokenized stocks with the instrument each one tracks.** ```sql theme={null} select assets.symbol, reference_assets.name as tracks, reference_assets.type from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where deployments.chain_id = 'solana' and assets.asset_type = 'tokenized-stocks' order by assets.symbol ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/stablecoins Every stablecoin issued on Solana: supply, holders and transfers. Solana stablecoins are the [Assets](/docs/catalog/chain-verticals/solana/assets) layer under `asset_type = 'stablecoin'`: the registry rows describe each coin's deployments and `metrics_asset_tokens` holds their daily supply, holders and transfer activity in one table per measure. Every column is documented at [Stablecoins](/docs/catalog/stablecoins/index). ## Sample queries **Largest stablecoins** **Rank the stablecoins issued on Solana by native circulating supply.** ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp >= timestamp('2026-08-22') and daily.timestamp < timestamp('2026-08-23') and deployments.chain_id = 'solana' and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 20 ``` **One coin's series** **Read one stablecoin's daily supply and holders on Solana.** Each measure is its own table, so reading two means a join on `asset_token_id` and `timestamp`. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where asset_token_id = 'usdc-EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v-solana' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ), holders as ( select timestamp, holders_native from `metrics_asset_tokens.holders_native_daily` where asset_token_id = 'usdc-EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v-solana' and timestamp >= timestamp('2026-06-01') and timestamp < timestamp('2026-08-23') ) select timestamp, supply.market_cap_circulating_native, holders.holders_native from supply left join holders using (timestamp) order by timestamp ``` # Tokens Source: https://tokenterminal.com/docs/catalog/chain-verticals/solana/tokens Solana token transfers, holder balances and daily prices. Four surfaces cover token activity on Solana. * [`facts_tokens.transfers`](/docs/catalog/tokens/transfers): one row per token transfer. * [`functions.calculate_latest_token_balances`](/docs/catalog/tokens/balances) and its historical sibling: holder balances at any date, computed at query time. * [`metrics_tokens.price_daily`](/docs/catalog/tokens/metrics): one USD price per token per day. Solana's token standard is SPL, so `token_type = 'spl'` and `token_address` is the mint address in base58, matched exactly as the chain writes it. `from_address` and `to_address` are token accounts rather than wallets, since one wallet can own several accounts in the same mint; `to_owner` is the wallet behind the credited one. The token list is everything we see onchain, which reaches far past the tokens anyone would want: a ranking of the busiest tokens returns mints whose symbols imitate well-known ones. Nothing has gone wrong when those appear. Joining `dimensions.asset_tokens` keeps the tokens tied to a named asset with a named issuer; [Assets](/docs/catalog/chain-verticals/solana/assets) covers that layer. Every column and both function signatures are documented at [Tokens](/docs/catalog/tokens/index). ## Sample queries > [!WARNING] > > `facts_tokens.transfers` is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **Daily activity** **Count the transfers and the accounts behind them on one day.** A distinct-account count holds for the window it was asked for, and summing several days counts anyone active on more than one of them twice; [Assets ▸ Senders](/docs/catalog/assets/senders) covers the longer windows. ```sql theme={null} select count(*) as transfers, count(distinct from_address) as senders, count(distinct to_address) as recipients from `facts_tokens.transfers` where partition_key >= timestamp('2026-08-01') and partition_key < timestamp('2026-09-01') and block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') and chain_id = 'solana' and token_type = 'spl' ``` **Busiest tokens** **Rank the busiest Solana mints on one day.** Joining `dimensions.tokens` on `token_id` adds the symbol and name of each mint. ```sql theme={null} select tokens.symbol, transfers.token_address, count(*) as transfer_count, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') and transfers.chain_id = 'solana' group by tokens.symbol, transfers.token_address order by transfer_count desc limit 20 ``` **Net balance moves** **Find the wallets that gained and lost the most of one mint on one day.** Each movement is unnested into its two legs -- the sender debited, the receiver credited -- and summing them per wallet nets the day; dividing by `10^decimals` converts to token amounts. The credit leg reads `to_owner` so the answer lands on wallets rather than on their token accounts. ```sql theme={null} select leg.account_address, sum(leg.balance_change_raw) / pow(10, tokens.decimals) as net_change from `facts_tokens.transfers` as movements cross join unnest([ struct(movements.from_address as account_address, -cast(movements.amount_raw as bignumeric) as balance_change_raw), struct(coalesce(movements.to_owner, movements.to_address) as account_address, cast(movements.amount_raw as bignumeric) as balance_change_raw) ]) as leg join `dimensions.tokens` as tokens on tokens.token_id = movements.token_id where movements.partition_key >= timestamp('2026-08-01') and movements.partition_key < timestamp('2026-09-01') and movements.block_timestamp >= timestamp('2026-08-20') and movements.block_timestamp < timestamp('2026-08-21') and movements.chain_id = 'solana' and movements.token_address = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' and leg.account_address is not null group by leg.account_address, tokens.decimals order by net_change desc limit 20 ``` **Current holders** **List the largest current holders of one Solana mint.** An account here is an SPL token account rather than the wallet that owns it, so a wallet spread across several accounts appears once per account; the returned `balance` is already converted out of raw units. Each call adds up the token's whole movement history, so a one-off holder set costs a full scan; [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'solana', 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', 'spl' ) order by balance desc limit 20 ``` **Balance history** **Trace the largest holding account's balance over time.** Taking the account from the latest-balances function keeps the query runnable unchanged; the historical function returns a row only on the days the balance moved, so the balance on any other date is the latest row at or before it. The function replays the same history, so it costs a full scan of the token as well. ```sql theme={null} with largest as ( select account_address from `functions.calculate_latest_token_balances`( 'solana', 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', 'spl' ) order by balance desc limit 1 ) select history.balance_date, history.balance from `functions.calculate_historical_eod_token_balances`( 'solana', 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', 'spl' ) as history join largest using (account_address) order by history.balance_date desc limit 20 ``` **Daily price** **Read one Solana mint's daily price.** Each row is the midnight UTC price in USD, and `token_id` is the mint address and the chain joined with a dash. ```sql theme={null} select prices.timestamp, tokens.symbol, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.timestamp >= timestamp('2026-08-16') and prices.timestamp < timestamp('2026-08-23') and prices.token_id = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v-solana' order by prices.timestamp ``` # Astar Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/astar The standardized Astar tables. The `astar` dataset holds the standardized Astar tables. History starts 2021-12. Every column is documented at [Substrate ▸ Overview](/docs/catalog/chain-verticals/substrate/index). ## Tables
Table Since
`blocks` 2021-12
`events` 2021-12
`extrinsics` 2021-12
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily extrinsics** **Count daily extrinsics over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as extrinsics from `astar.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Chainflip Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/chainflip The standardized Chainflip tables. The `chainflip` dataset holds the standardized Chainflip tables. History starts 2023-11. Every column is documented at [Substrate ▸ Overview](/docs/catalog/chain-verticals/substrate/index). ## Tables
Table Since
`blocks` 2023-11
`events` 2023-11
`extrinsics` 2023-11
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily extrinsics** **Count daily extrinsics over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as extrinsics from `chainflip.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Energy Web Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/energyweb The standardized Energy Web tables. The `energyweb` dataset holds the standardized Energy Web tables. History starts 2023-10. Every column is documented at [Substrate ▸ Overview](/docs/catalog/chain-verticals/substrate/index). ## Tables
Table Since
`blocks` 2023-10
`events` 2023-10
`extrinsics` 2023-10
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily extrinsics** **Count daily extrinsics over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as extrinsics from `energyweb.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Hydration Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/hydradx The standardized Hydration tables. The `hydradx` dataset holds the standardized Hydration tables. History starts 2022-03. Every column is documented at [Substrate ▸ Overview](/docs/catalog/chain-verticals/substrate/index). ## Tables
Table Since
`blocks` 2022-03
`events` 2022-03
`extrinsics` 2022-03
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily extrinsics** **Count daily extrinsics over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as extrinsics from `hydradx.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Substrate ecosystem Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/index Standardized blocks, extrinsics and events for every Substrate chain. Substrate is the framework Polkadot and the chains connected to it are built with. These chains call a transaction an extrinsic, and running one produces events: the chain's notes on what happened. That gives every chain here the same three tables, `blocks`, `extrinsics` and `events`, in one dataset per chain. The [Tables](#tables) section below says what each table holds and lists the columns once for the whole family. ## Chains
Chain `chain_id` blocks events extrinsics
Astar `astar` ✓ ✓ ✓
Chainflip `chainflip` ✓ ✓ ✓
Energy Web `energyweb` ✓ ✓ ✓
Hydration `hydradx` ✓ ✓ ✓
Kusama `kusama` ✓ ✓ ✓
Litentry `litentry` ✓ ✓ ✓
peaq `peaq` ✓ ✓ ✓
Polkadot `polkadot` ✓ ✓ ✓
Polkadot Asset Hub `polkadotassethub` ✓ ✓ ✓
Polkadot Bridge Hub `polkadotbridgehub` ✓ ✓ ✓
Polkadot Collectives `polkadotcollectives` ✓ ✓ ✓
Polkadot Coretime `polkadotcoretime` ✓ ✓ ✓
Polkadot People `polkadotpeople` ✓ ✓ ✓
## Tables Substrate is the framework Polkadot and its parachains are built with, and every chain built that way has the same three core tables with the same columns. The schemas below are read from `polkadot`, and apply to every chain listed on the [Substrate overview](/docs/catalog/chain-verticals/substrate/index). Three words to know before the tables. An **extrinsic** is what these chains call a transaction: something submitted from outside the chain for it to act on. A **pallet** is one module of the chain's own code, such as balances, staking or governance, and an extrinsic names the pallet and the method it wants. An **event** is a note the chain writes about what happened while running one. `extrinsics` and `events` are split by day on `block_timestamp`, and `blocks` on `timestamp`. Filter on that column in every query: with a filter the query reads only the days you asked for, without one it reads the whole table. **blocks** A block is a batch of extrinsics added to the chain. `blocks` contains one row per block.
Column Type Description
`relay_chain` `STRING` The main chain this one connects to, Polkadot or Kusama.
`chain` `STRING` The chain name.
`timestamp` `TIMESTAMP` The time the block was produced. Partition column.
`number` `INT64` The block number.
`block_hash` `STRING` The hash of the block.
`parent_hash` `STRING` The hash of the parent block.
`state_root` `STRING` The root hash of the state trie.
`extrinsics_root` `STRING` The root hash of the extrinsics trie.
`author_id` `STRING` The account that authored the block.
`finalized` `BOOL` Whether the block is finalized.
`block_date` `TIMESTAMP` The block timestamp truncated to the day.
`extrinsics_count` `INT64` The number of extrinsics in the block.
**Daily blocks and extrinsics** **Count blocks and total extrinsics per day over one week.** ```sql theme={null} select timestamp_trunc(timestamp, day) as day, count(*) as blocks, sum(extrinsics_count) as extrinsics from `polkadot.blocks` where timestamp >= timestamp('2026-08-16') and timestamp < timestamp('2026-08-23') group by day order by day ``` **extrinsics** `extrinsics` contains one row per extrinsic. Group by `pallet` and `method` to see what the chain was asked to do; the extrinsics the chain itself submits leave `signature` null and `pays_fee` false.
Column Type Description
`relay_chain` `STRING` The main chain this one connects to, Polkadot or Kusama.
`chain` `STRING` The chain name.
`block_number` `INT64` The number of the containing block.
`block_timestamp` `TIMESTAMP` The time of the containing block. Partition column.
`block_hash` `STRING` The hash of the containing block.
`pallet` `STRING` The part of the chain's code the call goes to, such as balances or staking.
`method` `STRING` The method called in that pallet.
`signature` `STRING` Who signed the extrinsic and their proof. Empty when the chain submitted it itself.
`id` `STRING` The identifier of the extrinsic.
`nonce` `INT64` The sender's nonce.
`args` `JSON` The call arguments.
`tip` `BIGNUMERIC` The tip paid to the block author.
`extrinsic_hash` `STRING` The hash of the extrinsic.
`extrinsic_id` `STRING` The block-number-and-index identifier of the extrinsic.
`info` `JSON` What running it cost, including its weight and fee class.
`immortal_era` `NUMERIC` The mortality setting of the extrinsic.
`success` `BOOL` Whether the extrinsic succeeded.
`pays_fee` `BOOL` Whether the extrinsic pays a fee.
**Pallet calls** **Rank pallet calls by executed extrinsics over one week.** ```sql theme={null} select pallet, method, count(*) as extrinsics from `polkadot.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by pallet, method order by extrinsics desc limit 20 ``` **events** `events` contains one row per event, each linked back to the extrinsic that produced it. Watch the column names here: `pallet` and `method` describe that extrinsic, while `event_pallet` and `event_method` describe the event itself.
Column Type Description
`relay_chain` `STRING` The main chain this one connects to, Polkadot or Kusama.
`chain` `STRING` The chain name.
`block_number` `INT64` The number of the containing block.
`block_timestamp` `TIMESTAMP` The time of the containing block. Partition column.
`block_hash` `STRING` The hash of the containing block.
`pallet` `STRING` The pallet of the extrinsic that produced the event, not of the event itself.
`method` `STRING` The method of that extrinsic.
`id` `STRING` The identifier of the event.
`extrinsic_hash` `STRING` The hash of the producing extrinsic.
`extrinsic_id` `STRING` The identifier of the producing extrinsic.
`success` `BOOL` Whether the producing extrinsic succeeded.
`event_method` `STRING` The method of the event itself.
`event_pallet` `STRING` The pallet that emitted the event.
`event_data` `ARRAY` The event payload fields.
`event_index` `INT64` The position of the event within the block.
`event_type` `STRING` The type label of the event.
**Event-emitting pallets** **Rank event-emitting pallets and methods over one week.** ```sql theme={null} select event_pallet, event_method, count(*) as events from `polkadot.events` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by event_pallet, event_method order by events desc limit 20 ``` ## Exceptions Polkadot adds two tables to the three: `chain_ids`, a small lookup table, and `initialize_finalize_events`, which holds the events the chain writes at the start and end of a block rather than while running an extrinsic. Every other chain here has exactly the three core tables. # Kusama Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/kusama The standardized Kusama tables. The `kusama` dataset holds the standardized Kusama tables. History starts 2019-11. Every column is documented at [Substrate ▸ Overview](/docs/catalog/chain-verticals/substrate/index). ## Tables
Table Since
`blocks` 2019-11
`events` 2019-11
`extrinsics` 2019-11
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily extrinsics** **Count daily extrinsics over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as extrinsics from `kusama.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Litentry Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/litentry The standardized Litentry tables. The `litentry` dataset holds the standardized Litentry tables. History starts 2022-06. Every column is documented at [Substrate ▸ Overview](/docs/catalog/chain-verticals/substrate/index). ## Tables
Table Since
`blocks` 2022-06
`events` 2022-06
`extrinsics` 2022-06
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily extrinsics** **Count daily extrinsics over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as extrinsics from `litentry.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # peaq Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/peaq The standardized peaq tables. The `peaq` dataset holds the standardized peaq tables. History starts 2024-01. Every column is documented at [Substrate ▸ Overview](/docs/catalog/chain-verticals/substrate/index). ## Tables
Table Since
`blocks` 2024-01
`events` 2024-01
`extrinsics` 2024-01
## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Daily extrinsics** **Count daily extrinsics over one week.** ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as extrinsics from `peaq.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` # Polkadot Source: https://tokenterminal.com/docs/catalog/chain-verticals/substrate/polkadot The Polkadot relay chain and its system chains, from June 2020. Polkadot is a relay chain with a set of system chains beside it, each handling one job of its own. Every one is its own dataset, queried as `.`, and all of them have the same three core tables. The relay chain has two more.
Chain `chain_id` Since What it holds
Relay chain `polkadot` 2020-06 Consensus and the chains connected to it.
Asset Hub `polkadotassethub` 2021-12 Fungible and non-fungible assets. Its tokens reach the token list.
Bridge Hub `polkadotbridgehub` 2023-05 Bridges from Polkadot to other networks.
Collectives `polkadotcollectives` 2022-11 On-chain bodies, including the Technical Fellowship.
Coretime `polkadotcoretime` 2024-09 Sales of blockspace to the chains that use it.
People `polkadotpeople` 2024-07 Identities, which moved off the relay chain onto their own.
Every column is documented at [Substrate ▸ Overview](/docs/catalog/chain-verticals/substrate/index). Asset Hub is where Polkadot's tokens live, and those reach the catalog's token list. [Chains](/docs/catalog/chains/index) covers the list of chains and the daily tables built on it. [Tokens](/docs/catalog/tokens/index) covers the token list. ## Tables Every chain above has `blocks`, `extrinsics` and `events`. The relay chain has two more.
Table Chains Description
`blocks` All One row per block, with its author and extrinsic count.
`extrinsics` All One row per extrinsic, the Substrate equivalent of a transaction.
`events` All One row per event emitted during block execution.
`initialize_finalize_events` `polkadot` Events emitted while a block is initialized and finalized.
`chain_ids` `polkadot` A mapping of numeric ids to chain identifiers.
`initialize_finalize_events` has the same columns as `events`; it was retired on 2024-07-29 and its history ends there. `chain_ids` is unpartitioned and has two columns, `id` and `chain_id`. ## Sample queries > [!WARNING] > > The tables split by day on `block_timestamp` (`blocks` on `timestamp`). Bound that column in every query; without a bound the query reads the whole table. **Event-emitting pallets** **Rank event-emitting pallets on the relay chain on one day.** ```sql theme={null} select event_pallet, count(*) as events from `polkadot.events` where block_timestamp >= timestamp('2026-08-20') and block_timestamp < timestamp('2026-08-21') group by event_pallet order by events desc limit 20 ``` **One system chain** **Count daily extrinsics on Asset Hub over one week.** Swap the dataset name for any other chain in the table above; the shape is the same. ```sql theme={null} select timestamp_trunc(block_timestamp, day) as day, count(*) as extrinsics from `polkadotassethub.extrinsics` where block_timestamp >= timestamp('2026-08-16') and block_timestamp < timestamp('2026-08-23') group by day order by day ``` **Chain entry lookup** **Look up Polkadot's chain entry and the project it belongs to.** ```sql theme={null} select chains.chain_id, chains.name as chain_name, projects.name as project_name, projects.primary_market_sector from `dimensions.chains` as chains join `dimensions.projects` as projects using (project_id) where chains.chain_id = 'polkadot' ``` # Chains Source: https://tokenterminal.com/docs/catalog/chains/index Blockchains, the project behind each one, and the fees and revenue they earn. A chain is a blockchain: the network that transactions run on, such as Ethereum, Base or Solana. Each chain matches one to one with the [project](/docs/catalog/projects/index) that runs it or with one of that project's [apps](/docs/catalog/apps/index), and `dimensions.chains` names that project. A chain's own figures are the gas and sequencer fees users pay to transact on it. Transaction-level tables sit per chain under [Chain verticals](/docs/catalog/chain-verticals/evm/index), one row per transaction. ## Coverage One row per chain, ticked for every measure it reports. Where a chain's earnings arrive as trading fees (HyperCore's order books), they sit with the [apps](/docs/catalog/apps/metrics) that charge them.
Chain Validators Fees Supply-side fees Revenue Contract deployers Contracts deployed Transaction count Transactions per second Average transaction fee Median transaction fee Block time
`acala`✓✗✗✗✓✓✓✓✓✗✓
`acalaevm`✗✗✗✗✗✗✓✗✓✗✗
`ajuna`✓✗✗✗✗✗✓✓✓✗✓
`alephzeroevm`✗✗✗✗✓✓✓✓✓✓✓
`algorand`✓✓✓✓✓✓✓✓✓✓✓
`anime`✗✗✗✗✗✗✓✓✗✗✓
`apechain`✗✗✗✗✗✗✓✓✗✗✓
`apertum`✗✗✗✗✓✗✓✓✗✗✗
`aptos`✗✓✓✓✓✓✓✓✓✓✓
`arbitrum`✗✓✓✓✓✓✓✓✓✓✓
`arc`✗✗✗✗✓✓✓✓✓✓✓
`artery`✗✗✗✗✓✗✓✓✗✗✗
`astar`✓✓✓✓✓✓✓✓✓✗✓
`avalanche`✗✓✓✓✓✓✓✓✓✓✓
`aventus`✓✗✗✗✗✗✓✓✓✗✓
`base`✗✓✓✓✓✓✓✓✓✓✓
`berachain`✗✓✓✓✓✓✓✓✓✓✓
`bifrostio`✓✗✗✗✗✗✓✓✓✗✓
`bifrostioevm`✗✗✗✗✗✗✓✗✓✗✗
`bitcoin`✗✓✓✓✗✗✓✓✓✓✓
`blast`✗✓✓✓✓✓✓✓✓✓✓
`bob`✗✗✗✗✗✗✓✓✗✗✓
`bobanetwork`✗✓✗✓✓✓✓✓✓✓✓
`bsc`✓✓✓✓✓✓✓✓✓✓✓
`buildonbeam`✗✗✗✗✓✗✓✓✗✗✗
`cardano`✓✓✓✓✓✓✓✓✓✓✓
`celestia`✓✓✓✓✗✗✓✓✓✓✓
`celo`✗✓✓✓✓✓✓✓✓✓✓
`chainflip`✓✓✗✓✗✗✓✓✓✓✓
`cosmos`✓✓✓✓✗✗✓✓✓✓✓
`darwinia`✓✗✗✗✗✗✓✓✓✗✓
`darwiniaevm`✗✗✗✗✗✗✓✗✓✗✗
`dexalot`✗✗✗✗✓✗✓✓✗✗✗
`dfk`✗✗✗✗✓✗✓✓✗✗✗
`dinarinetwork`✗✗✗✗✓✗✓✓✗✗✗
`dogecoin`✗✓✓✓✗✗✗✗✗✗✗
`dydx`✓✓✓✗✗✗✓✓✓✗✓
`energyweb`✓✓✓✓✗✗✓✓✓✗✓
`ethereum`✓✓✓✓✓✓✓✓✓✓✓
`fantom`✗✗✗✗✗✗✓✗✓✓✓
`flow`✓✓✓✓✓✓✓✓✓✓✓
`flowevm`✗✓✓✓✓✓✓✗✓✗✗
`fraxtal`✗✓✗✓✓✓✓✓✓✓✓
`frequency`✓✗✗✗✗✗✓✓✗✗✓
`galactica`✗✗✗✗✗✗✓✓✗✗✓
`gnosis`✗✓✓✓✓✓✓✓✓✓✓
`gravityalpha`✗✓✓✓✓✓✓✓✓✓✓
`growth`✗✗✗✗✓✗✓✓✗✗✗
`gunz`✗✗✗✗✓✗✓✓✗✗✗
`hedera`✓✓✓✓✓✓✓✓✓✓✓
`humanity`✗✗✗✗✗✗✓✓✗✗✓
`hydradx`✓✓✗✓✓✓✓✓✓✗✓
`hydradxevm`✗✗✗✗✗✗✓✗✓✗✗
`hyperbridge`✓✗✗✗✗✗✓✓✓✗✓
`hyperevm`✗✓✓✓✗✗✓✓✓✗✓
`immutablezkevm`✗✓✓✓✓✓✓✓✓✗✓
`injective`✗✗✗✗✓✓✓✓✓✓✓
`injectiveevm`✗✓✓✓✗✗✓✓✗✗✗
`ink`✗✓✗✓✓✓✓✓✓✓✓
`interlay`✗✗✗✗✗✗✓✓✗✗✓
`internetcomputer`✓✗✗✗✗✓✓✓✓✗✓
`invarch`✗✗✗✗✗✗✓✓✗✗✓
`iotex`✗✓✓✓✗✗✓✓✓✓✓
`katananetwork`✗✓✓✓✓✓✓✓✓✓✓
`kilt`✓✗✗✗✗✗✓✓✓✗✓
`kinto`✗✗✗✗✗✗✓✗✗✗✓
`kite`✗✗✗✗✓✗✓✓✗✗✗
`kusama`✗✓✓✓✗✗✓✓✓✗✓
`lamina1`✗✗✗✗✓✗✓✓✗✗✗
`linea`✗✓✗✓✓✓✓✓✓✓✓
`litecoin`✗✓✓✓✗✗✗✗✗✗✗
`litentry`✓✓✓✓✗✗✓✓✓✗✓
`litentryevm`✗✗✗✗✗✗✓✗✓✗✗
`manta`✗✓✓✓✓✓✓✓✓✓✓
`mantaatlantic`✗✗✗✗✗✗✓✓✗✗✗
`mantra`✓✗✗✗✗✗✓✓✓✓✓
`mantraevm`✗✗✗✗✗✗✓✓✓✗✗
`megaeth`✗✓✓✓✗✗✓✓✓✓✓
`metis`✗✗✗✗✗✗✓✓✗✗✓
`midnight`✗✗✗✗✗✓✓✓✗✗✓
`mode`✗✗✗✗✗✗✓✓✗✗✓
`monad`✗✓✓✓✓✓✓✓✓✓✓
`moonbeam`✓✗✗✗✓✓✓✓✓✗✓
`moonbeamevm`✗✗✗✗✗✗✓✗✓✗✗
`movement`✗✗✗✗✓✓✓✓✓✓✓
`mythos`✗✗✗✗✗✗✓✓✓✗✓
`near`✓✓✓✓✓✓✓✓✓✓✓
`neuroweb`✗✗✗✗✓✓✓✓✓✗✓
`neurowebevm`✗✗✗✗✗✗✓✗✓✗✗
`nodle`✗✗✗✗✗✗✓✓✗✗✓
`opbnb`✗✓✓✓✓✓✓✓✓✓✓
`optimism`✗✓✓✓✓✓✓✓✓✓✓
`peaq`✗✓✓✓✗✗✓✓✓✗✓
`peaqevm`✗✗✗✗✗✗✓✗✓✗✗
`pendulum`✓✗✗✗✗✗✓✓✓✗✓
`phala`✓✗✗✗✗✗✓✓✓✗✓
`plasma`✓✓✓✓✓✓✓✓✓✓✓
`polimec`✗✗✗✗✗✗✓✗✗✗✓
`polkadex`✗✗✗✗✗✗✓✓✗✗✓
`polkadot`✓✓✓✓✗✗✓✓✓✓✓
`polkadotassethub`✗✗✗✗✗✗✓✗✗✗✗
`polkadotbridgehub`✗✗✗✗✗✗✓✗✗✗✗
`polkadotcollectives`✗✗✗✗✗✗✓✗✗✗✗
`polkadotcoretime`✗✗✗✗✗✗✓✗✗✗✗
`polkadotpeople`✗✗✗✗✗✗✓✗✗✗✗
`polygon`✗✓✓✓✓✓✓✓✓✓✓
`qchain`✗✗✗✗✓✗✓✓✗✗✗
`ripple`✗✓✓✓✗✗✓✓✓✓✓
`robinhoodchain`✗✓✗✓✓✓✓✓✓✓✓
`robonomics`✗✗✗✗✗✗✓✓✓✗✓
`ronin`✗✗✗✗✗✗✓✓✓✓✓
`rootstock`✗✓✓✓✓✓✓✓✓✓✓
`scroll`✗✓✗✓✓✓✓✓✓✓✓
`seinetwork`✗✗✗✗✗✗✓✓✓✗✓
`settlus`✗✗✗✗✗✗✓✓✗✗✓
`shape`✗✗✗✗✗✗✓✓✗✗✓
`solana`✓✓✓✓✓✓✓✓✓✓✓
`soneium`✗✗✗✗✗✗✓✓✗✗✓
`sonic`✗✓✓✓✓✓✓✓✓✓✓
`stacks`✗✓✓✓✓✓✓✓✓✓✓
`starknet`✗✓✓✓✓✓✓✓✓✓✓
`stellar`✗✓✓✓✓✓✓✓✓✓✓
`story`✗✗✗✗✗✗✓✓✗✗✓
`straitsxl1`✗✗✗✗✓✗✓✓✗✗✗
`subsocial`✗✗✗✗✗✗✓✓✗✗✓
`sui`✓✓✓✓✓✓✓✓✓✓✓
`superseed`✗✗✗✗✗✗✓✓✗✗✓
`tempo`✗✓✓✓✓✓✓✓✓✓✓
`terra`✗✗✗✗✓✓✓✗✓✗✓
`titanl1`✗✗✗✗✓✗✓✓✗✗✗
`tixchain`✗✗✗✗✓✗✓✓✗✗✗
`tomatochain`✗✗✗✗✓✗✓✓✗✗✗
`ton`✗✓✓✓✗✓✓✓✓✓✓
`tron`✓✓✓✓✓✓✓✓✓✓✓
`turingchain`✗✗✗✗✓✗✓✓✗✗✗
`unichain`✗✓✗✓✓✓✓✓✓✓✓
`uniquenetwork`✗✗✗✗✓✓✓✓✓✗✓
`uniquenetworkevm`✗✗✗✗✗✗✓✗✓✗✗
`uptn`✗✗✗✗✓✗✓✓✗✗✗
`valuex`✗✗✗✗✓✗✓✓✗✗✗
`viction`✗✓✓✓✗✗✓✓✓✓✓
`worldchain`✗✗✗✗✗✗✓✓✗✗✓
`worldmobilechain`✗✓✓✓✗✗✓✓✓✓✓
`xai`✗✗✗✗✓✓✓✗✓✓✓
`xdc`✓✓✓✓✗✗✓✓✓✓✓
`xlayer`✗✓✓✓✓✓✓✓✓✓✓
`zcash`✗✓✓✓✗✗✗✗✗✗✗
`zeitgeist`✓✗✗✗✗✗✓✓✗✗✓
`zksyncera`✗✓✓✓✓✓✓✓✓✓✓
## Tables [Metrics](/docs/catalog/chains/metrics) holds the daily fee tables and example queries. [Registry](/docs/catalog/chains/registry) holds the identity table that maps a chain to the project running it. [Screener](/docs/catalog/chains/screener) holds one row per chain as of the last complete day, for ranking chains against each other. # Metrics Source: https://tokenterminal.com/docs/catalog/chains/metrics Daily chain fees, revenue, and the fees passed on. The chain's own figures: fees and revenue, costs and incentives, active addresses, transactions and network measures. One row per thing per day, at one grain: chain. ## Tables > [!NOTE] > > Daily HyperEVM gas fees and revenue cover closed UTC days and follow HyperEVM’s availability cutoff. A tab per grain. [Coverage](/docs/catalog/chains) shows which chains report which measure. **Chain** One row per chain per day. Every table holds `timestamp`, `chain_id` and one value column.
Table Value column What it holds
`metrics_chains.daily_active_addresses_daily` `daily_active_addresses` Distinct addresses transacting on the chain per day.
`metrics_chains.monthly_active_addresses_daily` `monthly_active_addresses` Distinct addresses transacting on the chain over a rolling 30 days.
`metrics_chains.weekly_active_addresses_daily` `weekly_active_addresses` Distinct addresses transacting on the chain over a rolling 7 days.
`metrics_chains.block_time_average_daily` `block_time_average` Average time between blocks, in milliseconds.
`metrics_chains.bridge_deposits_daily` `bridge_deposits` USD value of assets held in the chain's canonical bridge on the chain it settles to.
`metrics_chains.daily_contract_deployers_daily` `daily_contract_deployers` Distinct addresses deploying contracts.
`metrics_chains.contract_deployment_count_daily` `contract_deployment_count` Contracts deployed on the chain.
`metrics_chains.cost_of_revenue_daily` `cost_of_revenue` The chain's direct cost of revenue, such as data posted to the chain it settles to.
`metrics_chains.expenses_daily` `expenses` What the chain spent, in USD.
`metrics_chains.fees_daily` `fees` Fees paid to the chain (gas / sequencer).
`metrics_chains.fees_supply_side_daily` `fees_supply_side` Fees the chain does not retain (pass-throughs to builders / operators); fees = revenue + fees\_supply\_side. 0 where there are no pass-throughs, e.g. HyperEVM gas.
`metrics_chains.validators_daily` `validators` Number of validators securing the chain's consensus.
`metrics_chains.revenue_daily` `revenue` Revenue retained by the chain (gas / sequencer fees net of pass-throughs; equals fees where there are none, e.g. HyperEVM).
`metrics_chains.staking_market_cap_daily` `staking_market_cap` USD value of the chain's native token staked to secure the network.
`metrics_chains.token_incentives_daily` `token_incentives` Value of tokens the chain distributed as incentives.
`metrics_chains.transaction_count_daily` `transaction_count` Transactions processed by the chain.
`metrics_chains.transaction_fee_average_daily` `transaction_fee_average` Average fee per transaction.
`metrics_chains.transaction_fee_median_daily` `transaction_fee_median` Median fee per transaction.
`metrics_chains.transactions_per_second_daily` `transactions_per_second` Average transactions per second.
**Apps on the chain** One row per chain per day. These are what the apps deployed on the chain do there. Every table holds `timestamp`, `chain_id` and one value column. The chain's own operator is left out, so a chain's own fees sit in the Chain tab and never in both.
Table Value column What it holds
`metrics_chains.app_monthly_active_addresses_daily` `app_monthly_active_addresses` Distinct addresses using the apps' contracts on the chain over a rolling 30 days, each app's count added up, so an address using two apps counts twice.
`metrics_chains.app_active_loans_daily` `app_active_loans` Open loans in the apps on the chain, USD.
`metrics_chains.app_assets_staked_daily` `app_assets_staked` Assets staked with the apps on the chain, USD.
`metrics_chains.app_bridged_supply_daily` `app_bridged_supply` Stablecoins bridged onto the chain, USD.
`metrics_chains.app_fees_daily` `app_fees` Fees paid to the apps on the chain, USD.
`metrics_chains.app_gas_used_daily` `app_gas_used` Gas consumed by transactions calling the apps' contracts on the chain.
`metrics_chains.app_outstanding_supply_daily` `app_outstanding_supply` Stablecoin supply issued on the chain, USD.
`metrics_chains.app_trading_volume_daily` `app_trading_volume` Trading volume of the exchanges on the chain, USD. Derivatives venues and aggregators are left out: an aggregator's volume is counted at the exchange it routes to.
`metrics_chains.app_transaction_count_contracts_daily` `app_transaction_count_contracts` Transactions calling the apps' contracts on the chain.
`metrics_chains.app_tvl_daily` `app_tvl` Value locked in the apps on the chain, USD.
`metrics_chains.app_monthly_active_users_daily` `app_monthly_active_users` Monthly active users of the apps on the chain, each app's count added up, so a user of two apps counts twice.
## Sample queries **One chain's series** Each measure is its own table, so a row with both is a join on `chain_id` and `timestamp`. Bound the day range on every side, or the unbounded side reads its whole table. ```sql theme={null} with fees as ( select timestamp, fees from `metrics_chains.fees_daily` where chain_id = 'ethereum' and timestamp >= timestamp('2026-06-01') ), revenue as ( select timestamp, revenue from `metrics_chains.revenue_daily` where chain_id = 'ethereum' and timestamp >= timestamp('2026-06-01') ) select timestamp, fees.fees, revenue.revenue from fees full join revenue using (timestamp) order by timestamp ``` **Monthly fees** `fees` adds up over time, so a month is its days added together. Every table here is partitioned by `timestamp` and clustered on `chain_id`, so bounding both reads the least. ```sql theme={null} select timestamp_trunc(timestamp, month) as month, sum(fees) as fees from `metrics_chains.fees_daily` where chain_id = 'ethereum' and timestamp >= timestamp('2026-01-01') group by month order by month ``` **Fees by project** These tables key on `chain_id` alone, so attributing a chain's fees to the project running it means joining `dimensions.chains`. A project that runs several chains lands one row, with its chains added together. ```sql theme={null} select chains.project_id, sum(daily.fees) as fees from `metrics_chains.fees_daily` as daily join `dimensions.chains` as chains using (chain_id) where daily.timestamp = timestamp('2026-08-01') group by chains.project_id order by fees desc ``` **Fee split** `fees` is `revenue` plus `fees_supply_side`. Ethereum burns base and blob fees into `revenue` and pays priority tips to validators as `fees_supply_side`, while a chain that keeps all of its gas reads `revenue` equal to `fees`. ```sql theme={null} with fees as ( select chain_id, fees from `metrics_chains.fees_daily` where timestamp = timestamp('2026-08-01') ), revenue as ( select chain_id, revenue from `metrics_chains.revenue_daily` where timestamp = timestamp('2026-08-01') ), supply_side as ( select chain_id, fees_supply_side from `metrics_chains.fees_supply_side_daily` where timestamp = timestamp('2026-08-01') ) select chain_id, fees.fees, revenue.revenue, supply_side.fees_supply_side from fees left join revenue using (chain_id) left join supply_side using (chain_id) order by fees desc ``` # Registry Source: https://tokenterminal.com/docs/catalog/chains/registry Chain names, and the project that runs each one. The identity table behind every chain figure. Every metric table joins to it, and [Coverage](/docs/catalog/chains) introduces the grain. ## Columns
Column Type Description
`chain_id` `STRING` Identifier of the chain. Every table that mentions a chain joins on this.
`project_id` `STRING` Project that runs the chain. Defaults to the chain's own project, and names another project where that project's app runs the chain: `unichain` resolves to `uniswap`.
`name` `STRING` Display name.
`logo` `STRING` The chain's logo URL, with its content hash on the end so a changed logo is a new URL.
`market_sectors` `ARRAY` The market sectors the chain belongs to, most relevant first.
`primary_market_sector` `STRING` The first of `market_sectors`.
`chain_family` `STRING` `evm` or `svm`, null when the chain is unmapped. Every chain in one family is summed together for a key's activity, such as `region` on [Accounts ▸ Registry](/docs/catalog/accounts/registry).
## Sample queries **Chain identity** `chain_id` is the value every other table keys on, and this is the table that spells out what it stands for. ```sql theme={null} select chain_id, name, project_id from `dimensions.chains` where chain_id = 'hyperevm' ``` **Chains for one project** `project_id` is the one place a chain's operator is recorded, so a change of operator reaches every query that joins here. ```sql theme={null} select chain_id, name from `dimensions.chains` where project_id = 'uniswap' order by chain_id ``` **Chain to project** The daily chain tables key on `chain_id` alone, so putting a project's name beside a chain's figures means joining `dimensions.projects` through `project_id`. ```sql theme={null} select chains.chain_id, chains.name, chains.project_id, projects.name as project_name from `dimensions.chains` as chains join `dimensions.projects` as projects using (project_id) order by chains.chain_id ``` # Screener Source: https://tokenterminal.com/docs/catalog/chains/screener Every chain's latest figures and its apps' figures, with averages, totals and changes over six windows, in one row. One row per chain in `screeners.chains`, every figure as of `as_of`, the last complete day. Each measure has a column per window and aggregation, named `__`: `fees_30d_sum` is the fees paid to the chain over the 30 days ending on `as_of`, and `app_fees_30d_sum` is the fees paid to the apps on it. ## Columns **Keys** The two key columns, then one FLOAT64 column per measure, window and aggregation. Every row is a chain in `dimensions.chains`, so the join on `chain_id` always matches.
Column Type Description
`as_of`TIMESTAMPThe last complete day, the same on every row. Every window ends on it.
`chain_id`STRINGChain the row belongs to, such as `ethereum`; joins `dimensions.chains`.
**Aggregations** A window is `1d`, `7d`, `30d`, `90d`, `180d` or `365d`, and spans that many days ending on `as_of`, while the `max_` columns read the whole history. Which aggregations a measure has follows its `over_time` in [Metric definitions](/docs/catalog/metric-definitions): only a measure whose `over_time` is `sum` has `sum`.
Column What it holds
`__avg`Mean of the daily values over the window.
`__sum`Total of the daily values over the window. Flows only: the measures ticked under Sum.
`__change`A comparison of two aggregations: the value on `as_of` against the value one window earlier, as `(now - then) / abs(then)`. Null when either value is missing or the earlier one is 0.
`__trend`A comparison of two aggregations: the window's average against the average of the window before it, as `(avg - prior) / abs(prior)`. Null unless the window before has a value on every one of its days, and null when its average is 0.
`_max_latest`The value on `as_of`. Null when there is none.
`_max_ath`The highest daily value over the chain's whole history.
`_max_atl`The lowest daily value over the chain's whole history.
**Measures** Every measure has the `avg`, `change`, `trend` and `max_` columns, and the flows also have `sum`. The `app_` measures are the apps on the chain added together. Price, market cap and developers sit on the [project screener](/docs/catalog/projects/screener), for the project `dimensions.chains` names in `project_id`.
Measure Sum What it holds
`daily_active_addresses`✗Distinct addresses transacting on the chain per day.
`monthly_active_addresses`✗Distinct addresses transacting on the chain over a rolling 30 days.
`weekly_active_addresses`✗Distinct addresses transacting on the chain over a rolling 7 days.
`app_monthly_active_addresses`✗Distinct addresses using the apps' contracts on the chain over a rolling 30 days, each app's count added up, so an address using two apps counts twice.
`app_active_loans`✗Open loans in the apps on the chain, USD.
`app_assets_staked`✗Assets staked with the apps on the chain, USD.
`app_bridged_supply`✗Stablecoins bridged onto the chain, USD.
`app_fees`✓Fees paid to the apps on the chain, USD.
`app_gas_used`✓Gas consumed by transactions calling the apps' contracts on the chain.
`app_outstanding_supply`✗Stablecoin supply issued on the chain, USD.
`app_trading_volume`✓Trading volume of the exchanges on the chain, USD. Derivatives venues and aggregators are left out: an aggregator's volume is counted at the exchange it routes to.
`app_transaction_count_contracts`✓Transactions calling the apps' contracts on the chain.
`app_tvl`✗Value locked in the apps on the chain, USD.
`app_monthly_active_users`✗Monthly active users of the apps on the chain, each app's count added up, so a user of two apps counts twice.
`block_time_average`✗Average time between blocks, in milliseconds.
`bridge_deposits`✗USD value of assets held in the chain's canonical bridge on the chain it settles to.
`daily_contract_deployers`✗Distinct addresses deploying contracts.
`contract_deployment_count`✓Contracts deployed on the chain.
`cost_of_revenue`✓The chain's direct cost of revenue, such as data posted to the chain it settles to.
`expenses`✓What the chain spent, in USD.
`fees`✓Fees paid to the chain (gas / sequencer).
`fees_supply_side`✓Fees the chain does not retain (pass-throughs to builders / operators); fees = revenue + fees\_supply\_side. 0 where there are no pass-throughs, e.g. HyperEVM gas.
`validators`✗Number of validators securing the chain's consensus.
`revenue`✓Revenue retained by the chain (gas / sequencer fees net of pass-throughs; equals fees where there are none, e.g. HyperEVM).
`staking_market_cap`✗USD value of the chain's native token staked to secure the network.
`token_incentives`✓Value of tokens the chain distributed as incentives.
`transaction_count`✓Transactions processed by the chain.
`transaction_fee_average`✗Average fee per transaction.
`transaction_fee_median`✗Median fee per transaction.
`transactions_per_second`✗Average transactions per second.
## Sample queries **One chain** Every column of one row shares the same `as_of`, so the figures read together. `fees` is what users paid the chain, and `app_fees` what they paid the apps running on it. ```sql theme={null} select as_of, fees_30d_sum, app_fees_30d_sum, transaction_count_30d_sum, app_tvl_max_latest, app_tvl_30d_change from `screeners.chains` where chain_id = 'ethereum' ``` **Top chains by app fees** `app_fees_30d_sum` is the fees paid to the apps on the chain over the 30 days ending on `as_of`. The join to `dimensions.chains` on `chain_id` adds the name. ```sql theme={null} select chains.name, screener.app_fees_30d_sum, screener.transaction_count_30d_sum, screener.app_fees_30d_trend from `screeners.chains` as screener join `dimensions.chains` as chains using (chain_id) where screener.app_fees_30d_sum is not null order by screener.app_fees_30d_sum desc limit 25 ``` **Chain fees against app fees** Both sides are 30-day totals over the same window, so their ratio compares the gas users paid the chain with the fees they paid its apps. The app fee floor keeps a small base from dominating the ranking. ```sql theme={null} select chains.name, screener.fees_30d_sum, screener.app_fees_30d_sum, safe_divide(screener.fees_30d_sum, screener.app_fees_30d_sum) as chain_to_app_fees from `screeners.chains` as screener join `dimensions.chains` as chains using (chain_id) where screener.app_fees_30d_sum > 100000 order by chain_to_app_fees desc limit 25 ``` # Changelog Source: https://tokenterminal.com/docs/catalog/changelog **October 20, 2026** **Breaking** * **[Superseed](/docs/catalog/chain-verticals/evm/superseed)**: Archive the Superseed chain. Its tables stay queryable, and the record ends on October 18, 2026. **Expanded** * **[Projects metrics](/docs/catalog/projects/metrics)**: * Extend to Papertrade, StonkFun, SSV Network, JustLend and Coinbase Wrapped Assets. * Extend Paxos with fees, supply-side fees and revenue from the reserve yield on PYUSD, USDG and BUSD. * **[Agentic payments](/docs/catalog/popular-datasets/agentic-payments)**: Extend to Celo, where the Celo Core Co. facilitator settles USDC, USDT and USAT over EIP-3009 and wARS, wBRL and wCOP over the Coinbase Permit2 proxy. * **[Avalanche raw](/docs/catalog/chain-verticals/evm/avalanche/raw)**: * Extend blocks with `blob_gas_used`, `excess_blob_gas`, `parent_beacon_block_root`, `timestamp_milliseconds`, `min_delay_excess`, `min_price_exponent`, `target_exponent`, `settled_excess`, `settled_gas_numerator`, `settled_gas_unix` and `settled_height`. * Extend transactions with `y_parity`, from December 2024. * **[ZKsync Era raw](/docs/catalog/chain-verticals/evm/zksyncera/raw)**: Extend transactions with `y_parity`, `access_list` and `receipt_l2_to_l1_logs`, with L2-to-L1 logs from February 2023. * **[Ethereum raw](/docs/catalog/chain-verticals/evm/ethereum/raw)**: Extend traces with `value_raw`, the exact value in wei as a string. * **[Base raw](/docs/catalog/chain-verticals/evm/base/raw)**: Extend traces with `value_raw`, the exact value in wei as a string. * **[Hyperliquid raw](/docs/catalog/chain-verticals/hyperliquid/raw)**: Extend `node_trades` with `block_number` and `trade_id`, and `twap` with `stop_price`, `trigger_price` and `trigger_above`. **Fixed** * **[ZKsync Era raw](/docs/catalog/chain-verticals/evm/zksyncera/raw)**: Fix the `l1_batch_number`, `l1_batch_tx_index`, `l1_batch_timestamp`, `receipt_l1_batch_number` and `receipt_l1_batch_tx_index` columns on blocks, transactions and logs to carry the sealed L1 batch from June 2024. * **[Hyperliquid raw](/docs/catalog/chain-verticals/hyperliquid/raw)**: * Fix `node_trades` to cover every day from March 2025, both sides of every HyperCore trade. * Fix `blocks` to carry each stream's full record count on every block. * **[Sui](/docs/catalog/chain-verticals/move/sui)**: * Fix `transaction_kind` to read `ProgrammableSystemTransaction` for programmable system transactions, and the expiration in `transaction_json` to read `ValidDuring` or `Validity`. * Fix `move_packages` to hold package publishes and upgrades only. **October 13, 2026** **Breaking** * **[Anime](/docs/catalog/chain-verticals/evm/anime)**: Archive the Anime chain. Its tables stay queryable, and the record ends on October 5, 2026. **New** * **[Fact sheets](/docs/catalog/popular-datasets/fact-sheets)**: Add the terms an issuer discloses for each tokenized asset, with the evidence behind each value and the security it references, the data behind the Explorer fact sheets. * **[Real-world assets registry](/docs/catalog/real-world-assets/registry)**: Add `dimensions.underlying_securities`, the security a tokenized stock or fund references with its identifiers from public registers, and its field labels in `dimensions.underlying_security_fields`. **Expanded** * **[Projects metrics](/docs/catalog/projects/metrics)**: * Extend to Fragment, Pons and Binance Bitcoin, and to Polymarket US under Polymarket. * Extend World Liberty Financial with fees and revenue from the USD1 reserve yield. * Extend Gearbox with `tvl` and `liquidation_volume`. * **[Blast raw](/docs/catalog/chain-verticals/evm/blast/raw)**: Extend blocks with `excess_blob_gas`, `blob_gas_used`, `parent_beacon_block_root`, `withdrawals_root` and `withdrawals`, transactions with `deposit_receipt_version`, `receipt_deposit_receipt_version` and `receipt_blob_gas_used`, and traces with `transaction_index`. **Fixed** * **[Projects metrics](/docs/catalog/projects/metrics)**: * Fix Polymarket fees to count Combos and every inflow to the fee recipient, token incentives to the current reward distributors, and rebates to supply side and cost of revenue. * Fix Axiom fees on Solana to count every fee payment, with the cashback traders receive as supply-side fees. * Fix Gearbox fees, revenue, incentives and earnings to accrue on Ethereum, Monad and Plasma. * **[Order book markets](/docs/catalog/markets/order-book-markets)**: Fix `asset_type` on 71 Hyperliquid and tradeXYZ HIP-3 markets. * **[Ethereum raw](/docs/catalog/chain-verticals/evm/ethereum/raw)**: Fix `beacon_validators` `withdrawal_address` to be populated for validators with compounding (0x02) withdrawal credentials. * **[Assets registry](/docs/catalog/assets/registry)**: Fix token reference classifications and separate the JAAA fund token from the JAAA ETF. **October 6, 2026** **Breaking** * **[Human's manual](/docs/catalog/humans-manual)**: Rename six breakdown datasets to `_by_`. Queries on `metrics_project_chains` read `metrics_projects_by_chain`, and the same holds for `metrics_app_chains`, `metrics_dex_pool_tokens`, `metrics_dex_pool_pairs`, `metrics_perp_market_tokens` and `metrics_order_book_market_tokens`. * **[Metric definitions](/docs/catalog/metric-definitions)**: Rename the measures to put the noun first, with the window in the noun and qualifiers after it. `user_dau` reads `daily_active_users` and `source_transfer_volume` reads `transfer_volume_source`, in table and column names alike. * **[Assets metrics](/docs/catalog/assets/metrics)**: Rename the seven `_total` measures for market cap, mints, redemptions and transfers to bare names. Queries on a `_total_daily` table and its `_total` column read the same name without `_total`, with values unchanged. * **[Projects registry](/docs/catalog/projects/registry)**: Remove the Unichain, opBNB and Immutable zkEVM projects, keeping their chains under Uniswap, BSC and Immutable. Queries on these project ids read `metrics_chains` with `chain_id` `unichain`, `opbnb` or `immutablezkevm`. * **[Projects metrics](/docs/catalog/projects/metrics)**: Remove the `unknown` and `offchain` chain ids from `metrics_projects_by_chain` and `metrics_apps_by_chain`. Those rows count at project and app grain. * **[Apps registry](/docs/catalog/apps/registry)**: * Rename the app `makerdao-lending` to `makerdao-issuance`, Sky's stablecoin issuance. Queries filter on `app_id = 'makerdao-issuance'`. * Rename the app `lighter-dex` to `lighter-app`, a derivatives app named Lighter. Queries filter on `app_id = 'lighter-app'`. * **[Financial statements](/docs/catalog/popular-datasets/financial-statements)**: * Restrict the statements to projects that report fees. The 20 projects with only treasury lines read `metrics_projects.treasury_daily` and `treasury_net_daily`. * Rename the measure columns to the new measure names. `user_dau` reads `daily_active_users` and `tokenholders` reads `token_holders`. * **[Disclosures](/docs/catalog/real-world-assets/disclosures)**: Remove `not_launched` from `issuance_status`. A program member the issuer's list does not name reads null. **New** * **[Project screener](/docs/catalog/projects/screener)**: Add `screeners.projects`, each project's latest value, all-time high and low, and its average, change and trend over six windows from 1 day to 365 days, for 60 measures. * **[Chain screener](/docs/catalog/chains/screener)**: Add `screeners.chains`, the same aggregations for 30 chain measures, the chain's own and its apps'. * **[Asset screener](/docs/catalog/assets/screener)**: Add `screeners.assets`, `screeners.assets_by_chain` and `screeners.asset_tokens`, the same aggregations per asset, per asset on each chain and per asset token. * **[User retention](/docs/catalog/popular-datasets/user-retention)**: Add `reports_projects.user_retention_monthly`, monthly signup cohorts for every project with the share of each cohort active in each of the twelve months from signup. * **[Attested country](/docs/catalog/accounts/attested-country)**: Add the country of residence Coinbase attested for a wallet, by address and chain family. * **[Assets registry](/docs/catalog/assets/registry)**: Add `dimensions.assets_by_chain`, every curated asset on each chain it is deployed to. * **[Assets metrics](/docs/catalog/assets/metrics)**: * Add the asset-by-chain grain, `metrics_assets_by_chain`. * Add DeFi TVL and DEX trading volume per asset, per asset and app, and per deployment and app, as `app_tvl` and `app_trading_volume`. * Add holders across every deployment of an asset. * **[Stablecoins metrics](/docs/catalog/stablecoins/metrics)**: Add the stablecoin-by-chain grain from `metrics_assets_by_chain`. * **[Real-world assets metrics](/docs/catalog/real-world-assets/metrics)**: Add the asset-by-chain grain from `metrics_assets_by_chain`. * **[Projects metrics](/docs/catalog/projects/metrics)**: * Add price-to-fees and price-to-revenue (circulating and fully diluted), take rate, token turnover and staking market cap per project. * Add token market data, contract activity and thirteen standardized measures per project, among them trade count, open interest and bridge deposits. * Add active addresses, contract transactions, gas used, token holders, treasury and expenses per project and chain. * **[Chains metrics](/docs/catalog/chains/metrics)**: * Add eleven `app_*` measures for what the apps on a chain do, from app TVL and fees to gas used and monthly active addresses. * Add daily, weekly and monthly active addresses, expenses, token incentives, cost of revenue and bridge deposits per chain. * Add transactions, transactions per second, block time, fees per transaction, validators, deployments and staked value per chain. * **[Apps metrics](/docs/catalog/apps/metrics)**: * Add the thirteen standardized measures at app grain. * Add expenses per app and per app and chain. * Add seventeen measures per app and chain, among them token incentives, trade count and outstanding supply. * **[Human's manual](/docs/catalog/humans-manual)**: Add Screeners as a dataset type, `screeners.` with `__` columns. **Expanded** * **[Accounts registry](/docs/catalog/accounts/registry)**: * Extend accounts from labelled addresses to every address the catalog holds, with region and funding for each. * Extend accounts with `attested_country` and `attested_at`, on every EVM chain of an attested address. * **[Chains registry](/docs/catalog/chains/registry)**: Extend chains with `logo`, `market_sectors` and `primary_market_sector`. * **[Apps registry](/docs/catalog/apps/registry)**: Extend to issuance apps for Circle, Superstate, Usual, Reflexer, Aave GHO, Curve crvUSD, Dinari USD+, Flying Tulip USD and Hydrated Dollar. * **[Apps metrics](/docs/catalog/apps/metrics)**: Extend TVL, trading volume, active loans, fees, supply-side fees and revenue per app and chain to every app the Explorer reports. * **[Financial statements](/docs/catalog/popular-datasets/financial-statements)**: Extend the weekly, monthly, quarterly and yearly statements from 8 to 35 lines. * **[Disclosures](/docs/catalog/real-world-assets/disclosures)**: Extend with `excluded_jurisdictions`, the jurisdictions an asset may not be offered in. **Fixed** * **[Assets registry](/docs/catalog/assets/registry)**: Fix the issuer legal fields. **September 29, 2026** **Breaking** * **[DEX registry](/docs/catalog/dex/registry)**: Rekey every DEX pool table on `app_id` and retire the protocols and deployments dimensions. Queries that used the older `protocol_id` read `app_id` instead, and those that used `deployment_id` filter on `app_id` and `chain_id` together. * **[Projects registry](/docs/catalog/projects/registry)**: * Restrict the registry to the projects the Explorer lists. A project not listed there no longer has a row. * Remove `status_label` and `archival_strategy`. Read `primary_market_sector` for the lead sector and `market_sectors` for the full ordered list. * **[Assets registry](/docs/catalog/assets/registry)**: Remove `product_id` from `project_relations`. Each element is now a project id and a relation. * **[Disclosures](/docs/catalog/real-world-assets/disclosures)**: Rekey `governing_law`, `governing_law_subdivision`, `dispute_resolution_country`, `regulatory_framework` and `regulator` by jurisdiction, as arrays, and remove the `GLOBAL` jurisdiction. Unnest the column and filter on `jurisdiction`. * **[Real-world assets registry](/docs/catalog/real-world-assets/registry)**: Remove `token_permissions_label` from the asset tokens table. Join `dimensions.asset_token_fields` on the permission id for the copy. **New** * **[Funding](/docs/catalog/accounts/funding)**: Add where an account's funds came from, across 182 venues, from October 2015. * **[Real-world assets registry](/docs/catalog/real-world-assets/registry)**: * Add disclosure fields, each term's title, definition and value copy, 58 terms in all. * Add token fields, the 68 values behind `token_standard`, `token_extensions` and `token_permissions`. * **[Arc](/docs/catalog/chain-verticals/evm/arc)**: Add a chain section with six layers, from raw blocks to real-world assets. **Expanded** * **[Projects registry](/docs/catalog/projects/registry)**: Extend with `url`, `logo`, `primary_market_sector`, `listing_date`, `archived_at`, `archived_reason`, `coingecko_id` and `coinmarketcap_id`. * **[Accounts registry](/docs/catalog/accounts/registry)**: Extend accounts with `funding_confidence`, `funding_evidence_edges`, `funding_first_edge_at`, `funding_jurisdiction`, `funding_jurisdiction_name`, `funding_venue_project_id`, `funding_venue_source`, `funding_venue_type`, `funding_wallet_count` and `funding_wallets_without_country`. * **[DEX trades](/docs/catalog/dex/trades)**: * Extend to BisonFi, Tessera V and GoonFi on Solana. * Extend to Circle StableFX on Arc, with its three USDC corridors to EURC, MXNB and BRLA. * **[Agentic payments](/docs/catalog/popular-datasets/agentic-payments)**: Extend to x402 settlements on XDC and Arc. * **[Disclosures](/docs/catalog/real-world-assets/disclosures)**: Extend every term with a `_status` companion, and key a group affiliate's licences under its own market with `affiliate_entity`. * **[Tron](/docs/catalog/chain-verticals/other/tron)**: * Extend blocks with `version` and `witness_signature`. * Extend transactions with `receipt_info_exchange_id`, `receipt_info_inject_another_amount` and `receipt_info_withdraw_another_amount`, and internal transactions with `extra`. * Extend wallet blocks with `contract_ret`, `signature`, `permission_id`, `fee_limit`, `expiration`, `transaction_timestamp`, `ref_block_bytes`, `ref_block_hash`, `contract_address`, `call_value`, `call_token_value` and `token_id`. * Extend wallet blocks with `resource`, `balance`, `receiver_address`, `lock`, `lock_period`, `frozen_balance`, `unfreeze_balance` and `parameter_value`. **Fixed** * **[Fact tables](/docs/catalog/humans-manual)**: Fix the twelve `facts_*` tables to serve as materialized tables, same columns, queryable from any subscriber project. * **[Disclosures](/docs/catalog/real-world-assets/disclosures)**: Fix `subscription_time` and `redemption_time` to settlement duration bands: instant, daily, weekly, monthly, quarterly. **September 22, 2026** **Breaking** * **[Real-world assets](/docs/catalog/real-world-assets)**: Move the section to `/catalog/real-world-assets` and narrow it to tokenized stocks, funds and commodities. Links to the former address redirect. **New** * **[Disclosures](/docs/catalog/real-world-assets/disclosures)**: Add `dimensions.asset_disclosures`, a typed column per term with its evidence beside it, for 46 assets. * **[Arc raw](/docs/catalog/chain-verticals/evm/arc/raw)**: Add blocks, transactions, logs and traces, from the first block. * **[XDC raw](/docs/catalog/chain-verticals/evm/xdc/raw)**: Add traces, from May 2019. **Expanded** * **[DEX trades](/docs/catalog/dex/trades)**: Extend to PumpSwap and EulerSwap, the latter with 1,248 pools. * **[Real-world assets registry](/docs/catalog/real-world-assets/registry)**: * Extend asset tokens with `token_standard`, `token_extensions`, `decimals` and `first_issued_onchain`, on 97% of 23,434 deployments. * Extend asset tokens with `token_permissions`, which names what an issuer can do to a holder: pause, freeze, mint or seize. * **[Chains registry](/docs/catalog/chains/registry)**: Extend to six Avalanche L1 chains, each with daily active users at project grain: Kite, TuringChain, ValueX, Titan L1, TomatoChain and TixChain. * **[Chain metrics](/docs/catalog/chains/metrics)**: Extend to Arc fees and activity, attributed to Circle. * **[Polygon raw](/docs/catalog/chain-verticals/evm/polygon/raw)**: Extend transactions with `authorization_list`, from July 2025. **Fixed** * **[Real-world assets registry](/docs/catalog/real-world-assets/registry)**: * Fix `token_extensions` to name the live compliance module on 1,217 deployments. * Fix `token_standard` coverage to 97% of deployments, from 76%. * **[Ethereum raw](/docs/catalog/chain-verticals/evm/ethereum/raw)**: Fix `authorization_list.nonce` to NUMERIC on Ethereum, Base and BSC, so the full 64-bit range reads exactly. **September 15, 2026** **Breaking** * **[DEX registry](/docs/catalog/dex/registry)**: Remove `deployment_id` from the DEX pools registry and the pool metrics tables. Where you filtered on the older `deployment_id`, filter on `protocol_id` and `chain_id` together. * **[Tokens registry](/docs/catalog/tokens/registry)**: Remove `asset_id`, `bridged` and the external price-provider id from the tokens registry. `bridged` continues as `bridged_status` on the asset tokens table. * **[Interest rates](/docs/catalog/lending/interest-rates)**: Rekey `unique_id` to include the reserve. Every existing id changes, so re-pull rather than diff on the old ones. * **[Markets](/docs/catalog/markets/dex-pools)**: Retire `dimensions.vaults` ahead of the vault vertical. The registry returns with that vertical, its facts and metrics beside it. * **[Ethereum raw](/docs/catalog/chain-verticals/evm/ethereum/raw)**: Remove the pre-Merge columns `params`, `author` and `sealFields` from blocks and `publicKey`, `condition`, `creates` and `standardV` from transactions. A query that named them drops the name. * **[Base raw](/docs/catalog/chain-verticals/evm/base/raw)**: Remove the legacy `logs.signature` column. A query that named it drops the name. * **[HyperEVM raw](/docs/catalog/chain-verticals/evm/hyperevm/raw)**: Remove `total_difficulty`, `author`, `signature`, `step` and `params` from blocks and `source_hash` from transactions. A query that named them drops the name. **New** * **[Asset metrics](/docs/catalog/assets/metrics)**: Add `app_tvl`, daily, per asset token by app, per asset by app and per asset. * **[Geographic intelligence](/docs/catalog/popular-datasets/geographic-intelligence)**: Add a region of activity per account with a confidence tier, on Ethereum, Base, Solana and Robinhood Chain, with Ethereum history from July 2015. **Expanded** * **[DEX trades](/docs/catalog/dex/trades)**: * Extend to 14 more venues, taking the count from 32 to 49. * Restore Thena, Etherex and Pharaoh with frozen history. * **[Perp markets](/docs/catalog/markets/perp-markets)**: Extend to MUX on five chains, 31 markets, on the same tables as Hyperliquid. * **[Interest rates](/docs/catalog/lending/interest-rates)**: Extend to Morpho Blue beside Aave v2, Aave v3, Spark and HyperLend. * **[App metrics](/docs/catalog/apps/metrics)**: Extend trading volume to 48 apps and 60 projects, up from 43 and 25. * **[Ethereum raw](/docs/catalog/chain-verticals/evm/ethereum/raw)**: Extend with `authorization_list`, `y_parity`, `receipt_root` and `requests_hash`. * **[Base raw](/docs/catalog/chain-verticals/evm/base/raw)**: Extend with `authorization_list`, `withdrawals`, `withdrawals_root`, `requests_hash`, `deposit_receipt_version`, `receipt_deposit_receipt_version`, `receipt_blob_gas_used`, `receipt_operator_fee_constant` and `receipt_operator_fee_scalar`. * **[BSC raw](/docs/catalog/chain-verticals/evm/bsc/raw)**: Extend with `authorization_list`, `withdrawals`, `withdrawals_root`, `requests_hash` and `milli_timestamp`. * **[Starknet](/docs/catalog/chain-verticals/other/starknet)**: Extend transactions with `receipt_l1_gas`, `receipt_l1_data_gas`, `receipt_l2_gas`, `tip`, `nonce_data_availability_mode`, `fee_data_availability_mode`, `resource_bounds`, `paymaster_data`, `account_deployment_data`, `receipt_messages_sent` and `receipt_message_hash`, and blocks with `l1_da_mode` and `starknet_version`. * **[Geographic intelligence](/docs/catalog/popular-datasets/geographic-intelligence)**: Backfill `facts_accounts.activity_hours` to each chain's first block, Ethereum from July 2015. **Fixed** * **[Chain metrics](/docs/catalog/chains/metrics)**: Fix 63 daily tables to exclude the open UTC day and each chain's period before its availability cutoff. * **[Ethereum raw](/docs/catalog/chain-verticals/evm/ethereum/raw)**: Fix `withdrawals` on pre-Shanghai blocks to an empty array. # Contracts Source: https://tokenterminal.com/docs/catalog/contracts/index Deployed contracts, with the account that created each one. A contract is code deployed to an address on a chain: * Uniswap's `Factory` on `ethereum`, `0x1f98431c8ad98523631ae4a59f267346ea31f984` * WETH on `ethereum`, `0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2` [Registry](/docs/catalog/contracts/registry) gives that address its first deployment, the accounts behind it and the size of the deployed bytecode. A contract is also an account, so `account_id` here is the key [Accounts](/docs/catalog/accounts/index) uses and the two registries join on it. ## Coverage Every chain we record contract deployments on. `alephzeroevm` `arbitrum` `avalanche` `base` `berachain` `blast` `bobanetwork` `bsc` `celo` `ethereum` `flow` `flowevm` `fraxtal` `gnosis` `gravityalpha` `immutablezkevm` `ink` `katananetwork` `linea` `manta` `mantraevm` `monad` `opbnb` `optimism` `plasma` `polygon` `robinhoodchain` `scroll` `solana` `sonic` `starknet` `tempo` `tron` `unichain` `worldchain` `worldmobilechain` `xai` `xlayer` `zksyncera` ## Tables [Registry](/docs/catalog/contracts/registry) holds the deployment table: one row per contract, keyed by chain and address, with the account that signed for it, the account that called `CREATE`, and the bytecode size. # Registry Source: https://tokenterminal.com/docs/catalog/contracts/registry One row per contract: the chain, the address, and its first deployment. One row per contract's first deployment: one address on one chain, with the accounts behind its creation and the size of the code it deployed. It holds every contract we see onchain, far past the ones anyone has labeled, and [Accounts](/docs/catalog/accounts/registry) holds those labels. ## Columns
Column Type Description
`contract_id` `INT64` Fingerprint of `account_id`, stable across runs.
`account_id` `STRING` Contract as an account: `{contract_address}-{chain_id}`. The same pair as one key, for joining `dimensions.accounts` and `dimensions.tokens`.
`chain_id` `STRING` Chain the contract is deployed on. With `contract_address` it is the cluster key and the pair to filter on: the same address on two chains is two different contracts.
`contract_address` `STRING` Address of the contract, spelled the way its chain spells it: lowercase on EVM and Starknet, base58 and case-sensitive on Solana and Tron. Lowercase an EVM address copied from an explorer before matching it here.
`first_deployed_at` `TIMESTAMP` Time the address first held code. An address can be created, destroyed with `SELFDESTRUCT` and created again; the row describes that first creation.
`deployer_address` `STRING` Account that signed the first deployment's transaction.
`creator_address` `STRING` Account that called `CREATE` on the first deployment. Equals `deployer_address` for a direct creation, and differs where a factory contract creates on the signer's behalf.
`contract_size` `FLOAT64` Deployed bytecode size in bytes, on the first deployment.
## Sample queries > [!WARNING] > > The table is clustered on `chain_id` and `contract_address`, and every row is current rather than dated. Filter on the chain, and on the address where you have it; a query that filters on neither reads the whole table. **Look up a contract** Filter `chain_id` and `contract_address` together, since that pair is the cluster key. Lowercase an EVM address copied from an explorer before you paste it in. ```sql theme={null} select first_deployed_at, deployer_address, creator_address, contract_size from `dimensions.contracts` where chain_id = 'ethereum' and contract_address = '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2' ``` **What one account deployed** `creator_address` is the account that called `CREATE`, so filtering it returns a factory's output; filter `deployer_address` instead for the contracts an account signed for. ```sql theme={null} select contract_address, first_deployed_at, contract_size from `dimensions.contracts` where chain_id = 'ethereum' and creator_address = '0x1f98431c8ad98523631ae4a59f267346ea31f984' order by first_deployed_at limit 100 ``` **Name a contract** `dimensions.accounts` holds the label, and the two tables join on `account_id`. The project filter keeps the contracts somebody has attributed, since the label columns are null on every other account. ```sql theme={null} select contracts.contract_address, contracts.first_deployed_at, accounts.project_id, accounts.contract_name from `dimensions.contracts` as contracts join `dimensions.accounts` as accounts using (account_id) where contracts.chain_id = 'ethereum' and accounts.project_id = 'uniswap' order by contracts.first_deployed_at limit 100 ``` # DEX aggregators Source: https://tokenterminal.com/docs/catalog/dex-aggregators Every aggregator: routed swaps and volume, across every venue. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A DEX aggregator routes a swap across other exchanges' pools for the best price. The vertical lands with routed trades and daily volume per aggregator. # DEX Source: https://tokenterminal.com/docs/catalog/dex/index Every trading pool: swaps, volume, TVL and fees, across every DEX. Swap volume, liquidity and fees for every trading pool Token Terminal tracks, across every chain, one table per measure. ## Coverage A tab per grain, then the events and the chains. Each tab says what one row is, and a tick marks every app that reports it. **Project** A project is the business behind the protocol, such as `uniswap`. One row per project per day, every version and chain together.
App Project Trading volume TVL Fees Supply-side fees Revenue
`acala-dex``acala`✓✓✓✓✓
`aerodrome-slipstream``aerodrome`✓✓✓✓✓
`aerodrome-stable``aerodrome`✓✓✓✓✓
`aerodrome-volatile``aerodrome`✓✓✓✓✓
`aperture-swap-v1``aperture`✓✓✓✓✓
`apeswap-dex``apeswap`✓✓✓✓✓
`bifrostio-stable-swaps``bifrostio`✓✓✓✓✓
`biswap-dex``biswap`✓✗✓✓✓
`blackhole-dex``blackhole`✓✓✗✗✗
`camelot-dex``camelot`✓✓✓✓✓
`chainflip-dex``chainflip`✓✓✓✓✓
`circle-stablefx``circle`✓✓✓✓✓
`curve-dex``curve`✓✓✓✓✓
`dodo-dex``dodo`✓✗✓✓✓
`dydx-v3``dydx`✗✓✓✓✓
`dydx-v4``dydx`✗✓✓✓✓
`equalizer-dex``equalizer`✓✓✓✓✓
`etherex-dex``etherex`✓✓✓✓✓
`euler-swap``euler`✓✓✓✓✓
`fathom-dex``fathom`✓✓✓✓✓
`honeypop-dex``honeypop`✓✓✓✓✓
`hydradx-dex``hydradx`✓✓✓✓✓
`hyperliquid-spot``hyperliquid`✓✗✓✓✓
`instadapp-fluid-dex``instadapp`✓✓✓✓✓
`instadapp-fluid-dex-lite``instadapp`✓✓✓✓✓
`integral-dex``integral`✓✗✓✓✓
`katana-dex``katana`✓✓✓✓✓
`kyber-dex``kyber`✓✓✓✓✓
`maverick-dex``maverick`✓✓✓✓✓
`meteora-launchpad``meteora`✓✓✓✓✓
`meteora-liquidity-pools``meteora`✓✓✓✓✓
`metric-v1``metric`✓✗✗✗✗
`metric-v2``metric`✓✗✗✗✗
`near-intents``near`✓✗✓✓✓
`okutrade-dex``okutrade`✓✓✓✓✓
`orca-token-swap-v2``orca`✓✓✓✓✓
`orca-whirlpools``orca`✓✓✓✓✓
`pancakeswap-v2``pancakeswap`✓✓✓✓✓
`pancakeswap-v3``pancakeswap`✓✓✓✓✓
`pangolin-dex``pangolin`✓✓✓✓✓
`pendle-amm``pendle`✗✓✓✓✓
`pendle-boros``pendle`✗✓✓✓✓
`pendle-limit-order``pendle`✗✓✓✓✓
`pendle-vependle``pendle`✗✓✓✓✓
`pendle-yield-tokenization``pendle`✗✓✓✓✓
`pharaoh-dex``pharaoh`✓✓✓✓✓
`projectx``projectx`✓✗✗✗✗
`pumpfun-amm``pumpfun`✓✗✗✗✗
`pumpfun-launchpad``pumpfun`✓✗✓✓✓
`quickswap-v2``quickswap`✓✓✓✓✓
`quickswap-v3``quickswap`✓✓✓✓✓
`ramses-dex``ramses`✓✓✓✓✓
`raydium-clmm``raydium`✓✓✓✓✓
`raydium-cpmm``raydium`✓✓✓✓✓
`raydium-launchlab``raydium`✓✓✓✓✓
`raydium-openbook``raydium`✓✓✓✓✓
`raydium-stable-swap``raydium`✓✓✓✓✓
`ripple-amm``ripple`✓✓✓✓✓
`ripple-clob``ripple`✓✓✓✓✓
`shadowexchange-concentrated-liquidity``shadowexchange`✓✓✓✓✓
`shadowexchange-constant-product``shadowexchange`✓✓✓✓✓
`shadowexchange-dex``shadowexchange`✓✓✓✓✓
`solidlizard-dex``solidlizard`✓✓✓✓✓
`spookyswap-dex``spookyswap`✓✓✓✓✓
`sunswap-v1``sunswap`✓✗✗✗✗
`sunswap-v2``sunswap`✓✗✗✗✗
`sunswap-v3``sunswap`✓✗✗✗✗
`sunswap-v4``sunswap`✓✗✗✗✗
`sushiswap-dex``sushiswap`✓✓✓✓✓
`syncswap-dex``syncswap`✓✓✓✓✓
`thena-dex``thena`✓✓✓✓✓
`thruster-clamm``thruster`✓✓✓✓✓
`thruster-classic``thruster`✓✓✓✓✓
`traderjoe-dex``traderjoe`✓✓✓✓✓
`uniswap-v2``uniswap`✓✓✓✓✓
`uniswap-v3``uniswap`✓✓✓✓✓
`uniswap-v4``uniswap`✓✓✓✓✓
`variational-omni``variational`✗✓✓✓✓
`velodrome-dex``velodrome`✓✓✓✓✓
`versedex-dex``versedex`✓✓✓✓✓
`xswap-dex``xswap`✓✓✓✓✓
`zkswap-dex``zkswap`✓✓✗✗✗
`zyberswap-dex``zyberswap`✓✓✓✓✓
**App** An app is one deployed version of a protocol, such as `uniswap-v3`. One row per app per day, across every chain it runs on.
App Project Trading volume TVL Fees Supply-side fees Revenue
`acala-dex``acala`✓✓✓✓✗
`aerodrome-slipstream``aerodrome`✓✓✗✗✗
`aerodrome-stable``aerodrome`✓✓✗✗✗
`aerodrome-volatile``aerodrome`✓✓✗✗✗
`aperture-swap-v1``aperture`✓✓✓✓✓
`apeswap-dex``apeswap`✓✗✗✗✗
`bifrostio-stable-swaps``bifrostio`✓✓✗✗✗
`blackhole-dex``blackhole`✓✗✗✗✗
`camelot-dex``camelot`✓✗✗✗✗
`chainflip-dex``chainflip`✓✗✓✓✓
`circle-stablefx``circle`✓✓✓✓✓
`curve-dex``curve`✓✓✓✓✓
`dodo-dex``dodo`✓✗✗✗✗
`dydx-v3``dydx`✗✓✓✗✓
`dydx-v4``dydx`✗✓✓✗✓
`equalizer-dex``equalizer`✓✗✗✗✗
`etherex-dex``etherex`✓✗✗✗✗
`euler-swap``euler`✓✗✓✗✓
`fathom-dex``fathom`✓✓✓✓✓
`honeypop-dex``honeypop`✓✗✗✗✗
`hydradx-dex``hydradx`✓✓✓✗✓
`hyperliquid-spot``hyperliquid`✓✗✓✓✓
`instadapp-fluid-dex``instadapp`✓✗✓✓✓
`instadapp-fluid-dex-lite``instadapp`✓✓✓✓✗
`integral-dex``integral`✓✗✗✗✗
`maverick-dex``maverick`✓✗✗✗✗
`meteora-launchpad``meteora`✓✓✓✓✓
`meteora-liquidity-pools``meteora`✓✓✓✓✓
`metric-v1``metric`✓✗✗✗✗
`metric-v2``metric`✓✗✗✗✗
`near-intents``near`✓✗✓✓✓
`okutrade-dex``okutrade`✓✗✗✗✗
`orca-token-swap-v2``orca`✓✓✓✓✓
`orca-whirlpools``orca`✓✓✓✓✓
`pancakeswap-v2``pancakeswap`✓✓✓✓✓
`pancakeswap-v3``pancakeswap`✓✓✓✓✓
`pangolin-dex``pangolin`✓✗✗✗✗
`pendle-amm``pendle`✗✗✓✓✓
`pendle-boros``pendle`✗✓✓✓✓
`pendle-limit-order``pendle`✗✗✓✓✓
`pendle-vependle``pendle`✗✗✓✓✓
`pendle-yield-tokenization``pendle`✗✓✓✓✓
`pharaoh-dex``pharaoh`✓✗✗✗✗
`projectx``projectx`✓✗✗✗✗
`pumpfun-amm``pumpfun`✓✗✗✗✗
`pumpfun-launchpad``pumpfun`✓✗✓✓✓
`quickswap-v2``quickswap`✓✓✓✓✓
`quickswap-v3``quickswap`✓✓✓✓✓
`ramses-dex``ramses`✓✗✗✗✗
`raydium-clmm``raydium`✓✓✓✓✓
`raydium-cpmm``raydium`✓✓✓✓✓
`raydium-launchlab``raydium`✓✓✓✓✓
`raydium-openbook``raydium`✓✓✓✓✓
`raydium-stable-swap``raydium`✓✓✓✓✓
`ripple-amm``ripple`✓✓✓✓✓
`ripple-clob``ripple`✓✗✗✗✗
`shadowexchange-concentrated-liquidity``shadowexchange`✓✗✓✓✓
`shadowexchange-constant-product``shadowexchange`✓✗✓✓✓
`solidlizard-dex``solidlizard`✓✗✗✗✗
`spookyswap-dex``spookyswap`✓✗✗✗✗
`sunswap-v1``sunswap`✓✗✗✗✗
`sunswap-v2``sunswap`✓✗✗✗✗
`sunswap-v3``sunswap`✓✗✗✗✗
`sunswap-v4``sunswap`✓✗✗✗✗
`sushiswap-dex``sushiswap`✓✗✗✗✗
`thena-dex``thena`✓✗✗✗✗
`thruster-clamm``thruster`✓✗✓✓✓
`thruster-classic``thruster`✓✗✓✓✓
`traderjoe-dex``traderjoe`✓✗✗✗✗
`uniswap-v2``uniswap`✓✓✓✓✓
`uniswap-v3``uniswap`✓✓✓✓✓
`uniswap-v4``uniswap`✓✓✓✓✓
`variational-omni``variational`✗✓✓✓✓
`velodrome-dex``velodrome`✓✗✗✗✗
`versedex-dex``versedex`✓✗✗✗✗
`zkswap-dex``zkswap`✓✗✗✗✗
**Pool** A pool is one place to swap tokens on one chain, such as Uniswap v3's `USDC-WETH` pool on Ethereum. One row per pool per day.
App Project Trading volume
`aerodrome-slipstream``aerodrome`✓
`aerodrome-stable``aerodrome`✓
`aerodrome-volatile``aerodrome`✓
`aperture-swap-v1``aperture`✓
`apeswap-dex``apeswap`✓
`blackhole-dex``blackhole`✓
`camelot-dex``camelot`✓
`circle-stablefx``circle`✓
`curve-dex``curve`✓
`dodo-dex``dodo`✓
`equalizer-dex``equalizer`✓
`etherex-dex``etherex`✓
`euler-swap``euler`✓
`fathom-dex``fathom`✓
`honeypop-dex``honeypop`✓
`instadapp-fluid-dex``instadapp`✓
`instadapp-fluid-dex-lite``instadapp`✓
`integral-dex``integral`✓
`maverick-dex``maverick`✓
`meteora-launchpad``meteora`✓
`meteora-liquidity-pools``meteora`✓
`metric-v1``metric`✓
`metric-v2``metric`✓
`okutrade-dex``okutrade`✓
`orca-token-swap-v2``orca`✓
`orca-whirlpools``orca`✓
`pancakeswap-v2``pancakeswap`✓
`pancakeswap-v3``pancakeswap`✓
`pangolin-dex``pangolin`✓
`pharaoh-dex``pharaoh`✓
`projectx``projectx`✓
`pumpfun-amm``pumpfun`✓
`pumpfun-launchpad``pumpfun`✓
`quickswap-v2``quickswap`✓
`quickswap-v3``quickswap`✓
`ramses-dex``ramses`✓
`raydium-clmm``raydium`✓
`raydium-cpmm``raydium`✓
`raydium-launchlab``raydium`✓
`raydium-openbook``raydium`✓
`raydium-stable-swap``raydium`✓
`shadowexchange-concentrated-liquidity``shadowexchange`✓
`shadowexchange-constant-product``shadowexchange`✓
`shadowexchange-dex``shadowexchange`✓
`solidlizard-dex``solidlizard`✓
`spookyswap-dex``spookyswap`✓
`sunswap-v1``sunswap`✓
`sunswap-v2``sunswap`✓
`sunswap-v3``sunswap`✓
`sunswap-v4``sunswap`✓
`sushiswap-dex``sushiswap`✓
`temple``temple`✓
`thena-dex``thena`✓
`thruster-clamm``thruster`✓
`thruster-classic``thruster`✓
`traderjoe-dex``traderjoe`✓
`uniswap-v2``uniswap`✓
`uniswap-v3``uniswap`✓
`uniswap-v4``uniswap`✓
`velodrome-dex``velodrome`✓
`versedex-dex``versedex`✓
`zkswap-dex``zkswap`✓
**Pair** A pair is two tokens inside one pool, such as `USDC` and `WETH`. One row per pool and pair per day.
App Project Trading volume
`aerodrome-slipstream``aerodrome`✓
`aerodrome-stable``aerodrome`✓
`aerodrome-volatile``aerodrome`✓
`aperture-swap-v1``aperture`✓
`apeswap-dex``apeswap`✓
`blackhole-dex``blackhole`✓
`camelot-dex``camelot`✓
`circle-stablefx``circle`✓
`curve-dex``curve`✓
`dodo-dex``dodo`✓
`equalizer-dex``equalizer`✓
`etherex-dex``etherex`✓
`euler-swap``euler`✓
`fathom-dex``fathom`✓
`honeypop-dex``honeypop`✓
`instadapp-fluid-dex``instadapp`✓
`instadapp-fluid-dex-lite``instadapp`✓
`integral-dex``integral`✓
`maverick-dex``maverick`✓
`meteora-launchpad``meteora`✓
`meteora-liquidity-pools``meteora`✓
`metric-v1``metric`✓
`metric-v2``metric`✓
`okutrade-dex``okutrade`✓
`orca-token-swap-v2``orca`✓
`orca-whirlpools``orca`✓
`pancakeswap-v2``pancakeswap`✓
`pancakeswap-v3``pancakeswap`✓
`pangolin-dex``pangolin`✓
`pharaoh-dex``pharaoh`✓
`projectx``projectx`✓
`pumpfun-amm``pumpfun`✓
`pumpfun-launchpad``pumpfun`✓
`quickswap-v2``quickswap`✓
`quickswap-v3``quickswap`✓
`ramses-dex``ramses`✓
`raydium-clmm``raydium`✓
`raydium-cpmm``raydium`✓
`raydium-launchlab``raydium`✓
`raydium-openbook``raydium`✓
`raydium-stable-swap``raydium`✓
`shadowexchange-concentrated-liquidity``shadowexchange`✓
`shadowexchange-constant-product``shadowexchange`✓
`shadowexchange-dex``shadowexchange`✓
`solidlizard-dex``solidlizard`✓
`spookyswap-dex``spookyswap`✓
`sunswap-v1``sunswap`✓
`sunswap-v2``sunswap`✓
`sunswap-v3``sunswap`✓
`sunswap-v4``sunswap`✓
`sushiswap-dex``sushiswap`✓
`temple``temple`✓
`thena-dex``thena`✓
`thruster-clamm``thruster`✓
`thruster-classic``thruster`✓
`traderjoe-dex``traderjoe`✓
`uniswap-v2``uniswap`✓
`uniswap-v3``uniswap`✓
`uniswap-v4``uniswap`✓
`velodrome-dex``velodrome`✓
`versedex-dex``versedex`✓
`zkswap-dex``zkswap`✓
**Events** One row per swap, at the moment it happened onchain. Amounts are in the token's own units; join [Prices](/docs/catalog/tokens/metrics) for a USD figure.
App Project Trades
`aerodrome-slipstream``aerodrome`✓
`aerodrome-stable``aerodrome`✓
`aerodrome-volatile``aerodrome`✓
`aperture-swap-v1``aperture`✓
`apeswap-dex``apeswap`✓
`blackhole-dex``blackhole`✓
`camelot-dex``camelot`✓
`circle-stablefx``circle`✓
`curve-dex``curve`✓
`dodo-dex``dodo`✓
`equalizer-dex``equalizer`✓
`etherex-dex``etherex`✓
`euler-swap``euler`✓
`fathom-dex``fathom`✓
`honeypop-dex``honeypop`✓
`instadapp-fluid-dex``instadapp`✓
`instadapp-fluid-dex-lite``instadapp`✓
`integral-dex``integral`✓
`maverick-dex``maverick`✓
`meteora-launchpad``meteora`✓
`meteora-liquidity-pools``meteora`✓
`metric-v1``metric`✓
`metric-v2``metric`✓
`okutrade-dex``okutrade`✓
`orca-whirlpools``orca`✓
`pancakeswap-v2``pancakeswap`✓
`pancakeswap-v3``pancakeswap`✓
`pangolin-dex``pangolin`✓
`pharaoh-dex``pharaoh`✓
`projectx``projectx`✓
`pumpfun-amm``pumpfun`✓
`pumpfun-launchpad``pumpfun`✓
`quickswap-v2``quickswap`✓
`quickswap-v3``quickswap`✓
`ramses-dex``ramses`✓
`raydium-clmm``raydium`✓
`raydium-cpmm``raydium`✓
`raydium-launchlab``raydium`✓
`raydium-openbook``raydium`✓
`raydium-stable-swap``raydium`✓
`shadowexchange-concentrated-liquidity``shadowexchange`✓
`shadowexchange-constant-product``shadowexchange`✓
`solidlizard-dex``solidlizard`✓
`spookyswap-dex``spookyswap`✓
`sunswap-v1``sunswap`✓
`sunswap-v2``sunswap`✓
`sunswap-v3``sunswap`✓
`sunswap-v4``sunswap`✓
`sushiswap-dex``sushiswap`✓
`temple``temple`✓
`thena-dex``thena`✓
`thruster-clamm``thruster`✓
`thruster-classic``thruster`✓
`traderjoe-dex``traderjoe`✓
`uniswap-v2``uniswap`✓
`uniswap-v3``uniswap`✓
`uniswap-v4``uniswap`✓
`velodrome-dex``velodrome`✓
`versedex-dex``versedex`✓
`zkswap-dex``zkswap`✓
**Chains** Every chain the section covers.
Chain Apps
`acala``acala-dex`
`arbitrum``apeswap-dex`, `camelot-dex`, `dodo-dex`, `euler-swap`, `instadapp-fluid-dex`, `integral-dex`, `metric-v1`, `metric-v2`, `pancakeswap-v2`, `pancakeswap-v3`, `pendle-boros`, `pendle-yield-tokenization`, `ramses-dex`, `solidlizard-dex`, `sushiswap-dex`, `traderjoe-dex`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`, `variational-omni`
`arc``circle-stablefx`
`avalanche``blackhole-dex`, `dodo-dex`, `dydx-v3`, `euler-swap`, `metric-v2`, `pangolin-dex`, `pharaoh-dex`, `quickswap-v2`, `sushiswap-dex`, `traderjoe-dex`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`
`base``aerodrome-slipstream`, `aerodrome-stable`, `aerodrome-volatile`, `dodo-dex`, `euler-swap`, `instadapp-fluid-dex`, `maverick-dex`, `metric-v1`, `metric-v2`, `pancakeswap-v2`, `pancakeswap-v3`, `pendle-yield-tokenization`, `quickswap-v2`, `quickswap-v3`, `sushiswap-dex`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`
`berachain``euler-swap`, `pendle-yield-tokenization`
`bifrostio``bifrostio-stable-swaps`
`blast``thruster-clamm`, `thruster-classic`, `uniswap-v3`, `uniswap-v4`
`bobanetwork``uniswap-v3`
`bsc``apeswap-dex`, `dodo-dex`, `euler-swap`, `instadapp-fluid-dex`, `maverick-dex`, `metric-v1`, `metric-v2`, `pancakeswap-v2`, `pancakeswap-v3`, `pendle-yield-tokenization`, `sushiswap-dex`, `thena-dex`, `traderjoe-dex`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`
`cantonnetwork``temple`
`celo``uniswap-v3`
`chainflip``chainflip-dex`
`dydx``dydx-v4`
`ethereum``apeswap-dex`, `curve-dex`, `dodo-dex`, `dydx-v3`, `euler-swap`, `instadapp-fluid-dex`, `instadapp-fluid-dex-lite`, `integral-dex`, `maverick-dex`, `metric-v1`, `metric-v2`, `pancakeswap-v2`, `pancakeswap-v3`, `pendle-yield-tokenization`, `sushiswap-dex`, `traderjoe-dex`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`, `versedex-dex`
`fantom``equalizer-dex`, `spookyswap-dex`, `sushiswap-dex`
`gnosis``sushiswap-dex`
`hydradx``hydradx-dex`
`hypercore``hyperliquid-spot`
`hyperevm``metric-v2`, `pendle-yield-tokenization`, `projectx`
`linea``etherex-dex`
`manta``aperture-swap-v1`, `quickswap-v3`, `uniswap-v3`
`megaeth``metric-v2`
`monad``metric-v2`, `pendle-yield-tokenization`
`near``near-intents`
`optimism``aerodrome-slipstream`, `dodo-dex`, `sushiswap-dex`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`, `velodrome-dex`
`plasma``instadapp-fluid-dex`, `pendle-yield-tokenization`, `uniswap-v3`
`polygon``apeswap-dex`, `dodo-dex`, `instadapp-fluid-dex`, `metric-v2`, `quickswap-v2`, `quickswap-v3`, `sushiswap-dex`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`
`ripple``ripple-amm`, `ripple-clob`
`robinhoodchain``curve-dex`, `metric-v1`, `metric-v2`, `pancakeswap-v2`, `pancakeswap-v3`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`
`scroll``honeypop-dex`
`solana``meteora-launchpad`, `meteora-liquidity-pools`, `orca-token-swap-v2`, `orca-whirlpools`, `pumpfun-amm`, `pumpfun-launchpad`, `raydium-clmm`, `raydium-cpmm`, `raydium-launchlab`, `raydium-openbook`, `raydium-stable-swap`
`sonic``euler-swap`, `pendle-yield-tokenization`, `shadowexchange-concentrated-liquidity`, `shadowexchange-constant-product`
`tron``sunswap-v1`, `sunswap-v2`, `sunswap-v3`, `sunswap-v4`
`unichain``euler-swap`, `uniswap-v2`, `uniswap-v3`, `uniswap-v4`
`xdc``curve-dex`, `dydx-v3`, `fathom-dex`, `okutrade-dex`
`zksyncera``maverick-dex`, `pancakeswap-v2`, `pancakeswap-v3`, `uniswap-v3`, `zkswap-dex`
## Tables [Metrics](/docs/catalog/dex/metrics) holds the daily table schemas at each grain and example queries. [Registry](/docs/catalog/dex/registry) holds the identity tables. Each event has its own page and its own table: [Trades](/docs/catalog/dex/trades). # Metrics Source: https://tokenterminal.com/docs/catalog/dex/metrics Daily DEX figures per project, app, pool and pair. Trading volume, TVL, fees and revenue, in USD. One row per thing per day, at four grains: project, app, pool and pair. ## Tables > [!NOTE] > > Daily pool trading volume and position principal, uncollected fees and TVL cover closed UTC days and follow the availability cutoff of each pool’s chain. A tab per grain. [Coverage](/docs/catalog/dex) shows which apps report which measure. **Project** One row per project per day.
Table Value column What it holds
`metrics_projects.trading_volume_daily``trading_volume`Total value of trades executed.
`metrics_projects.tvl_daily``tvl`Total value locked.
`metrics_projects.fees_daily``fees`Total fees paid by users.
`metrics_projects.fees_supply_side_daily``fees_supply_side`Fees paid out to the supply side.
`metrics_projects.revenue_daily``revenue`Fees retained by the protocol.
**App** One row per app per day.
Table Value column What it holds
`metrics_apps.trading_volume_daily``trading_volume`Value of trades executed by the app, measured on the quote leg at execution price.
`metrics_apps.tvl_daily``tvl`Total value locked in the app.
`metrics_apps.fees_daily``fees`Fees paid by users of the app across every chain it runs on.
`metrics_apps.fees_supply_side_daily``fees_supply_side`Fees the app passed through to builders and, on HIP-3 markets, to market deployers.
`metrics_apps.revenue_daily``revenue`Fees the app retained across every chain it runs on.
**Pool** One row per pool per day.
Table Value column What it holds
`metrics_dex_pools.trading_volume_daily``trading_volume`Total value of trades executed through the DEX pool.
`metrics_dex_pools.tvl_daily``tvl`USD value of assets held in the DEX pool.
`metrics_dex_pools.fees_daily``fees`Fees paid by users of the DEX pool.
`metrics_dex_pools.flash_loan_volume_daily``flash_loan_volume`Total value of flash loans executed through the DEX pool.
**Pair** One row per pool and token pair per day.
Table Value column What it holds
`metrics_dex_pools_by_pair.trading_volume_daily``trading_volume`Total value of trades executed through the DEX pool.
## Sample queries **One pool's series** Each measure is its own table, so a row with all three is a join on `dex_pool_id` and `timestamp`, bounded on every side. Join with `full join`: a pool can hold liquidity on a day nothing traded. ```sql theme={null} with volume as ( select timestamp, trading_volume from `metrics_dex_pools.trading_volume_daily` where dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum' and timestamp >= timestamp('2026-06-01') ), tvl as ( select timestamp, tvl from `metrics_dex_pools.tvl_daily` where dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum' and timestamp >= timestamp('2026-06-01') ), fees as ( select timestamp, fees from `metrics_dex_pools.fees_daily` where dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum' and timestamp >= timestamp('2026-06-01') ) select timestamp, volume.trading_volume, tvl.tvl, fees.fees from volume full join tvl using (timestamp) full join fees using (timestamp) order by timestamp ``` **Pools by volume** One day of pool volume across the catalog, ranked. `dex_pool_id` joins `dimensions.dex_pools` for the pool's tokens and its fee tier. ```sql theme={null} select dex_pool_id, app_id, chain_id, trading_volume from `metrics_dex_pools.trading_volume_daily` where timestamp = timestamp('2026-08-01') order by trading_volume desc limit 25 ``` **Pair total across pools** The same pair can trade in many pools, and it has the same `dex_pair_id` in all of them, so a total across pools is a group by on that column. ```sql theme={null} select timestamp, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where dex_pair_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2-ethereum' and timestamp >= timestamp('2026-08-01') group by timestamp order by timestamp ``` **Pool by pair breakdown** A pool's pair rows add back up to its row on the pool table. A breakdown by single token would not: every swap involves two tokens, so counting it under each one counts it twice and the total stops matching the pool. ```sql theme={null} select dex_pair_id, sum(trading_volume) as trading_volume from `metrics_dex_pools_by_pair.trading_volume_daily` where dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') group by dex_pair_id order by trading_volume desc ``` **Sector total** A sector total is a grouping over the pool volume table joined to `dimensions.projects`, by day. Group by `primary_market_sector`, where every project appears exactly once. ```sql theme={null} select daily.timestamp, sum(daily.trading_volume) as sector_volume from `metrics_dex_pools.trading_volume_daily` as daily join `dimensions.projects` as projects on projects.project_id = daily.project_id where projects.primary_market_sector = 'exchange' and daily.timestamp >= timestamp('2026-08-01') group by daily.timestamp order by daily.timestamp ``` **Pool vs pair check** The pool row is the sum of its pair rows. On any day the pool traded, the two sides agree exactly. ```sql theme={null} with pairs as ( select dex_pool_id, timestamp, sum(trading_volume) as summed from `metrics_dex_pools_by_pair.trading_volume_daily` where dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum' and timestamp >= timestamp('2026-08-01') group by dex_pool_id, timestamp ), pools as ( select dex_pool_id, timestamp, trading_volume from `metrics_dex_pools.trading_volume_daily` where dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum' and timestamp >= timestamp('2026-08-01') ) select timestamp, pools.trading_volume as pool_grain, pairs.summed as pair_grain from pools join pairs using (dex_pool_id, timestamp) order by timestamp ``` # Registry Source: https://tokenterminal.com/docs/catalog/dex/registry Pool identity, the fee it charges, its tokens, and who runs it. The identity tables behind every DEX figure. Every fact and metric joins to one of them, and [Coverage](/docs/catalog/dex) introduces each grain. ## Tables **Projects** One row per project in the catalog.
Column Type Description
`project_id`STRINGThe project, such as `aave`.
`slug`STRINGThe project's key in Token Terminal page URLs. It differs from `project_id` where the page URL is hyphenated (`redstone-chain` for `redstonechain`).
`url`STRINGThe project's page on the Token Terminal Explorer.
`name`STRINGDisplay name.
`symbol`STRINGTicker of the project's token, where it has one.
`logo`STRINGPublic URL of the project logo, a PNG. Its `?logo_hash=` suffix changes whenever the image does. Null for a project whose image was never uploaded.
`description`STRUCTThe project copy: `what` the project is, `who` it serves and `how` it works.
`links`ARRAY\The project's links as `type` and `url` pairs (website, x, docs, github). `type` is the label as written, so `twitter` and `x` both occur.
`market_sectors`ARRAY\Every market sector the project belongs to, as tag ids, primary first. Unnesting it yields one row per sector.
`primary_market_sector`STRINGThe market sector the project is listed under: the first element of `market_sectors`. One value per row.
`listing_date`TIMESTAMPWhen the project was listed on Token Terminal.
`coingecko_id`STRINGThe project token's CoinGecko id.
`coinmarketcap_id`STRINGThe project token's CoinMarketCap id.
**Apps** One row per app in the catalog.
Column Type Description
`app_id`STRINGThe app, such as `aave-v3`.
`project_id`STRINGThe project operating it.
`name`STRINGDisplay name.
`market_sectors`ARRAY\Every sector the app is tagged with.
`primary_market_sector`STRINGThe first of those, for grouping.
`created_at`TIMESTAMPWhen the app was added.
**Pools** One row per pool on one chain, listing every pool ever created, including ones that never traded.
Column Type Description
`dex_pool_id` `STRING` Identifier of the pool: the pool address joined with the chain.
`app_id` `STRING` The app operating the pool.
`chain_id` `STRING` Chain the pool lives on.
`project_id` `STRING` Project the operating app belongs to.
`pool_address` `STRING` Onchain address of the pool. Where one contract holds every pool, this is the pool's id inside that contract.
`pool_name` `STRING` The pool's tokens as a name, for example `USDC-WETH`.
`pool_display_name` `STRING` Pool name with the fee added on, where the pool charges a fixed one.
`fee_tier` `BIGNUMERIC` The fee the pool charges on every swap, as a decimal fraction, so `0.0005` reads 0.05%. Empty where the venue sets the fee swap by swap.
`created_at` `TIMESTAMP` Time of the block the pool was created in.
`hooks_address` `STRING` Address of the pool's hooks contract, on venues that attach one. A hooks contract is extra code the venue runs around each swap.
`token_ids` `ARRAY` The tokens the pool holds, in pool order, as keys of `dimensions.tokens`.
## Sample queries **Pools per chain** Count the pools each app has created on each chain. ```sql theme={null} select app_id, chain_id, count(*) as pools from `dimensions.dex_pools` group by app_id, chain_id order by pools desc limit 20 ``` **A pool's tokens** `token_ids` lists the pool's tokens, in the order the pool holds them, as keys of `dimensions.tokens`. Join that table on one element of the list for symbol, name and decimals; a leg's curated asset, where it has one, is on `dimensions.asset_tokens` under the same key. ```sql theme={null} select pools.dex_pool_id, pools.pool_display_name, position, tokens.symbol, tokens.decimals, tokens.token_address from `dimensions.dex_pools` as pools, unnest(pools.token_ids) as token_id with offset as position join `dimensions.tokens` as tokens using (token_id) where pools.dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum' order by position ``` **Pools for one pair** `token_ids` holds the pool's tokens as a list, so a pair is two `in unnest(token_ids)` clauses rather than one equality. ```sql theme={null} select dex_pool_id, app_id, pool_display_name, fee_tier from `dimensions.dex_pools` where chain_id = 'ethereum' and '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' in unnest(token_ids) and '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2-ethereum' in unnest(token_ids) order by created_at limit 50 ``` **Registry against traded pools** A pool enters this table when its factory emits the creation event, so the registry side counts every pool an app has ever created and the traded side counts the ones that saw a swap. ```sql theme={null} with registry as ( select app_id, count(*) as pools_in_registry from `dimensions.dex_pools` where chain_id = 'ethereum' group by app_id ), traded as ( select app_id, count(distinct dex_pool_id) as pools_traded from `metrics_dex_pools.trading_volume_daily` where chain_id = 'ethereum' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') group by app_id ) select app_id, registry.pools_in_registry, traded.pools_traded from registry left join traded using (app_id) order by registry.pools_in_registry desc ``` # Trades Source: https://tokenterminal.com/docs/catalog/dex/trades Individual DEX swaps in token amounts. One row per swap, in the pool's own token amounts. `amount_in` and `amount_out` are the two legs, and deduplicating a router's fills on `transaction_hash` turns venue volume into interface volume. ## Columns
Column Type Description
`block_timestamp` `TIMESTAMP` Time of the block containing the swap. Partition column.
`transaction_hash` `STRING` Hash of the transaction containing the swap. Several rows share a hash when a router splits one swap across pools.
`log_index` `INT64` Position of the swap event in the block. `(chain_id, transaction_hash, log_index)` identifies a row.
`dex_pool_id` `STRING` Pool the swap executed in, keyed like [`dimensions.dex_pools`](/docs/catalog/dex/registry).
`app_id` `STRING` The app operating the pool, read from the pool registry.
`chain_id` `STRING` Chain the swap executed on.
`project_id` `STRING` Project the operating app belongs to.
`token_in_id` `STRING` Token the trader handed to the pool, keyed like [`dimensions.tokens`](/docs/catalog/tokens/registry).
`token_out_id` `STRING` Token the trader received from the pool.
`fee_rate` `BIGNUMERIC` Fee charged on this swap, as a decimal fraction of its size. Fixed per pool on most venues, set per swap where the venue supports dynamic fees. Null where the venue publishes no per-swap rate the catalog decodes (Aero, Aerodrome, Velodrome).
`amount_in` `BIGNUMERIC` Amount of `token_in_id` handed over, in whole token units, always positive.
`amount_out` `BIGNUMERIC` Amount of `token_out_id` received, in whole token units, always positive.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One day, one pool** The pool here is the Uniswap v3 USDC-WETH 0.05% pool on Ethereum; find any pool's id in [`dimensions.dex_pools`](/docs/catalog/dex/registry). ```sql theme={null} select trades.block_timestamp, trades.transaction_hash, trades.token_in_id, trades.amount_in, trades.token_out_id, trades.amount_out, trades.fee_rate from `facts_dex_pools.trades` as trades where trades.dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fca843a45-ethereum' and trades.chain_id = 'ethereum' and trades.block_timestamp >= timestamp('2026-08-20') and trades.block_timestamp < timestamp('2026-08-21') order by trades.amount_in desc limit 100 ``` **Venue vs interface volume** The venue lens sums every fill; the interface lens counts each transaction once, taking its largest fill as the user's swap, so router-split swaps stop double counting. ```sql theme={null} with fills as ( select trades.transaction_hash, trades.amount_in from `facts_dex_pools.trades` as trades where trades.token_in_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' and trades.chain_id = 'ethereum' and trades.block_timestamp >= timestamp('2026-08-20') and trades.block_timestamp < timestamp('2026-08-21') ), per_transaction as ( select max(amount_in) as swap_amount from fills group by transaction_hash ) select (select sum(amount_in) from fills) as venue_volume, (select sum(swap_amount) from per_transaction) as interface_volume ``` # FAQ Source: https://tokenterminal.com/docs/catalog/faq Common questions about the data catalog. ## Access > **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 `.`, qualified by your project id when you query it from outside that project. Compute is billed to you. Snowflake shares are available on request. [Contact us](https://calendly.com/d/cv8h-mgf-n3g/token-terminal-api-demo) to arrange the share. > **Which datasets does the share cover?** > > `dimensions` and `functions`, plus a `facts_` and a `metrics_` dataset per kind of thing measured, such as `metrics_dex_pools`. Standardized blockchain tables are shared separately, one dataset per chain, and [Chain ecosystems](/docs/catalog/index#chain-ecosystems) covers them. > **Your own data: can I check it against Token Terminal's tags?** > > Yes, entirely inside your own project. Join your holder table to the linked `facts_accounts` and `dimensions` datasets on `account_id`, spelled `{address}-{chain_id}` after lowercasing an EVM address. We never receive an address, an `account_id`, or any per-wallet row from you: what reaches us, if you choose to send it, is an aggregate with any group under 10 wallets already dropped. ## Querying > **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. > **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. > **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. > **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. ## Levels and identifiers > **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. > **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. > **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` answers how much of it is out there in some form, counting tokens outstanding rather than economic value. > **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}`. ## Market verticals and coverage > **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. > **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. Some measures also carry through from a previously served figure rather than from onchain facts. [Projects ▸ Metrics](/docs/catalog/projects/metrics) and [Apps ▸ Metrics](/docs/catalog/apps/metrics) list what each table holds. > **How far back does history go?** > > It varies from table to table and chain to chain. Each chain page lists its layers' start dates. # Human's manual Source: https://tokenterminal.com/docs/catalog/humans-manual How the catalog is organized, how its tables are named, and how to read a page. The catalog is a set of BigQuery tables. These docs describe every one of them, and every page follows the same shape. This page explains the organization, the table names, the parts of a page and the marks on it. ## Organization The catalog is one set of tables, presented four ways.
Band What it is
[Popular datasets](/docs/catalog/index#popular-datasets) A dataset that belongs to no single market and no single chain: Financial statements, User retention, Prices, Agentic payments, Yields, Token transfers, Geographic intelligence and P\&L. Each one answers a question on its own terms, so its shape follows the question rather than the house pattern. The entity keys still join: every row carries a `project_id`, `chain_id`, `asset_id`, `token_id` or account address.
[Market verticals](/docs/catalog/index#market-verticals) A cross-chain slice into one market: Stablecoins, Real-world assets, DEX, Perpetuals, Lending, Bridges and the rest. A market is the entity tables with one filter applied, so its pages point back at the tables the entities own.
[Chain ecosystems](/docs/catalog/index#chain-ecosystems) One chain's slice across every market: its raw blocks and transactions, then every entity and market layer with data on that chain. Each chain page lists the layers the chain carries and the date each one starts.
[Core entities](/docs/catalog/index#core-entities) The model of the system and the actors in it. A project runs apps on chains and issues assets; an asset is deployed as tokens; tokens move between accounts. Every table in the catalog is keyed to one or more of those actors. Each entity section holds their registry, the events they take part in, and their daily numbers.
## Dataset types The dataset a table lives in says what kind of table it is. Each kind has its own icon in the sidebar. **Dimensions** **Dimensions** are the registry. A dimension is the metadata of every thing of one kind, one row per thing: its name, its identifiers and its classifications. `dimensions.assets` is every asset, `dimensions.chains` every chain, `dimensions.dex_pools` every trading pool. Nothing on a dimension row changes from day to day. Every other table joins a dimension on its id. The Registry page of each section documents them. > **[Assets ▸ Registry](/docs/catalog/assets/registry)** > > Asset names, where each is issued, and what each one tracks. > **[Projects ▸ Registry](/docs/catalog/projects/registry)** > > Project names, market sectors, and who runs what. > **[DEX ▸ Registry](/docs/catalog/dex/registry)** > > Pool identity, the fee it charges, its tokens, and who runs it. **Facts** **Facts** are events. A fact is one row per thing that happened onchain, at the time it happened: the block, the transaction, the accounts involved, the amount and the ids of the dimensions it belongs to. `facts_tokens.transfers` is every token transfer, `facts_bridge_tokens.transfers` every cross-chain transfer, `facts_lending_markets.deposits` every deposit into a lending market. Amounts are in the token's own units; a USD value is a join to prices. Facts are the record every metric is built from. Each fact table has its own page, named by its event: Transfers, Trades, Deposits. > **[Tokens ▸ Transfers](/docs/catalog/tokens/transfers)** > > Every fungible token transfer. > **[Bridges ▸ Transfers](/docs/catalog/bridges/transfers)** > > Cross-chain bridge transfers, with the sending and arriving sides matched. > **[Perpetuals ▸ Trades](/docs/catalog/perpetuals/trades)** > > Individual perpetual trades. > **[Perpetuals ▸ Trades](/docs/catalog/perpetuals/trades)** > > Individual perpetual and order-book market trades. **Metrics** **Metrics** are aggregates over a period. Each measure has its own table, holding one row per thing per period with that thing's identifier columns and one value column: daily for most tables, hourly for prices. Some tables also have a `provenance` column naming which source supplied that row (see Marks). Every measure of one kind of thing sits in one dataset, so `metrics_assets.market_cap_circulating_daily` is every asset's supply on every day and `metrics_tokens.price_hourly` is every token's price every hour. Reading two measures at once is a join on the thing's id and the period. Metrics are built from the facts and keyed to the same dimensions, so a metric row joins its registry row on the same id. The Metrics page of each section documents them, and [Metric definitions](/docs/catalog/metric-definitions) holds the unit and the combination rule of every measure. > **[Assets ▸ Metrics](/docs/catalog/assets/metrics)** > > Daily asset tables: supply, holders, transfers, price, yield and the gap from peg. > **[Projects ▸ Metrics](/docs/catalog/projects/metrics)** > > TVL, Fees, Revenue, Token incentives, Active users and sector-specific volume per project and per project on one chain. > **[Tokens ▸ Prices](/docs/catalog/tokens/metrics)** > > One USD price per token per day, and per hour. **Reports** **Reports** are a set of measures pre-joined into one row, for a question you would otherwise answer by joining several metrics tables. A report row is one thing for one period, carrying every measure the question needs side by side, so `reports_projects.financial_statements_quarterly` is one project's income statement and treasury for a quarter, in one row, rather than a metrics table per line joined on project and period. Reports hold nothing the metrics tables do not: every column traces back to a measure, so a figure read here and the same figure read from its metrics table agree. Reach for a report when the question is already the one it answers, and for metrics when it is not. A period in the table name means the table carries history, one row per period. No period in the name means one row per thing, as of now. > **[Popular datasets ▸ Financial statements](/docs/catalog/popular-datasets/financial-statements)** > > A protocol's income statement and treasury, by reporting period. > **[Popular datasets ▸ User retention](/docs/catalog/popular-datasets/user-retention)** > > A protocol's monthly user cohorts, and the share of each still active in the months after signup. **Screeners** **Screeners** are one row per thing as of the last complete day, for ranking and filtering things against each other. A screener is generated from the thing's key and its measures: every column is `__`, one measure over one window from a day to a year or all history, under one aggregation, so `screeners.projects` holds `fees_30d_sum`, `fees_30d_trend` and `tvl_7d_change` side by side for every project. A report is curated instead: its columns were chosen to answer one question. Like a report, a screener holds nothing the metrics tables do not. > **[Projects ▸ Screener](/docs/catalog/projects/screener)** > > Every project's latest figures, with averages, totals and changes over six windows, in one row. > **[Chains ▸ Screener](/docs/catalog/chains/screener)** > > Every chain's latest figures and its apps' figures, with averages, totals and changes over six windows, in one row. > **[Assets ▸ Screener](/docs/catalog/assets/screener)** > > Every asset's latest figures across all chains, per chain and per token, with averages, totals and changes over six windows, in one row. **Functions** **Functions** are calculations on request. A function runs when you call it, for figures too numerous to store. `functions.calculate_latest_token_balances` returns every holder of a token and their balance, worked out from the token's transfers at query time. Function pages document them. > **[Tokens ▸ Balances](/docs/catalog/tokens/balances)** > > Holder balances on any past date, computed at query time. > **[Stablecoins ▸ Balances](/docs/catalog/stablecoins/balances)** > > Stablecoin holder balances at any past date, computed at query time. **Raw chain** **Raw chain datasets** stand apart from the others. Each chain has its own dataset named after it, holding the chain's own record in a standardized shape: `ethereum.transactions` is every Ethereum transaction, `solana.blocks` every Solana block. Chains of the same kind share one shape, so a query written for one EVM chain runs on another with the dataset name swapped. [Chain ecosystems](/docs/catalog/index#chain-ecosystems) document them. > **[Ethereum ▸ Raw](/docs/catalog/chain-verticals/evm/ethereum/raw)** > > The standardized Ethereum blocks, transactions, logs and internal calls. > **[Base ▸ Raw](/docs/catalog/chain-verticals/evm/base/raw)** > > The standardized Base blocks, transactions, logs and internal calls. > **[Solana](/docs/catalog/chain-verticals/solana/index)** > > Standardized Solana blocks, transactions, instructions, account activity and rewards. ## Table names A table name is `dataset.table`. The dataset says what kind of table it is, and for facts and metrics it also says which things the table is about. Things are plural in a table name and singular in the identifier column that joins them: `facts_lending_markets.deposits` carries `lending_market_id`, which joins `dimensions.lending_markets`. **Dimensions** `dimensions.`: the things, plural. One row per thing.
Table Reads as
`dimensions.assets` The registry of assets.
`dimensions.assets_by_chain` The registry of asset chains: one asset's deployments on one chain, taken together.
`dimensions.asset_tokens` The registry of asset tokens: one asset on one chain.
`dimensions.dex_pools` The registry of DEX pools.
`dimensions.lending_markets` The registry of lending markets.
`dimensions.metrics` The registry of measures: the unit and combination rule of every one.
**Facts** `facts_.`: the dataset names the thing the event happens to, plural; the table names the event, plural. One row per event. The thing's identifier column joins its dimension.
Table Thing Event Reads as
`facts_tokens.transfers` Token Transfer Transfers of tokens, one row per transfer.
`facts_bridge_tokens.transfers` Bridge Transfer Transfers across bridges, one row per cross-chain transfer with both legs paired.
`facts_lending_markets.deposits` Lending market Deposit Deposits into lending markets, one row per deposit.
`facts_perp_markets.trades` Perp market Trade Trades on perpetual markets, one row per leg of a fill.
**Metrics** `metrics_._`: the dataset names the **level**, the things measured, plural; two things joined means one row per pair, and every level rolls up to the one above it. The table names the **measure** and the **period**, the row's time step. One measure per table, so a row carries the level's identifier columns, the period column and one value column of the same name as the measure, plus `provenance` on the tables that have one (see Marks).
Table Level Measure Period
`metrics_assets.market_cap_circulating_daily` One asset Circulating market cap Day
`metrics_asset_tokens.holders_native_daily` One asset on one chain Holders Day
`metrics_projects.fees_daily` One project Fees Day
`metrics_projects_by_chain.fees_daily` One project on one chain Fees Day
`metrics_dex_pools_by_pair.trading_volume_daily` One pool, one traded pair Trading volume Day
`metrics_tokens.price_daily` One token Price Day
`metrics_tokens.price_hourly` One token Price Hour
**Reports** `reports_._`: the dataset names the **things** the report is about, plural, and the table names the **report** and the **period** each row covers. Unlike a metrics table it carries many measures rather than one, because the point of a report is that the joining is already done.
Table Reads as
`reports_projects.financial_statements_quarterly` One project's financial statement for one quarter, per row.
`reports_projects.financial_statements_yearly` The same statement over calendar years.
`reports_projects.user_retention_monthly` One project's users first active in one month, and the share of them active in each month after, per row.
**Screeners** `screeners.`: the dataset is the kind and the table names the **things**, plural. One row per thing as of the last complete day, `as_of`, so no period in the name. Each column is `__`, the window `max` meaning all history (`tvl_max_ath`).
Table Reads as
`screeners.projects` One project's figures as of the last complete day, per row.
`screeners.chains` The same for one chain.
`screeners.assets` The same for one asset, across every chain.
`screeners.assets_by_chain` The same for one asset on one chain, its deployments there taken together.
`screeners.asset_tokens` The same for one asset's token contract on one chain.
**Functions** `functions.calculate_`: `calculate_`, then what comes back. Called with arguments, in place of a table name.
Function Reads as
`functions.calculate_latest_token_balances` Calculates the latest balance of every holder of one token.
`functions.calculate_historical_eod_token_balances` Calculates every holder's balance of one token at the end of a past day.
**Raw chain** `.`: the chain's `chain_id` as the dataset, then the record type, plural. One row per block, transaction, log or call.
Table Reads as
`ethereum.blocks` Ethereum's blocks, one row per block.
`ethereum.transactions` Ethereum's transactions, one row per transaction.
`base.logs` Base's event logs, one row per log.
`solana.account_activity` Solana's account activity, one row per account touched per transaction.
## Page kinds Every page is one of the kinds below. Each kind has a fixed flow of parts, top to bottom. **Overview** The first page of a section.
Part What it holds
Intro What the entity or the market is, in a few sentences.
Pages One card per page in the section.
Coverage Every app the section covers, the chains each one runs on, and the project behind it. The query beside it returns the same table, live.
> **[Stablecoins ▸ Overview](/docs/catalog/stablecoins/index)** > > Every stablecoin: supply, holders, transfers and off-peg, across every chain. > **[Projects ▸ Overview](/docs/catalog/projects/index)** > > Protocols, the apps they run, and financial metrics at every level. > **[EVM ecosystem ▸ Overview](/docs/catalog/chain-verticals/evm/index)** > > Standardized blocks, transactions, logs and traces for every EVM chain. **Registry** The dimension tables of a section.
Part What it holds
Intro What the tables describe; with several tables, one bullet per table with its grain.
Columns Every column, its type and one line on what it holds. With several tables this is Tables: one tab per table, each with its own column table.
Sample queries One tab per question, each opening with a bold sentence saying what the query answers.
> **[Assets ▸ Registry](/docs/catalog/assets/registry)** > > Asset names, where each is issued, and what each one tracks. > **[Projects ▸ Registry](/docs/catalog/projects/registry)** > > Project names, market sectors, and who runs what. > **[Lending ▸ Registry](/docs/catalog/lending/registry)** > > Every lending market: one asset inside one lending pool. **Facts** One fact table, named by its event: Transfers, Trades, Deposits.
Part What it holds
Intro What the table records and what one row stands for: "one row per transfer".
Columns Every column, its type and one line on what it holds.
Coverage Every app these tables carry a figure for. Present when it is narrower than the section's own coverage.
Sample queries A yellow box naming the timestamp column to bound, then one tab per question.
Notes Caveats: what the table does not hold, or a rule that is easy to get wrong.
> **[Tokens ▸ Transfers](/docs/catalog/tokens/transfers)** > > Every fungible token transfer. > **[Bridges ▸ Transfers](/docs/catalog/bridges/transfers)** > > Cross-chain bridge transfers, with the sending and arriving sides matched. > **[Perpetuals ▸ Trades](/docs/catalog/perpetuals/trades)** > > Individual perpetual trades. > **[Perpetuals ▸ Trades](/docs/catalog/perpetuals/trades)** > > Individual perpetual and order-book market trades. **Metrics** The metrics tables of a section.
Part What it holds
Intro What is measured, and the dataset behind each level with the grain of its rows.
Tables One tab per level. Each tab lists that level's tables with the value column each one carries.
Coverage Every app these tables carry a figure for. Present when it is narrower than the section's own coverage.
Sample queries One tab per question, each bounded on `timestamp`.
Notes Caveats: which measures do not add up, and what an empty cell means.
> **[Assets ▸ Metrics](/docs/catalog/assets/metrics)** > > Daily asset tables: supply, holders, transfers, price, yield and the gap from peg. > **[Projects ▸ Metrics](/docs/catalog/projects/metrics)** > > TVL, Fees, Revenue, Token incentives, Active users and sector-specific volume per project and per project on one chain. > **[DEX ▸ Metrics](/docs/catalog/dex/metrics)** > > Daily volume, TVL, fees and flash-loan volume per pool and per pair. **Functions** The functions of a section.
Part What it holds
Intro What the functions compute and from which table.
Functions One tab per function: its parameters, what it returns, and what the result means.
Sample queries One tab per question, each calling a function in place of a table.
Notes Caveats: cost, and what a missing row means.
> **[Tokens ▸ Balances](/docs/catalog/tokens/balances)** > > Holder balances on any past date, computed at query time. > **[Stablecoins ▸ Balances](/docs/catalog/stablecoins/balances)** > > Stablecoin holder balances at any past date, computed at query time. **Worked view** A market's page over a table another section owns.
Part What it holds
Intro The filter that selects the market, and the pointer to the owning page: "Every column is documented at ...".
Sample queries One tab per question, with the filter applied.
Notes Caveats specific to the market.
> **[Stablecoins ▸ Transfers](/docs/catalog/stablecoins/transfers)** > > Every stablecoin transfer. > **[Stablecoins ▸ Metrics](/docs/catalog/stablecoins/metrics)** > > Daily supply, holders, transfers and off-peg, per stablecoin and per deployment. > **[Real-world assets ▸ Metrics](/docs/catalog/real-world-assets/metrics)** > > Daily real-world asset supply, holders, transfer activity, price and yield. **Chain overview** The first page of a chain section.
Part What it holds
Intro What the catalog holds for the chain and the dataset the chain's own record sits in.
Layers One row per layer with data on the chain, with the date the layer starts.
Filtering The `chain_id` filter that selects the chain in every catalog table, with one query.
> **[Ethereum ▸ Overview](/docs/catalog/chain-verticals/evm/ethereum/index)** > > Everything the catalog holds for Ethereum, from raw blocks to project activity. > **[Base ▸ Overview](/docs/catalog/chain-verticals/evm/base/index)** > > Everything the catalog holds for Base, from raw blocks to project activity. > **[Solana](/docs/catalog/chain-verticals/solana/index)** > > Standardized Solana blocks, transactions, instructions, account activity and rewards. **Chain layer** One layer on one chain: a worked view of that layer with the chain filter applied.
Part What it holds
Intro What the layer holds on this chain, and the pointer to the page that owns the columns.
Tables On the Raw page only: the chain's own tables, one line each.
Sample queries One tab per question, with `chain_id` fixed.
Notes Caveats specific to the chain.
> **[Ethereum ▸ Raw](/docs/catalog/chain-verticals/evm/ethereum/raw)** > > The standardized Ethereum blocks, transactions, logs and internal calls. > **[Ethereum ▸ DEX](/docs/catalog/chain-verticals/evm/ethereum/dex)** > > Ethereum trading pools, their daily volume, value locked and fees. > **[Base ▸ Stablecoins](/docs/catalog/chain-verticals/evm/base/stablecoins)** > > Every stablecoin issued on Base: supply, holders and transfers. **Archived roster** One page per family for the chains that have stopped, in place of a section each.
Part What it holds
Intro The tables the family carries, and that the record has ended, so both dates are final.
Chain tabs One tab per chain, holding a row per raw table with the earliest and latest month it covers.
> **[Archived chains ▸ EVM ecosystem](/docs/catalog/chain-verticals/archived/evm)** > > The archived EVM chains, and the months each raw table covers. > **[Archived chains ▸ Substrate ecosystem](/docs/catalog/chain-verticals/archived/substrate)** > > The archived Substrate chains, and the months each raw table covers. **Changelog** One page, one entry per week, for what changed in the catalog. The only dated page: its numbers are the week's.
Part What it holds
Entry One block per week, newest first, labelled with the Tuesday it was published.
Breaking A table or column renamed, dropped, retyped or re-keyed, a table retired or moved, a chain archived, with what a query does now on the same line. Present in every entry, even when it reads None.
New, Expanded, Fixed Tables that serve for the first time; more venues, chains, assets or history on a table that already served; corrections that changed numbers already queryable. Each line opens on the entity, linked to the page that documents it, then a verb from a fixed set: Add, Extend, Restore, Backfill, Fix.
> **[Changelog](/docs/catalog/changelog)** > > What changed in the catalog, week by week: new tables, wider coverage, corrections, and every breaking change with its migration. ## Marks
Mark Meaning
**In progress** A `Soon` tag beside a page title, a banner at the top of a page, or bold text on a card. The table is documented ahead of serving: the page is its spec, and the table lands behind it.
**New** A `New` tag beside a page title. The tables on the page serve, and the page landed in the last 30 days.
Since A date in a chain page's Layers table: the earliest day that layer holds for the chain.
Source A word in a Metrics page's table list. Ladder is summed from the entity's own markets and pools. Projected is the project's series attributed to the entity that reports it.
Provenance A column on the metrics tables that are built two ways. Its value is `ladder`, a figure summed from the thing's own markets and pools, or `projected`, the level above attributed down to it.
Warning box The table is large and split by day. The box names the column to bound. A query with no bound reads the whole table, and the whole table is billed to you.
Your BQ Project ID The field at the right end of the top bar. Write your project id there and the browser keeps it. Every sample query on every page rewrites itself to run in your project.
## Identifiers Simple identifiers are lowercase names. Combined identifiers join their parts with dashes.
Identifier Shape Example
`chain_id` Chain name `ethereum`
`asset_id` Asset name `usdc`
`project_id` Project name `uniswap`
`app_id` Project name and version `uniswap-v3`
`token_id` `{token_address}-{chain_id}` `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum`
`asset_token_id` `{asset_id}-{token_address}-{chain_id}` `usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum`
An asset is one identity across chains and a token is one contract on one chain: USDC is one row in `dimensions.assets`, one row per chain in `dimensions.assets_by_chain` and one row per token contract in `dimensions.asset_tokens`. EVM addresses are stored lowercase: wrap an address copied from a block explorer in `lower()` before matching it. Solana addresses are base58 and case-sensitive: stored and matched verbatim. [Accounts](/docs/catalog/accounts/index) covers the address rules. ## Numbers * **An empty cell is not zero.** It means no figure exists for that measure, for that thing, on that day. * **Units live in the metric definition.** `dimensions.metrics` names the unit of every measure: `usd`, `count`, `ratio` or `pct`. Ratios are fractions: an `apy` of `0.05` is five percent, and an `off_peg` of `-0.02` is two percent below peg. * **Every measure is additive, semi-additive or non-additive.** * **Additive**: flows, such as Fees or Trading volume. They add up across days and across things: a week is seven days added together, a project is its apps added together. * **Semi-additive**: balances, such as TVL or Supply. They add up across things but not across days: a week's figure is the last day's. * **Non-additive**: rates and counts of distinct addresses, such as APY or Active users. They add up neither way. [Metric definitions](/docs/catalog/metric-definitions) holds the class and the rule for every measure. * **A report or screener row holds many measures.** [Financial statements](/docs/catalog/popular-datasets/financial-statements) puts one period's figures side by side, flows summed over the period and balances read at its close. The [project screener](/docs/catalog/projects/screener) puts every window of every measure on one row, each column named `__`. ## Running a query **1. Get the share** The catalog arrives in your own Google Cloud project as a BigQuery share, and compute is billed to you. [Contact us](https://calendly.com/d/cv8h-mgf-n3g/token-terminal-api-demo) to arrange it. **2. Write your project id** Type your BigQuery project id into the field at the right end of the top bar. Every sample query on every page carries it. **3. Copy a sample query** Open the page for the table, pick the tab whose bold sentence matches your question, and copy the query. **4. Run it in BigQuery** Paste the query into the BigQuery console and run it. Keep the date bound the query came with, and widen it once the result looks right. # Data catalog Source: https://tokenterminal.com/docs/catalog/index Every table in the catalog, queryable from your own BigQuery project. Write your BigQuery Project ID in the top bar. Every sample query rewrites to use it and runs in your project as-is. Two manuals cover the catalog. The [Human's manual](/docs/catalog/humans-manual) explains how these pages are laid out and how to read a table name, a page and a number. The [Agent's manual](/docs/catalog/agents-manual) is the same catalog as one page a model reads before it writes a query: the naming grammar, the key columns, the partition rules, the units and the tables that are documented but not served yet. The Agent's manual is written in [caveman](https://github.com/juliusbrussee/caveman) format, which cuts English to the words that carry the rule: no articles, no auxiliary verbs, no hedging, no transitions. *Why use many token when few token do trick.* Identifiers, types, numbers and negations stay exact. Only the grammar goes. ## Popular datasets Datasets that belong to no single market and no single chain: financial statements, fact sheets, user retention, prices, agentic payments, yields, token transfers, geographic intelligence and P\&L. > **[Financial statements](/docs/catalog/popular-datasets/financial-statements)** > > A protocol's income statement and treasury, by reporting period. > **[Fact sheets](/docs/catalog/popular-datasets/fact-sheets)** > > What an issuer discloses about a tokenized asset, each value with its evidence, and the security it references. > **[User retention](/docs/catalog/popular-datasets/user-retention)** > > A protocol's monthly user cohorts, and the share of each still active in the months after signup. > **[Prices](/docs/catalog/popular-datasets/prices)** > > One USD price per token and per curated asset, per day. > **[Agentic payments](/docs/catalog/popular-datasets/agentic-payments)** > > Payments software makes without a person in the loop, by asset. > **[Yields](/docs/catalog/popular-datasets/yields)** > > The yield an asset pays, per asset and per deployment. > **[Token transfers](/docs/catalog/popular-datasets/token-transfers)** > > Every fungible token transfer, joined to the entity that issued it. > **[Geographic intelligence](/docs/catalog/popular-datasets/geographic-intelligence)** > > Region of activity, funding venue and attested country for an address, with jurisdiction from venues that serve one country. > **[P\&L](/docs/catalog/popular-datasets/pnl)** > > What an account paid for its tokens and what they are worth now. **In progress.** ## Market verticals Curated verticals for every market, stablecoins to bridges, each followed across every chain. > **[Stablecoins](/docs/catalog/stablecoins/index)** > > Every stablecoin: supply, holders, transfers and off-peg, across every chain. > **[Real-world assets](/docs/catalog/real-world-assets/index)** > > Every tokenized stock, fund and commodity: supply, holders and price against the underlying, across every chain. > **[DEX](/docs/catalog/dex/index)** > > Every trading pool: swaps, volume, TVL and fees, across every DEX. > **[Perpetuals](/docs/catalog/perpetuals/index)** > > Every perpetual and order-book market: trades, open interest, funding and liquidations, across every venue. > **[Lending](/docs/catalog/lending/index)** > > Every lending market: supply, borrows and rates, across every protocol. > **[Bridges](/docs/catalog/bridges/index)** > > Every cross-chain transfer: matched legs, USD value and daily volume, across every bridge. > **[Liquid staking](/docs/catalog/liquid-staking)** > > Every liquid staking protocol: staked value, flows and yield, across every chain. **In progress.** > **[Prediction markets](/docs/catalog/prediction-markets)** > > Every outcome market: trades, volume and positions, across every venue. **In progress.** > **[DEX aggregators](/docs/catalog/dex-aggregators)** > > Every aggregator: routed swaps and volume, across every venue. **In progress.** > **[Asset management](/docs/catalog/asset-management)** > > Every managed vault: deposits, value locked and returns, across every protocol. **In progress.** ## Chain ecosystems Everything on one chain, from raw blocks to asset and project metrics, across every market. Chains that work the same way internally share a family, so they carry the same tables and a query written for one runs on another with the chain name swapped. > **[Solana](/docs/catalog/chain-verticals/solana/index)** > > Solana from raw slots up: projects, apps, assets, tokens, contracts and its trading pools. > **[Hyperliquid](/docs/catalog/chain-verticals/hyperliquid/index)** > > HyperCore's exchange: raw fills and funding, and the perpetual and order-book markets above them. > **[EVM ecosystem](/docs/catalog/chain-verticals/evm/index)** > > Ethereum, Base, Arbitrum and the wider EVM family: blocks, transactions, logs and traces. > **[UTXO ecosystem](/docs/catalog/chain-verticals/bitcoin/index)** > > Bitcoin, Litecoin, Dogecoin and Stacks: blocks, transactions, inputs and outputs. > **[Move ecosystem](/docs/catalog/chain-verticals/move/index)** > > Aptos, Sui and Movement: transactions, events and objects. > **[Cosmos ecosystem](/docs/catalog/chain-verticals/cosmos/index)** > > Cosmos Hub, Injective and the wider Cosmos SDK family: blocks, transactions and messages. > **[Substrate ecosystem](/docs/catalog/chain-verticals/substrate/index)** > > Polkadot and the wider Substrate family: blocks, extrinsics and events. > **[Other ecosystems](/docs/catalog/chain-verticals/other/index)** > > Chains that match no family, each with its own table shape. ## Core entities The core actors in almost every blockchain transaction. > **[Projects](/docs/catalog/projects/index)** > > A business that operates a network, deploys apps or issues assets, such as Ethereum, Aave or Circle. > **[Chains](/docs/catalog/chains/index)** > > The blockchain a project's apps run on, such as Ethereum or Solana. > **[Apps](/docs/catalog/apps/index)** > > One deployed version of a protocol that a project runs, such as Uniswap v3 or Aave v3. > **[Markets](/docs/catalog/markets/index)** > > A venue where a trade, a loan or a position happens, such as a Uniswap v3 pool or the BTC perpetual. > **[Assets](/docs/catalog/assets/index)** > > A financial instrument issued onchain, such as a stablecoin or a tokenized fund. > **[Tokens](/docs/catalog/tokens/index)** > > A token contract on one chain, such as USDC on Ethereum. > **[Accounts](/docs/catalog/accounts/index)** > > A wallet or a contract, such as an exchange wallet or a Uniswap pool. > **[Contracts](/docs/catalog/contracts/index)** > > Code deployed to an address, such as the Uniswap v3 factory on Ethereum. # Borrows Source: https://tokenterminal.com/docs/catalog/lending/borrows Every borrow from a lending market. One row per borrow from a lending market. `amount` is the tokens drawn, and [Interest rates](/docs/catalog/lending/interest-rates) has the rate that applied. ## Columns
Column Type Description
`block_timestamp`TIMESTAMPTime of the block containing the borrow. Partition column.
`block_number`INT64Number of the block containing the borrow.
`transaction_hash`STRINGHash of the transaction that emitted the borrow event.
`log_index`INT64Position of the borrow event in the block.
`unique_id`INT64Row key: fingerprint of chain\_id, block\_number, transaction\_hash, log\_index.
`event_type`STRINGConstant 'borrows'; stacking key across the lending facts.
`project_id`STRINGProtocol operating the market, such as aave.
`app_id`STRINGDeployment of the protocol the market belongs to.
`chain_id`STRINGChain the borrow happened on.
`lending_market_id`STRINGMarket the borrow left; joins `dimensions.lending_markets`.
`lending_market_reserve_id`STRINGReserve within the market; joins `dimensions.lending_market_reserves`.
`lending_market_contract_address`STRINGContract the market lives on; not a key.
`receipt_token_address`STRINGDebt token whose balance moved (the variable debt token for Aave); null where debt is not tokenised.
`token_id`STRINGToken borrowed: \{token\_address}-\{chain\_id}.
`token_address`STRINGContract address of the token borrowed.
`token_symbol`STRINGSymbol of the token borrowed.
`token_decimals`INT64Decimals of the token borrowed.
`borrower_address`STRINGAccount the borrowed tokens went to (the delegatee under credit delegation).
`user_address`STRINGAccount whose debt rose; the position key across the lending facts.
`shares_raw`BIGNUMERICMovement in the protocol's debt unit, exact integer; summing per position replays the borrow-share balance.
`shares`BIGNUMERICshares\_raw decimal-corrected.
`amount_raw`BIGNUMERICEvent-time amount in the token's stored unit, exact integer.
`amount`BIGNUMERICamount\_raw decimal-corrected into whole tokens. \*/}
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One day, one app** `amount` is whole tokens and `amount_raw` the integer the contract emitted. `user_address` is whose debt rose. ```sql theme={null} select events.block_timestamp, events.token_symbol, events.amount, events.user_address from `facts_lending_markets.borrows` as events where events.block_timestamp >= timestamp('2026-09-01') and events.block_timestamp < timestamp('2026-09-02') and events.chain_id = 'ethereum' and events.app_id = 'aave-v3' limit 100 ``` **Daily borrows per app** Group by `token_symbol` as well as app: `amount` is in each token's own units, so one sum per token is the comparable figure. ```sql theme={null} select date(events.block_timestamp) as day, events.app_id, events.token_symbol, sum(events.amount) as borrowed from `facts_lending_markets.borrows` as events where events.block_timestamp >= timestamp('2026-08-01') and events.block_timestamp < timestamp('2026-09-01') and events.chain_id = 'ethereum' group by day, events.app_id, events.token_symbol order by day, borrowed desc ``` # Deposits Source: https://tokenterminal.com/docs/catalog/lending/deposits Every deposit into a lending market. One row per deposit into a lending market. `amount` is the tokens supplied, and summing it per `user_address` replays a position. ## Columns
Column Type Description
`block_timestamp`TIMESTAMPTime of the block containing the deposit. Partition column.
`block_number`INT64Number of the block containing the deposit.
`transaction_hash`STRINGHash of the transaction that emitted the deposit event.
`log_index`INT64Position of the deposit event in the block.
`unique_id`INT64Row key: fingerprint of `chain_id`, `block_number`, `transaction_hash`, `log_index`.
`event_type`STRINGConstant `deposits`; stacking key across the lending facts.
`project_id`STRINGProtocol operating the market, such as `aave`.
`app_id`STRINGDeployment of the protocol the market belongs to.
`chain_id`STRINGChain the deposit happened on.
`lending_market_id`STRINGMarket the deposit entered; joins `dimensions.lending_markets`.
`lending_market_reserve_id`STRINGReserve within the market; joins `dimensions.lending_market_reserves`.
`lending_market_contract_address`STRINGContract the market lives on; not a key.
`receipt_token_address`STRINGReceipt token whose balance moved (the aToken for Aave); null where positions are not tokenised.
`token_id`STRINGToken deposited: `{token_address}-{chain_id}`.
`token_address`STRINGContract address of the token deposited.
`token_symbol`STRINGSymbol of the token deposited.
`token_decimals`INT64Decimals of the token deposited.
`depositor_address`STRINGAccount that acted: the supplier, or the sender on a receipt-token transfer.
`user_address`STRINGAccount whose supplied balance rose; the position key across the lending facts.
`shares_raw`BIGNUMERICMovement in the protocol's interest-bearing unit, exact integer; summing per position replays the share balance.
`shares`BIGNUMERIC`shares_raw` decimal-corrected.
`amount_raw`BIGNUMERICEvent-time amount in the token's stored unit, exact integer.
`amount`BIGNUMERIC`amount_raw` decimal-corrected into whole tokens.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One day, one app** `amount` is whole tokens and `amount_raw` the integer the contract emitted. `user_address` is whose supplied balance rose, and the account to group a position by. ```sql theme={null} select events.block_timestamp, events.token_symbol, events.amount, events.user_address from `facts_lending_markets.deposits` as events where events.block_timestamp >= timestamp('2026-09-01') and events.block_timestamp < timestamp('2026-09-02') and events.chain_id = 'ethereum' and events.app_id = 'aave-v3' order by events.amount desc limit 100 ``` **Daily deposits per app** Group by `token_symbol` as well as app: `amount` is in each token's own units, so one sum per token is the comparable figure. ```sql theme={null} select date(events.block_timestamp) as day, events.app_id, events.token_symbol, sum(events.amount) as deposited from `facts_lending_markets.deposits` as events where events.block_timestamp >= timestamp('2026-08-01') and events.block_timestamp < timestamp('2026-09-01') and events.chain_id = 'ethereum' group by day, events.app_id, events.token_symbol order by day, deposited desc ``` **Net supply for one user** Deposits are the increase and [Withdrawals](/docs/catalog/lending/withdrawals) the decrease, so sign each side and sum. `event_type` is a constant on every lending fact, which keeps track of the source table across a wider `union all`. ```sql theme={null} with movements as ( select token_symbol, amount from `facts_lending_markets.deposits` where block_timestamp >= timestamp('2026-08-01') and chain_id = 'ethereum' and user_address = '0x0000000000000000000000000000000000000000' union all select token_symbol, -amount from `facts_lending_markets.withdrawals` where block_timestamp >= timestamp('2026-08-01') and chain_id = 'ethereum' and user_address = '0x0000000000000000000000000000000000000000' ) select token_symbol, sum(amount) as net_supplied from movements group by token_symbol order by net_supplied desc ``` # Flash loans Source: https://tokenterminal.com/docs/catalog/lending/flash-loans Every flash loan: borrowed and repaid inside one transaction. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! One row per flash loan, borrowed and repaid inside one transaction. `amount_raw` is the tokens drawn and `premium_raw` the fee paid for them. # Lending Source: https://tokenterminal.com/docs/catalog/lending/index Every lending market: supply, borrows and rates, across every protocol. Deposits, borrows, collateral and rates for every lending protocol Token Terminal tracks, from the protocol down to the individual market and the token inside it. ## Coverage A tab per grain, then the events and the chains. Each tab says what one row is, and a tick marks every app that reports it. **Project** A project is the business behind the protocol, such as `aave`. One row per project per day, every version and chain together.
App Project TVL Active loans Fees Supply-side fees Revenue
`aave-v2``aave`✓✓✓✓✓
`aave-v3``aave`✓✓✓✓✓
`aave-v4``aave`✓✓✓✓✓
`benddao-lending``benddao`✗✓✓✓✓
`benqi-lending``benqi`✗✓✓✓✓
`chainflip-lending``chainflip`✓✓✓✓✓
`compound-lending``compound`✓✓✓✓✓
`curve-llamalend``curve`✓✓✓✓✓
`dolomite-lending``dolomite`✓✓✓✓✓
`etherfi-cash``etherfi`✓✓✓✓✓
`euler-lending``euler`✓✓✓✓✓
`flux-lending``flux`✓✓✗✗✗
`flyingtulip-lend``flyingtulip`✓✓✓✓✓
`fraxlend-lending``fraxlend`✓✓✗✗✗
`gearbox-lending``gearbox`✗✓✓✓✓
`goldfinch-lending``goldfinch`✗✓✓✓✓
`hydradx-lending``hydradx`✓✓✓✓✓
`hyperlend-lending``hyperlend`✓✓✓✓✓
`instadapp-fluid``instadapp`✓✓✓✓✓
`instadapp-fluid-lite``instadapp`✓✓✓✓✓
`instadapp-fluid-vault``instadapp`✓✓✓✓✓
`instadapp-jupiter-lend``instadapp`✓✓✓✓✓
`instadapp-venus-flux``instadapp`✓✓✓✓✓
`jupiter-lend``jupiter`✓✓✓✓✓
`kamino-lend``kamino`✓✓✗✗✗
`maple-institutional``maple`✓✓✓✓✓
`maple-other-pools``maple`✓✓✓✓✓
`moonwell-lending``moonwell`✓✓✓✓✓
`morpho-blue``morpho`✓✓✓✓✓
`morpho-midnight``morpho`✓✓✓✓✓
`morpho-optimizer``morpho`✓✓✓✓✓
`notional-lending``notional`✓✗✓✓✓
`primenumbers-primefi-lending``primenumbers`✓✓✓✓✓
`prismafinance-lending``prismafinance`✓✗✗✗✗
`radiant-lending``radiant`✓✓✓✓✓
`seamlessprotocol-ilms``seamlessprotocol`✓✓✓✓✓
`seamlessprotocol-lending``seamlessprotocol`✓✓✓✓✓
`seamlessprotocol-leverage-tokens``seamlessprotocol`✓✓✓✓✓
`shoebill-lending``shoebill`✓✓✓✓✓
`silo-lending``silo`✓✓✓✓✓
`spark-lend``spark`✓✓✓✓✓
`truefi-lending``truefi`✗✓✓✓✓
`venus-flux``venus`✓✓✓✓✓
`venus-lending``venus`✓✓✓✓✓
`zerolend-lending``zerolend`✓✓✓✓✓
**App** An app is one deployed version of a protocol, such as `aave-v3`. One row per app per day, across every chain it runs on.
App Project TVL Active loans Fees Supply-side fees Revenue
`aave-v2``aave`✓✓✓✓✓
`aave-v3``aave`✓✓✓✓✓
`aave-v4``aave`✓✓✓✓✓
`chainflip-lending``chainflip`✓✓✓✓✓
`curve-llamalend``curve`✓✓✗✗✗
`etherfi-cash``etherfi`✓✓✓✓✓
`euler-lending``euler`✗✗✓✓✓
`flyingtulip-lend``flyingtulip`✓✓✓✓✓
`hydradx-lending``hydradx`✓✓✓✓✓
`instadapp-fluid``instadapp`✓✓✗✓✓
`instadapp-fluid-lite``instadapp`✓✗✓✓✓
`instadapp-fluid-vault``instadapp`✗✗✓✓✓
`instadapp-jupiter-lend``instadapp`✓✓✓✓✓
`instadapp-venus-flux``instadapp`✓✓✓✓✓
`jupiter-lend``jupiter`✓✓✓✓✓
`kamino-lend``kamino`✓✓✗✗✗
`maple-institutional``maple`✓✓✗✗✗
`maple-other-pools``maple`✓✓✗✗✗
`morpho-blue``morpho`✓✓✓✓✓
`morpho-midnight``morpho`✓✓✗✗✗
`morpho-optimizer``morpho`✓✓✓✓✓
`primenumbers-primefi-lending``primenumbers`✓✓✓✓✓
`seamlessprotocol-ilms``seamlessprotocol`✓✓✗✗✗
`seamlessprotocol-lending``seamlessprotocol`✓✓✓✓✓
`seamlessprotocol-leverage-tokens``seamlessprotocol`✓✓✓✗✗
`spark-lend``spark`✓✓✓✓✓
`venus-flux``venus`✓✓✓✓✓
`venus-lending``venus`✓✓✓✓✓
**Market** A market is one pool of deposits that borrowers draw against, such as Aave v3's `Core` market on Ethereum. One row per market per day.
App Project TVL Active loans Collateral
`aave-v3``aave`✓✓✓
`aave-v4``aave`✓✓✓
`morpho-blue``morpho`✓✓✓
**Reserve** A reserve is one asset inside one market, such as `USDC` in Aave v3's `Core` market. One row per market and token per day.
App Project TVL Active loans Collateral
`aave-v3``aave`✓✓✓
`aave-v4``aave`✓✓✓
`morpho-blue``morpho`✓✓✓
**Events** One row per lending event, at the moment it happened onchain. Amounts are in the token's own units; join [Prices](/docs/catalog/tokens/metrics) for a USD figure.
App Project Deposits Withdrawals Borrows Repayments Liquidations Interest rates
`aave-v2``aave`✓✓✓✓✓✓
`aave-v3``aave`✓✓✓✓✓✓
`aave-v4``aave`✓✓✓✓✓✗
`hyperlend-lending``hyperlend`✓✓✓✓✓✓
`morpho-blue``morpho`✓✓✓✓✓✗
`spark-lend``spark`✓✓✓✓✓✓
**Chains** Every chain the section covers.
Chain Apps
`aptos``aave-v3`
`arbitrum``aave-v3`, `instadapp-fluid`, `morpho-blue`, `venus-lending`
`avalanche``aave-v2`, `aave-v3`, `aave-v4`
`base``aave-v3`, `instadapp-fluid`, `morpho-blue`, `morpho-midnight`, `seamlessprotocol-ilms`, `seamlessprotocol-lending`, `seamlessprotocol-leverage-tokens`, `venus-lending`
`bsc``aave-v3`, `instadapp-venus-flux`, `venus-flux`, `venus-lending`
`celo``aave-v3`, `morpho-blue`
`chainflip``chainflip-lending`
`ethereum``aave-v2`, `aave-v3`, `aave-v4`, `curve-llamalend`, `flyingtulip-lend`, `instadapp-fluid`, `instadapp-fluid-lite`, `maple-institutional`, `maple-other-pools`, `morpho-blue`, `morpho-optimizer`, `seamlessprotocol-leverage-tokens`, `spark-lend`, `venus-lending`
`gnosis``aave-v3`, `spark-lend`
`hydradx``hydradx-lending`
`hyperevm``morpho-blue`
`ink``morpho-blue`
`katananetwork``morpho-blue`
`linea``aave-v3`
`monad``aave-v3`, `morpho-blue`
`opbnb``venus-lending`
`optimism``aave-v3`, `etherfi-cash`, `morpho-blue`, `venus-lending`
`plasma``aave-v3`, `instadapp-fluid`, `morpho-blue`
`polygon``aave-v2`, `aave-v3`, `instadapp-fluid`, `morpho-blue`
`robinhoodchain``morpho-blue`
`scroll``aave-v3`, `etherfi-cash`, `morpho-blue`
`solana``instadapp-jupiter-lend`, `jupiter-lend`, `kamino-lend`
`sonic``aave-v3`, `flyingtulip-lend`, `morpho-blue`
`unichain``morpho-blue`, `venus-lending`
`worldchain``morpho-blue`
`xdc``primenumbers-primefi-lending`
`zksyncera``aave-v3`, `venus-lending`
## Tables [Metrics](/docs/catalog/lending/metrics) holds the daily table schemas at each grain and example queries. [Registry](/docs/catalog/lending/registry) holds the identity tables. Each event has its own page and its own table: [Deposits](/docs/catalog/lending/deposits), [Withdrawals](/docs/catalog/lending/withdrawals), [Borrows](/docs/catalog/lending/borrows), [Repayments](/docs/catalog/lending/repayments), [Liquidations](/docs/catalog/lending/liquidations), [Interest rates](/docs/catalog/lending/interest-rates) and [Flash loans](/docs/catalog/lending/flash-loans). # Interest rates Source: https://tokenterminal.com/docs/catalog/lending/interest-rates Every rate update in every lending market. One row per rate update in a lending market. `deposit_interest_rate` and `borrow_interest_rate` are annual fractions. Read `interest_rate_type` first: it says whether a row's rates apply from that block onward or over the interval that just closed. ## Columns
Column Type Description
`block_timestamp`TIMESTAMPTime of the block containing the rate update. Partition column.
`block_number`INTEGERNumber of the block containing the rate update.
`transaction_hash`STRINGHash of the transaction that emitted the rate update.
`log_index`INTEGERPosition of the rate update in the block.
`unique_id`INTEGERRow key: fingerprint of `chain_id`, `block_number`, `transaction_hash`, `log_index`, `lending_market_reserve_id`. The reserve is part of the key because one rate update can apply to several reserves at once.
`event_type`STRINGConstant `interest_rates`; stacking key across the lending facts.
`project_id`STRINGProtocol operating the market, such as `aave`.
`app_id`STRINGDeployment of the protocol the market belongs to.
`chain_id`STRINGChain the rate update happened on.
`lending_market_id`STRINGMarket the rate applies to; joins `dimensions.lending_markets`.
`lending_market_reserve_id`STRINGReserve the rate applies to; joins `dimensions.lending_market_reserves`.
`lending_market_contract_address`STRINGContract the market lives on; not a key.
`token_id`STRINGToken the rate applies to: `{token_address}-{chain_id}`.
`token_address`STRINGContract address of that token.
`token_symbol`STRINGSymbol of that token.
`deposit_index`FLOATCumulative interest index on the supply side, starting at 1. The ratio between two rows is what a supplied balance earned between them. Where a protocol reports a realized share price rather than an accumulator (Morpho Blue), it can fall below 1 after a market absorbs bad debt, and the ratio then reads the loss as well as the interest.
`borrow_index`FLOATCumulative interest index on the borrow side, starting at 1. The ratio between two rows is what a debt accrued between them. Over long gaps between rows this ratio and the annualized rate diverge, because Morpho accrues on a truncated series while quoting APY on the exponential; the index is the realized figure.
`interest_rate_type`STRINGHow to read the two rates. `forward-looking` means they apply from this block onward (Aave, Spark, HyperLend); `backward-looking` means they applied over the interval that ended at this block (Morpho Blue). Constant per protocol.
`deposit_interest_rate`FLOATAnnual rate paid to suppliers, as a fraction: `0.05` reads 5%.
`borrow_interest_rate`FLOATAnnual rate charged to borrowers, as a fraction: `0.05` reads 5%.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One day, one app** A market updates its rates whenever its utilization moves, so an active reserve has many rows in a day. `deposit_interest_rate` and `borrow_interest_rate` are annual fractions. ```sql theme={null} select events.block_timestamp, events.token_symbol from `facts_lending_markets.interest_rates` as events where events.block_timestamp >= timestamp('2026-09-01') and events.block_timestamp < timestamp('2026-09-02') and events.chain_id = 'ethereum' and events.app_id = 'aave-v3' limit 100 ``` **Daily rate updates per app** A row is a rate update on one reserve. Some apps price a whole asset at once, and every reserve borrowing that asset then gets its own row, so this counts reserve updates rather than repricings. To count repricings, count distinct `block_number`, `transaction_hash` and `log_index`: one transaction can reprice several assets, so block and transaction alone undercounts. ```sql theme={null} select date(events.block_timestamp) as day, events.app_id, count(*) as updates from `facts_lending_markets.interest_rates` as events where events.block_timestamp >= timestamp('2026-08-01') and events.block_timestamp < timestamp('2026-09-01') and events.chain_id = 'ethereum' group by day, events.app_id order by day, updates desc ``` # Liquidations Source: https://tokenterminal.com/docs/catalog/lending/liquidations Every liquidation of an undercollateralized borrower. One row per liquidation, with the collateral seized and the debt repaid on the same row. `collateral_amount` is the tokens seized and `borrow_amount` the debt cleared. ## Columns
Column Type Description
`block_timestamp`TIMESTAMPTime of the block containing the liquidation. Partition column.
`block_number`INTEGERNumber of the block containing the liquidation.
`transaction_hash`STRINGHash of the transaction that emitted the liquidation event.
`log_index`INTEGERPosition of the liquidation event in the block.
`unique_id`INTEGERRow key: fingerprint of `chain_id`, `block_number`, `transaction_hash`, `log_index`.
`event_type`STRINGConstant `liquidations`; stacking key across the lending facts.
`project_id`STRINGProtocol operating the market, such as `aave`.
`app_id`STRINGDeployment of the protocol the market belongs to.
`chain_id`STRINGChain the liquidation happened on.
`lending_market_id`STRINGMarket holding the debt that was repaid; joins `dimensions.lending_markets`.
`lending_market_contract_address`STRINGContract the market lives on; not a key.
`lending_position_id`STRINGThe liquidated position: one borrower inside one market.
`collateral_lending_market_reserve_id`STRINGReserve the seized collateral sat in; joins `dimensions.lending_market_reserves`.
`collateral_lending_market_reserve_position_id`STRINGThe borrower's holding in that collateral reserve.
`collateral_receipt_token_address`STRINGReceipt token whose balance moved on the collateral side; null where positions are not tokenised.
`borrow_lending_market_reserve_id`STRINGReserve the repaid debt sat in; joins `dimensions.lending_market_reserves`.
`borrow_lending_market_reserve_position_id`STRINGThe borrower's debt in that reserve.
`borrow_receipt_token_address`STRINGDebt token whose balance moved on the borrow side; null where debt is not tokenised.
`liquidator_address`STRINGAccount that repaid the debt and took the collateral.
`borrower_address`STRINGAccount that was liquidated; the position key across the lending facts.
`collateral_token_id`STRINGCollateral token seized: `{token_address}-{chain_id}`.
`collateral_token_address`STRINGContract address of the collateral token.
`collateral_token_symbol`STRINGSymbol of the collateral token.
`collateral_token_decimals`INTEGERDecimals of the collateral token.
`borrow_token_id`STRINGDebt token repaid: `{token_address}-{chain_id}`.
`borrow_token_address`STRINGContract address of the debt token.
`borrow_token_symbol`STRINGSymbol of the debt token.
`borrow_token_decimals`INTEGERDecimals of the debt token.
`collateral_to_liquidator_amount_raw`BIGNUMERICShare of the seized collateral paid to the liquidator, in the token's stored unit, exact integer.
`collateral_to_liquidator_amount`BIGNUMERIC`collateral_to_liquidator_amount_raw` decimal-corrected into whole tokens.
`collateral_to_treasury_amount_raw`BIGNUMERICShare of the seized collateral kept by the protocol, in the token's stored unit, exact integer.
`collateral_to_treasury_amount`BIGNUMERIC`collateral_to_treasury_amount_raw` decimal-corrected into whole tokens.
`collateral_amount_raw`BIGNUMERICCollateral seized in total, exact integer; the liquidator share and the treasury share add up to it.
`collateral_amount`BIGNUMERIC`collateral_amount_raw` decimal-corrected into whole tokens.
`borrow_amount_raw`BIGNUMERICDebt repaid in the token's stored unit, exact integer.
`borrow_amount`BIGNUMERIC`borrow_amount_raw` decimal-corrected into whole tokens.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One day, one app** Each row has two token legs: the collateral seized and the debt repaid. `borrower_address` is the position that was closed and `liquidator_address` the account that closed it. ```sql theme={null} select events.block_timestamp, events.collateral_token_symbol, events.collateral_amount, events.borrow_token_symbol, events.borrow_amount, events.borrower_address, events.liquidator_address from `facts_lending_markets.liquidations` as events where events.block_timestamp >= timestamp('2026-09-01') and events.block_timestamp < timestamp('2026-09-02') and events.chain_id = 'ethereum' and events.app_id = 'aave-v3' limit 100 ``` **Most liquidated collateral** Counting rows counts liquidation events; summing `collateral_amount` totals the tokens taken. Both are per collateral token, since the amounts are in each token's own units. ```sql theme={null} select events.collateral_token_symbol, count(*) as liquidations, sum(events.collateral_amount) as collateral_seized from `facts_lending_markets.liquidations` as events where events.block_timestamp >= timestamp('2026-08-01') and events.block_timestamp < timestamp('2026-09-01') and events.chain_id = 'ethereum' group by events.collateral_token_symbol order by liquidations desc limit 25 ``` **Collateral kept by the protocol** A liquidation splits the seized collateral between the liquidator's bonus and the protocol's cut. The two columns are those shares, and they add up to `collateral_amount`. ```sql theme={null} select date(events.block_timestamp) as day, events.app_id, sum(events.collateral_to_liquidator_amount) as to_liquidator, sum(events.collateral_to_treasury_amount) as to_treasury from `facts_lending_markets.liquidations` as events where events.block_timestamp >= timestamp('2026-08-01') and events.block_timestamp < timestamp('2026-09-01') and events.chain_id = 'ethereum' group by day, events.app_id order by day ``` # Metrics Source: https://tokenterminal.com/docs/catalog/lending/metrics Daily lending figures per project, app, market and reserve. TVL, active loans, collateral, fees and revenue, in USD. One row per thing per day, at four grains: project, app, market and reserve. TVL, active loans and collateral are balances, not flows. They add up across reserves, markets, apps and chains, but never across days: a week's figure is the last day in it, and adding seven days counts the same balance seven times. Fees and revenue are flows and add up both ways. [Metric definitions](/docs/catalog/metric-definitions) has the rule in full. ## Tables A tab per grain. [Coverage](/docs/catalog/lending) shows which apps report which measure. **Project** One row per project per day.
Table Value column What it holds
`metrics_projects.tvl_daily``tvl`Total value locked.
`metrics_projects.active_loans_daily``active_loans`USD value of open loans (outstanding borrows).
`metrics_projects.collateral_daily``collateral`USD value of deposits actively backing an open loan.
`metrics_projects.fees_daily``fees`Total fees paid by users.
`metrics_projects.fees_supply_side_daily``fees_supply_side`Fees paid out to the supply side.
`metrics_projects.revenue_daily``revenue`Fees retained by the protocol.
**App** One row per app per day.
Table Value column What it holds
`metrics_apps.tvl_daily``tvl`Total value locked in the app.
`metrics_apps.active_loans_daily``active_loans`USD value of open loans (outstanding borrows) across the app's lending markets.
`metrics_apps.collateral_daily``collateral`USD value of deposits actively backing an open loan across the app's lending markets.
`metrics_apps.fees_daily``fees`Fees paid by users of the app across every chain it runs on.
`metrics_apps.fees_supply_side_daily``fees_supply_side`Fees the app passed through to builders and, on HIP-3 markets, to market deployers.
`metrics_apps.revenue_daily``revenue`Fees the app retained across every chain it runs on.
**Market** One row per market per day.
Table Value column What it holds
`metrics_lending_markets.tvl_daily``tvl`USD value of deposits supplied to the lending market (idle + borrowed).
`metrics_lending_markets.active_loans_daily``active_loans`USD value of open loans (outstanding borrows) on the market.
`metrics_lending_markets.collateral_daily``collateral`USD value of deposits actively backing an open loan on the market.
**Reserve** One row per market and token per day.
Table Value column What it holds
`metrics_lending_market_reserves.tvl_daily``tvl`USD value of deposits supplied to the reserve (idle + borrowed).
`metrics_lending_market_reserves.active_loans_daily``active_loans`USD value of open loans (outstanding borrows) against the reserve.
`metrics_lending_market_reserves.collateral_daily``collateral`USD value of the reserve's deposits actively backing an open loan.
## Sample queries **One market's series** Each measure is its own table, so a row with both is a join on `lending_market_id` and `timestamp`, bounded on every side. Join the loans side with `left join`: a market can hold value with no loans open against it. ```sql theme={null} with markets as ( select lending_market_id, lending_market_name from `dimensions.lending_markets` where chain_id = 'ethereum' and app_id = 'aave-v3' ), locked as ( select lending_market_id, timestamp, tvl from `metrics_lending_markets.tvl_daily` where chain_id = 'ethereum' and timestamp >= timestamp('2026-06-01') ), loans as ( select lending_market_id, timestamp, active_loans from `metrics_lending_markets.active_loans_daily` where chain_id = 'ethereum' and timestamp >= timestamp('2026-06-01') ) select locked.timestamp, markets.lending_market_name, locked.tvl, loans.active_loans from locked join markets using (lending_market_id) left join loans using (lending_market_id, timestamp) order by locked.timestamp ``` **Every protocol, ranked** The project grain rolls up every app and chain a protocol runs, so one row is the protocol's whole business. ```sql theme={null} select project_id, active_loans from `metrics_projects.active_loans_daily` where timestamp = timestamp('2026-09-01') order by active_loans desc limit 25 ``` **One app across chains** `metrics_apps_by_chain` splits an app's daily figure by the chain it sits on, keyed on `app_id` and `chain_id` together. ```sql theme={null} select timestamp, chain_id, tvl from `metrics_apps_by_chain.tvl_daily` where app_id = 'aave-v3' and timestamp >= timestamp('2026-08-01') order by timestamp, tvl desc ``` # Registry Source: https://tokenterminal.com/docs/catalog/lending/registry Every lending market and the reserves inside each one. The identity tables behind every lending figure. Every fact and metric joins to one of them, and [Coverage](/docs/catalog/lending) introduces each grain. ## Tables **Projects** One row per project in the catalog.
Column Type Description
`project_id`STRINGThe project, such as `aave`.
`slug`STRINGThe project's key in Token Terminal page URLs. It differs from `project_id` where the page URL is hyphenated (`redstone-chain` for `redstonechain`).
`url`STRINGThe project's page on the Token Terminal Explorer.
`name`STRINGDisplay name.
`symbol`STRINGTicker of the project's token, where it has one.
`logo`STRINGPublic URL of the project logo, a PNG. Its `?logo_hash=` suffix changes whenever the image does. Null for a project whose image was never uploaded.
`description`STRUCTThe project copy: `what` the project is, `who` it serves and `how` it works.
`links`ARRAY\The project's links as `type` and `url` pairs (website, x, docs, github). `type` is the label as written, so `twitter` and `x` both occur.
`market_sectors`ARRAY\Every market sector the project belongs to, as tag ids, primary first. Unnesting it yields one row per sector.
`primary_market_sector`STRINGThe market sector the project is listed under: the first element of `market_sectors`. One value per row.
`listing_date`TIMESTAMPWhen the project was listed on Token Terminal.
`coingecko_id`STRINGThe project token's CoinGecko id.
`coinmarketcap_id`STRINGThe project token's CoinMarketCap id.
**Apps** One row per app in the catalog.
Column Type Description
`app_id`STRINGThe app, such as `aave-v3`.
`project_id`STRINGThe project operating it.
`name`STRINGDisplay name.
`market_sectors`ARRAY\Every sector the app is tagged with.
`primary_market_sector`STRINGThe first of those, for grouping.
`created_at`TIMESTAMPWhen the app was added.
**Markets** One row per lending market on one chain.
Column Type Description
`lending_market_id` `STRING` Market key, formatted `{lending_market}-{chain_id}`.
`app_id` `STRING` App operating the market, such as `aave-v3` or `morpho-blue`. Joins `dimensions.apps`.
`chain_id` `STRING` Chain the market lives on.
`project_id` `STRING` Project behind the app. Joins `dimensions.projects`.
`lending_market` `STRING` The protocol's own key for the market: the pool contract address on pool lenders, the market hash on Morpho Blue.
`lending_market_contract_address` `STRING` The deployed contract the market runs on. Matches `lending_market` on pool lenders; every Morpho Blue market on a chain shares one singleton contract.
`lending_market_name` `STRING` Readable name of the market, such as `Core` or `Morpho Blue: cbBTC/USDC 86%`. A label, not a key.
**Reserves** One row per reserve, one asset inside one market. An Aave pool lists one reserve per underlying token and a Morpho Blue market exactly two, the loan side and the collateral side; where a pool lists the same token twice, the key is the protocol's listing rather than the token.
Column Type Description
`lending_market_reserve_id` `STRING` Reserve key, formatted `{lending_market}-{lending_market_reserve}-{chain_id}`.
`lending_market_id` `STRING` Market the reserve belongs to. Joins `dimensions.lending_markets`.
`app_id` `STRING` App operating the market. Joins `dimensions.apps`.
`chain_id` `STRING` Chain the market lives on.
`project_id` `STRING` Project behind the app. Joins `dimensions.projects`.
`lending_market` `STRING` The protocol's own key for the market, copied from the market row.
`lending_market_contract_address` `STRING` The deployed contract the market runs on, copied from the market row.
`lending_market_name` `STRING` Readable name of the market, copied from the market row.
`lending_market_reserve` `STRING` The protocol's own key for the reserve inside its market: the underlying token address on Aave-style pools, `loan` or `collateral` on Morpho Blue, the numeric reserve id on Aave v4.
`lending_market_reserve_name` `STRING` Readable name: the market name and the token symbol, such as `Core: WETH`. A label, not a key.
`token_id` `STRING` Key of the underlying token in `dimensions.tokens`, formatted `{token_address}-{chain_id}`.
`token_address` `STRING` Address of the underlying token contract.
`token_symbol` `STRING` Ticker symbol of the underlying token.
## Sample queries **Markets per chain** A project can run several apps and each app several markets on a chain, so the count is per app and chain together. ```sql theme={null} select chain_id, app_id, count(*) as markets from `dimensions.lending_markets` where project_id = 'aave' group by chain_id, app_id order by markets desc ``` **Markets in one app** `lending_market_id` is the key every lending fact and metric joins on. `lending_market_contract_address` is what to look up onchain. ```sql theme={null} select lending_market_id, lending_market_name, chain_id, lending_market_contract_address from `dimensions.lending_markets` where app_id = 'aave-v3' order by chain_id, lending_market_name ``` **Reserves of one market** `lending_market_reserve` is the protocol's own key for the listing and `lending_market_reserve_id` the catalog key built from it. ```sql theme={null} select lending_market_reserve_id, lending_market_reserve, token_symbol, token_address from `dimensions.lending_market_reserves` where lending_market_id = '0xc13e21b648a5ee794902342038ff3adab66be987-ethereum' order by token_symbol ``` **Where one token is listed** `token_address` is the underlying token, not the receipt token an app issues against it. ```sql theme={null} select app_id, chain_id, lending_market_id, lending_market_name, lending_market_reserve from `dimensions.lending_market_reserves` where token_address = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48' and chain_id = 'ethereum' order by app_id, lending_market_name ``` # Repayments Source: https://tokenterminal.com/docs/catalog/lending/repayments Every loan repayment in a lending market. One row per repayment, including the debt leg of a liquidation. `amount` is the tokens returned, and [Liquidations](/docs/catalog/lending/liquidations) shows that same leg from the collateral side. ## Columns
Column Type Description
`block_timestamp`TIMESTAMPTime of the block containing the repayment. Partition column.
`block_number`INT64Number of the block containing the repayment.
`transaction_hash`STRINGHash of the transaction that emitted the repayment event.
`log_index`INT64Position of the repayment event in the block.
`unique_id`INT64Row key: fingerprint of chain\_id, block\_number, transaction\_hash, log\_index.
`event_type`STRINGConstant 'repayments'; stacking key across the lending facts.
`project_id`STRINGProtocol operating the market, such as aave.
`app_id`STRINGDeployment of the protocol the market belongs to.
`chain_id`STRINGChain the repayment happened on.
`lending_market_id`STRINGMarket the repayment entered; joins `dimensions.lending_markets`.
`lending_market_reserve_id`STRINGReserve within the market; joins `dimensions.lending_market_reserves`.
`lending_market_contract_address`STRINGContract the market lives on; not a key.
`receipt_token_address`STRINGDebt token whose balance moved (the variable debt token for Aave); null where debt is not tokenised.
`token_id`STRINGToken repaid: \{token\_address}-\{chain\_id}.
`token_address`STRINGContract address of the token repaid.
`token_symbol`STRINGSymbol of the token repaid.
`token_decimals`INT64Decimals of the token repaid.
`repayer_address`STRINGAccount that paid (the liquidator on a liquidation).
`user_address`STRINGAccount whose debt fell; the position key across the lending facts.
`shares_raw`BIGNUMERICMovement in the protocol's debt unit, exact integer; summing per position replays the borrow-share balance.
`shares`BIGNUMERICshares\_raw decimal-corrected.
`amount_raw`BIGNUMERICEvent-time amount in the token's stored unit, exact integer.
`amount`BIGNUMERICamount\_raw decimal-corrected into whole tokens. \*/}
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One day, one app** `amount` is whole tokens and `amount_raw` the integer the contract emitted. `user_address` is whose debt fell. ```sql theme={null} select events.block_timestamp, events.token_symbol, events.amount, events.user_address from `facts_lending_markets.repayments` as events where events.block_timestamp >= timestamp('2026-09-01') and events.block_timestamp < timestamp('2026-09-02') and events.chain_id = 'ethereum' and events.app_id = 'aave-v3' limit 100 ``` **Daily repayments per app** Group by `token_symbol` as well as app: `amount` is in each token's own units, so one sum per token is the comparable figure. ```sql theme={null} select date(events.block_timestamp) as day, events.app_id, events.token_symbol, sum(events.amount) as repaid from `facts_lending_markets.repayments` as events where events.block_timestamp >= timestamp('2026-08-01') and events.block_timestamp < timestamp('2026-09-01') and events.chain_id = 'ethereum' group by day, events.app_id, events.token_symbol order by day, repaid desc ``` # Withdrawals Source: https://tokenterminal.com/docs/catalog/lending/withdrawals Every withdrawal from a lending market. One row per withdrawal from a lending market, including the sending side of a receipt-token transfer. `amount` is the tokens taken out, and summing it per `user_address` replays a position. ## Columns
Column Type Description
`block_timestamp`TIMESTAMPTime of the block containing the withdrawal. Partition column.
`block_number`INT64Number of the block containing the withdrawal.
`transaction_hash`STRINGHash of the transaction that emitted the withdrawal event.
`log_index`INT64Position of the withdrawal event in the block.
`unique_id`INT64Row key: fingerprint of chain\_id, block\_number, transaction\_hash, log\_index.
`event_type`STRINGConstant 'withdrawals'; stacking key across the lending facts.
`project_id`STRINGProtocol operating the market, such as aave.
`app_id`STRINGDeployment of the protocol the market belongs to.
`chain_id`STRINGChain the withdrawal happened on.
`lending_market_id`STRINGMarket the withdrawal left; joins `dimensions.lending_markets`.
`lending_market_reserve_id`STRINGReserve within the market; joins `dimensions.lending_market_reserves`.
`lending_market_contract_address`STRINGContract the market lives on; not a key.
`receipt_token_address`STRINGReceipt token whose balance moved (the aToken for Aave); null where positions are not tokenised.
`token_id`STRINGToken withdrawn: \{token\_address}-\{chain\_id}.
`token_address`STRINGContract address of the token withdrawn.
`token_symbol`STRINGSymbol of the token withdrawn.
`token_decimals`INT64Decimals of the token withdrawn.
`withdrawer_address`STRINGWhere the value went: the receiver of the withdrawal, or the recipient on a receipt-token transfer.
`user_address`STRINGAccount whose supplied balance fell; the position key across the lending facts.
`shares_raw`BIGNUMERICMovement in the protocol's interest-bearing unit, exact integer; summing per position replays the share balance.
`shares`BIGNUMERICshares\_raw decimal-corrected.
`amount_raw`BIGNUMERICEvent-time amount in the token's stored unit, exact integer.
`amount`BIGNUMERICamount\_raw decimal-corrected into whole tokens. \*/}
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One day, one app** `amount` is whole tokens and `amount_raw` the integer the contract emitted. `user_address` is whose supplied balance fell. ```sql theme={null} select events.block_timestamp, events.token_symbol, events.amount, events.user_address from `facts_lending_markets.withdrawals` as events where events.block_timestamp >= timestamp('2026-09-01') and events.block_timestamp < timestamp('2026-09-02') and events.chain_id = 'ethereum' and events.app_id = 'aave-v3' limit 100 ``` **Daily withdrawals per app** Group by `token_symbol` as well as app: `amount` is in each token's own units, so one sum per token is the comparable figure. ```sql theme={null} select date(events.block_timestamp) as day, events.app_id, events.token_symbol, sum(events.amount) as withdrawn from `facts_lending_markets.withdrawals` as events where events.block_timestamp >= timestamp('2026-08-01') and events.block_timestamp < timestamp('2026-09-01') and events.chain_id = 'ethereum' group by day, events.app_id, events.token_symbol order by day, withdrawn desc ``` # Liquid staking Source: https://tokenterminal.com/docs/catalog/liquid-staking Every liquid staking protocol: staked value, flows and yield, across every chain. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A liquid staking protocol takes a token to stake and issues a token that stays tradable while the stake earns. The vertical covers the protocols and their tokens: staked value, deposits and withdrawals, and yield. # DEX pools Source: https://tokenterminal.com/docs/catalog/markets/dex-pools Pools as a venue: the key, and how the pool list compares to what traded. One row per DEX pool on one chain in `dimensions.dex_pools`, listing every pool ever created. `dex_pool_id` is the pool address joined with the chain, and it is the key every pool figure joins on. ## Coverage One row per app, and a tick marks every app that reports the measure at this grain. It is the same table as the Pool tab of [DEX](/docs/catalog/dex).
App Project Trading volume
`aerodrome-slipstream``aerodrome`✓
`aerodrome-stable``aerodrome`✓
`aerodrome-volatile``aerodrome`✓
`aperture-swap-v1``aperture`✓
`apeswap-dex``apeswap`✓
`blackhole-dex``blackhole`✓
`camelot-dex``camelot`✓
`circle-stablefx``circle`✓
`curve-dex``curve`✓
`dodo-dex``dodo`✓
`equalizer-dex``equalizer`✓
`etherex-dex``etherex`✓
`euler-swap``euler`✓
`fathom-dex``fathom`✓
`honeypop-dex``honeypop`✓
`instadapp-fluid-dex``instadapp`✓
`instadapp-fluid-dex-lite``instadapp`✓
`integral-dex``integral`✓
`maverick-dex``maverick`✓
`meteora-launchpad``meteora`✓
`meteora-liquidity-pools``meteora`✓
`metric-v1``metric`✓
`metric-v2``metric`✓
`okutrade-dex``okutrade`✓
`orca-token-swap-v2``orca`✓
`orca-whirlpools``orca`✓
`pancakeswap-v2``pancakeswap`✓
`pancakeswap-v3``pancakeswap`✓
`pangolin-dex``pangolin`✓
`pharaoh-dex``pharaoh`✓
`projectx``projectx`✓
`pumpfun-amm``pumpfun`✓
`pumpfun-launchpad``pumpfun`✓
`quickswap-v2``quickswap`✓
`quickswap-v3``quickswap`✓
`ramses-dex``ramses`✓
`raydium-clmm``raydium`✓
`raydium-cpmm``raydium`✓
`raydium-launchlab``raydium`✓
`raydium-openbook``raydium`✓
`raydium-stable-swap``raydium`✓
`shadowexchange-concentrated-liquidity``shadowexchange`✓
`shadowexchange-constant-product``shadowexchange`✓
`shadowexchange-dex``shadowexchange`✓
`solidlizard-dex``solidlizard`✓
`spookyswap-dex``spookyswap`✓
`sunswap-v1``sunswap`✓
`sunswap-v2``sunswap`✓
`sunswap-v3``sunswap`✓
`sunswap-v4``sunswap`✓
`sushiswap-dex``sushiswap`✓
`temple``temple`✓
`thena-dex``thena`✓
`thruster-clamm``thruster`✓
`thruster-classic``thruster`✓
`traderjoe-dex``traderjoe`✓
`uniswap-v2``uniswap`✓
`uniswap-v3``uniswap`✓
`uniswap-v4``uniswap`✓
`velodrome-dex``velodrome`✓
`versedex-dex``versedex`✓
`zkswap-dex``zkswap`✓
## Columns
Column Type Description
`dex_pool_id`STRINGIdentifier of the pool: the pool address joined with the chain.
`app_id`STRINGThe app operating the pool.
`chain_id`STRINGChain the pool lives on.
`project_id`STRINGProject the operating app belongs to.
`pool_address`STRINGOnchain address of the pool. Where one contract holds every pool, this is the pool's id inside that contract.
`pool_name`STRINGThe pool's tokens as a name, for example `USDC-WETH`.
`pool_display_name`STRINGPool name with the fee added on, where the pool charges a fixed one.
`fee_tier`BIGNUMERICThe fee the pool charges on every swap, as a decimal fraction, so `0.0005` reads 0.05%. Empty where the venue sets the fee swap by swap.
`created_at`TIMESTAMPTime of the block the pool was created in.
`hooks_address`STRINGAddress of the pool's hooks contract, on venues that attach one. A hooks contract is extra code the venue runs around each swap.
`token_ids`ARRAY\The tokens the pool holds, in pool order, as keys of `dimensions.tokens`.
## Sample queries **Rank pools by volume** The volume table keys on `dex_pool_id`, and the registry turns that key into a readable pair and the fee the pool charges. Filter `chain_id` on both sides so the result stays on one chain. ```sql theme={null} select pools.pool_display_name, pools.app_id, pools.fee_tier, sum(volume.trading_volume) as trading_volume from `metrics_dex_pools.trading_volume_daily` as volume join `dimensions.dex_pools` as pools using (dex_pool_id) where volume.chain_id = 'ethereum' and pools.chain_id = 'ethereum' and volume.timestamp >= timestamp('2026-08-01') and volume.timestamp < timestamp('2026-08-08') group by 1, 2, 3 order by trading_volume desc limit 20 ``` **Registry against traded pools** A pool enters the registry when its factory emits the creation event, so the registry side counts every pool an app has ever created and the traded side counts the ones that saw a swap. ```sql theme={null} with registry as ( select app_id, count(*) as pools_in_registry from `dimensions.dex_pools` where chain_id = 'ethereum' group by app_id ), traded as ( select app_id, count(distinct dex_pool_id) as pools_traded from `metrics_dex_pools.trading_volume_daily` where chain_id = 'ethereum' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') group by app_id ) select app_id, registry.pools_in_registry, traded.pools_traded from registry left join traded using (app_id) order by registry.pools_in_registry desc ``` # Markets Source: https://tokenterminal.com/docs/catalog/markets/index Venue identity for DEX pools, lending markets, order-book markets and perpetual futures markets. A market is one venue where a trade, a loan or a position happens: a Uniswap v3 `USDC-WETH` pool on Ethereum, Aave v3's `Core` market, the `BTC Perpetual` on Hyperliquid, the `HYPE/USDC` book. Each kind has its own table and its own key, and every row names the [app](/docs/catalog/apps/index) running the venue, the chain it settles on and the [project](/docs/catalog/projects/index) behind that app. Market figures roll up from here into the app running the venue, and the app's into its project. Where a measure is a balance rather than a flow, the app figure is the state of its markets on that day. ## Tables [DEX pools](/docs/catalog/markets/dex-pools) holds the swap venues, [Lending markets](/docs/catalog/markets/lending-markets) the deposit pools and the reserves inside them, [Order-book markets](/docs/catalog/markets/order-book-markets) the spot and outcome books, and [Perpetual futures markets](/docs/catalog/markets/perp-markets) the contracts that track a price without expiring. Each page has that table's columns and queries against it. The daily figures at market grain sit with the vertical that works the venue: [DEX](/docs/catalog/dex/index), [Lending](/docs/catalog/lending/index) and [Perpetuals](/docs/catalog/perpetuals/index). # Lending markets Source: https://tokenterminal.com/docs/catalog/markets/lending-markets Lending markets and their reserves: the keys, and how to size them. One row per lending market in `dimensions.lending_markets`, the boundary inside which deposits and debts back each other: the pool on Aave, one collateral and loan pair on Morpho Blue. `lending_market_reserve_id` keys `dimensions.lending_market_reserves`, one row per asset inside a market, and that is the grain a market's figures are summed from. ## Coverage One row per app, and a tick marks every app that reports the measure at this grain. It is the same table as the Market tab of [Lending](/docs/catalog/lending).
App Project TVL Active loans Collateral
`aave-v3``aave`✓✓✓
`aave-v4``aave`✓✓✓
## Columns **Markets** One row per lending market on one chain.
Column Type Description
`lending_market_id`STRINGMarket key, formatted `{lending_market}-{chain_id}`.
`app_id`STRINGApp operating the market, such as `aave-v3` or `morpho-blue`. Joins `dimensions.apps`.
`chain_id`STRINGChain the market lives on.
`project_id`STRINGProject behind the app. Joins `dimensions.projects`.
`lending_market`STRINGThe protocol's own key for the market: the pool contract address on pool lenders, the market hash on Morpho Blue.
`lending_market_contract_address`STRINGThe deployed contract the market runs on. Matches `lending_market` on pool lenders; every Morpho Blue market on a chain shares one singleton contract.
`lending_market_name`STRINGReadable name of the market, such as `Core` or `Morpho Blue: cbBTC/USDC 86%`. A label, not a key.
**Reserves** One row per reserve, one asset inside one market. An Aave pool lists one reserve per underlying token and a Morpho Blue market exactly two, the loan side and the collateral side; where a pool lists the same token twice, the key is the protocol's listing rather than the token.
Column Type Description
`lending_market_reserve_id`STRINGReserve key, formatted `{lending_market}-{lending_market_reserve}-{chain_id}`.
`lending_market_id`STRINGMarket the reserve belongs to. Joins `dimensions.lending_markets`.
`app_id`STRINGApp operating the market. Joins `dimensions.apps`.
`chain_id`STRINGChain the market lives on.
`project_id`STRINGProject behind the app. Joins `dimensions.projects`.
`lending_market`STRINGThe protocol's own key for the market, copied from the market row.
`lending_market_contract_address`STRINGThe deployed contract the market runs on, copied from the market row.
`lending_market_name`STRINGReadable name of the market, copied from the market row.
`lending_market_reserve`STRINGThe protocol's own key for the reserve inside its market: the underlying token address on Aave-style pools, the vToken contract on Venus, `loan` or `collateral` on Morpho Blue, the numeric reserve id on Aave v4.
`lending_market_reserve_name`STRINGReadable name: the market name and the token symbol, such as `Core: WETH`. A label, not a key.
`token_id`STRINGKey of the underlying token in `dimensions.tokens`, formatted `{token_address}-{chain_id}`.
`token_address`STRINGAddress of the underlying token contract.
`token_symbol`STRINGTicker symbol of the underlying token.
## Sample queries **Rank markets by size** TVL is a balance, so read it on a single day. The registry turns `lending_market_id` into the market's name, its app and the chain it lives on. ```sql theme={null} select markets.lending_market_name, markets.app_id, markets.chain_id, market_tvl.tvl from `metrics_lending_markets.tvl_daily` as market_tvl join `dimensions.lending_markets` as markets using (lending_market_id) where market_tvl.timestamp = timestamp('2026-08-01') order by market_tvl.tvl desc limit 20 ``` **What one market holds** The reserve rows sit one level below the market and each names its token, so the registry turns each reserve key into a symbol. Filter the reserve side on `lending_market_id` to stay inside one market. ```sql theme={null} select reserves.token_symbol, reserves.lending_market_reserve, reserve_tvl.tvl from `metrics_lending_market_reserves.tvl_daily` as reserve_tvl join `dimensions.lending_market_reserves` as reserves using (lending_market_reserve_id) where reserve_tvl.timestamp = timestamp('2026-08-01') and reserves.lending_market_id = '0xc13e21b648a5ee794902342038ff3adab66be987-ethereum' order by reserve_tvl.tvl desc ``` # Order-book markets Source: https://tokenterminal.com/docs/catalog/markets/order-book-markets Order books as a venue: the key, and how to rank them. One row per order-book market that has traded in `dimensions.order_book_markets`, a book of buy and sell orders where the token itself changes hands, covering spot books and outcome markets. `order_book_market_id` is the venue's book identifier joined with the chain, and it is the key every order-book figure joins on. ## Coverage One row per app, and a tick marks every app that reports the measure at this grain. It is the same table as the Order book market tab of [Perpetuals](/docs/catalog/perpetuals).
App Project Trading volume Fees Supply-side fees Revenue
`hyperliquid-outcome-markets``hyperliquid`✓✓✓✓
`hyperliquid-spot``hyperliquid`✓✓✓✓
## Columns
Column Type Description
`order_book_market_id`STRINGIdentifier of the market: the venue's book identifier joined with the chain.
`project_id`STRINGProject the operating app belongs to.
`app_id`STRINGThe app running the book. A book runs under this one app, where a perpetual market has an exchange app and an interface app.
`chain_id`STRINGChain the book settles on.
`quote_asset_id`STRINGThe token volume is measured in, keyed like `dimensions.assets`. Every accepted quote token is a dollar stablecoin (`usdc`, `usdh`, `usdt0`, `usde`), so a trade's size times its price is already its dollar value.
`base_symbol`STRINGSymbol of the traded token, as the venue lists it. Several contracts can share one symbol.
`name`STRINGReadable pair name, for example `HYPE/USDC`.
`created_at`TIMESTAMPTime of the first trade seen in the market, which is what puts the row in this table.
## Sample queries **Rank books by volume** The volume table keys on `order_book_market_id`, and the registry turns that key into a readable pair and names the app running the book. Volume is a flow, so a week of it adds up. ```sql theme={null} select markets.name, markets.app_id, markets.chain_id, sum(volume.trading_volume) as trading_volume from `metrics_order_book_markets.trading_volume_daily` as volume join `dimensions.order_book_markets` as markets using (order_book_market_id) where volume.timestamp >= timestamp('2026-08-01') and volume.timestamp < timestamp('2026-08-08') group by 1, 2, 3 order by trading_volume desc limit 20 ``` **Books per app and chain** `created_at` is when the market first traded, so the earliest one per app reads as the date its book opened. ```sql theme={null} select chain_id, app_id, count(*) as markets, min(created_at) as first_traded from `dimensions.order_book_markets` group by 1, 2 order by markets desc ``` # Perpetual futures markets Source: https://tokenterminal.com/docs/catalog/markets/perp-markets Perpetual futures markets as a venue: the key, and how to rank them. One row per perpetual futures market in `dimensions.perp_markets`, a contract that follows an underlying asset's price. `perp_market_id` identifies the market and its settlement chain, and is the key every perpetual figure joins on. ## Coverage One row per app, and a tick marks every app that reports the measure at this grain. It is the same table as the Perp market tab of [Perpetuals](/docs/catalog/perpetuals).
App Project Notional volume Open interest Funding rate Liquidations Active traders Fees Revenue
`dreamcash-perps``hyperliquid`✓✓✓✓✓✓✓
`entropyio-perps``hyperliquid`✓✓✓✓✓✓✓
`felix-perps``hyperliquid`✓✓✓✓✓✓✓
`hyena-perps``hyperliquid`✓✓✓✓✓✓✓
`hyperliquid-perps``hyperliquid`✓✓✓✓✓✓✓
`kinetiq-perps``hyperliquid`✓✓✓✓✓✓✓
`paragon-perps``hyperliquid`✓✓✓✓✓✓✓
`tradexyz-perps``hyperliquid`✓✓✓✓✓✓✓
`ventuals-perps``hyperliquid`✓✓✓✓✓✓✓
`mux-perps``mux`✗✗✗✓✗✗✗
## Columns
Column Type Description
`perp_market_id`STRINGIdentifier of the market: the registered market key joined with the chain on HyperCore; `{pool_address}:{asset_index}-{chain_id}` on MUX.
`project_id`STRINGProject the exchange app belongs to.
`interface_app_id`STRINGThe builder credited for the market. Every fill in the market has this one value, and a market's whole volume lands under one interface app.
`chain_id`STRINGChain the market settles on.
`exchange_app_id`STRINGThe venue that settles the trades. It matches `interface_app_id` on a venue's own markets and differs on a builder-deployed HIP-3 market, where the engine is `hyperliquid-perps` and the interface is the listing builder.
`quote_asset_id`STRINGThe token positions settle in, keyed like `dimensions.assets`. Null on MUX markets, which accept several collateral tokens and price in USD.
`base_reference_asset_id`STRINGThe reference asset whose price the market follows, keyed like `dimensions.reference_assets`. Null where the market's asset has no reference-asset mapping.
`name`STRINGReadable market name, for example `BTC Perpetual`.
`status`STRINGListing status from the market registry, such as `active`. Null for markets identified from executions.
## Sample queries **Rank markets by volume** Notional volume is published twice, once crediting the exchange app that settled the trades and once crediting the interface app they came through. Each table is a complete account of the same trades, so read one of them. ```sql theme={null} select markets.name, markets.exchange_app_id, sum(volume.notional_trading_volume) as notional_volume from `metrics_perp_markets.notional_trading_volume_exchange_daily` as volume join `dimensions.perp_markets` as markets using (perp_market_id) where volume.timestamp >= timestamp('2026-08-01') and volume.timestamp < timestamp('2026-08-08') group by 1, 2 order by notional_volume desc limit 20 ``` **Open interest by settlement token** `quote_asset_id` is the token positions settle in, so grouping by it splits open interest by settlement currency. Open interest is a balance, so read it on a single day. ```sql theme={null} select markets.quote_asset_id, sum(oi.open_interest) as open_interest from `metrics_perp_markets.open_interest_daily` as oi join `dimensions.perp_markets` as markets using (perp_market_id) where oi.timestamp = timestamp('2026-08-01') group by 1 order by open_interest desc ``` # Metric definitions Source: https://tokenterminal.com/docs/catalog/metric-definitions Every measure in the catalog, with its unit and the rules for combining it. Some numbers you can add up and some you cannot. Fees for a week are the seven daily figures added together. Circulating supply for a week is not: add seven days of supply and you get a number seven times too big. Add up a count of distinct addresses and you count anyone who showed up on two days twice. Two tables hold the rules. * `dimensions.metrics`: one row per measure per kind of thing measured, with its unit and its combination rules. * `dimensions.metric_instances`: one row per measure with a specific wording, for one entity. ## Tables **Metric definitions** `dimensions.metrics` holds one row per measure per kind of thing measured, and each row says what unit the measure is in and what to do with it when you combine days or combine things. The rows come from the same authored definitions the daily tables are built from, so the two never disagree. Two columns hold the answer to whether a measure sums. `over_time` says what to do when you turn several days into one figure. `across_dimensions` says what to do when you turn several things, such as several chains or apps, into one figure. `measure_type` names which of four kinds of number you are looking at, and `additivity` sums that up in a word. | `measure_type` | `additivity` | Over time | Across things | | - | - | - | - | | `flow` | `additive` | `sum` | `sum` | | `balance` | `semi_additive` | `last_value` | `sum` | | `ratio` | `non_additive` | `average` or `last_value` | `unsupported` | | `unique_count` | `non_additive` | `last_value` | `unsupported` | A **flow** counts activity over a stretch of time, so it adds up freely in both directions: across days, and across the things being measured. Fees for a project are its apps' fees added together, just as fees for a week are seven days added together. A **balance** is a level: how much of something there was at the end of the day. Balances add up across things but never across days: the supply of USDC is its supply on each chain added together. For a range of days, take the last day's figure. A **ratio** is a rate, such as a yield. A **unique count** counts distinct addresses. Neither adds up, and both read `unsupported` across things because the daily table alone does not hold enough to combine them correctly. Averaging two yields needs to know how much money sits behind each, and the daily table does not carry that. Combining two counts of distinct addresses needs the addresses themselves, not the counts. [Assets ▸ Senders](/docs/catalog/assets/senders) shows how a count of distinct addresses widens.
Column Type Description
`metric_id` `STRING` Identifier of the measure, including the kind of thing it measures.
`entity_id` `STRING` Kind of thing the measure is defined for: an asset, a project, a chain.
`measure` `STRING` Name of the measure.
`column_name` `STRING` Column the measure's value sits in.
`title` `STRING` Display title.
`generic_definition` `STRING` What the measure means, whatever it is measuring.
`ai_hint` `STRING` Guidance for software reading the table on how to use the measure.
`unit` `STRING` Unit of the value: `usd`, `count`, `ratio`, `pct`.
`format` `STRING` How to display the value.
`deprecated` `BOOL` Whether the measure is retired.
`measure_type` `STRING` `flow`, `balance`, `ratio` or `unique_count`.
`additivity` `STRING` `additive`, `semi_additive` or `non_additive`.
`value_grain` `STRING` The level the value is measured at.
`over_time` `STRING` What to do when turning several days into one figure.
`across_dimensions` `STRING` What to do when turning several things into one figure.
`ranking_direction` `STRING` Which end of a ranking counts as better.
`dimensions` `ARRAY` Ways the measure can be broken down.
`formula_expression` `STRING` The formula, where the measure is worked out from others.
`formula_dependencies` `ARRAY` Measures the formula reads.
`formula_summary` `STRING` The formula in words.
`methodology_summary` `STRING` How the measure is worked out.
`source_types` `ARRAY` Kinds of source the measure comes from.
`caveats` `ARRAY` Known limitations of the measure.
`notes` `ARRAY` Additional notes.
`quality_minimum` `FLOAT64` Lowest value considered plausible.
`quality_maximum` `FLOAT64` Highest value considered plausible.
`inserted_at` `TIMESTAMP` When the row was published.
**Metric instances** `dimensions.metric_instances` holds one row where a measure needs a more exact definition for one project or one asset than the general one gives. Revenue means something particular for a lending market and something else for an exchange.
Column Type Description
`metric_id` `STRING` Measure the definition applies to.
`entity_id` `STRING` Kind of thing it applies to: an asset, a project, a chain.
`entity_ref` `STRING` The specific thing, for example `usdc`.
`definition` `STRING` What the measure means for that one thing.
## Sample queries **By entity** **List every measure defined for one kind of thing, with the rules for combining it.** ```sql theme={null} select measure, column_name, title, unit, measure_type, additivity, over_time, across_dimensions from `dimensions.metrics` where entity_id = 'asset' and not deprecated order by measure ``` **Non-summable** **Find the measures that must never be summed.** ```sql theme={null} select entity_id, measure, measure_type, across_dimensions from `dimensions.metrics` where across_dimensions != 'sum' order by entity_id, measure ``` **Definitions and sources** **Read every project measure with its written definition, its combination rules and the kinds of source behind it.** `generic_definition` is the wording published for the measure, and `source_types` names what the number is built from, so a reader can tell an onchain measure from one built on something else without leaving the table. Together with `additivity`, `over_time` and `across_dimensions` this is the whole contract for a measure in one row. ```sql theme={null} select metric_id, title, unit, additivity, over_time, across_dimensions, source_types, generic_definition from `dimensions.metrics` where entity_id = 'project' and not deprecated order by metric_id ``` **Specific definition** **Read the specific definition of a measure, falling back to the general one.** ```sql theme={null} select metrics.metric_id, metrics.title, coalesce(instances.definition, metrics.generic_definition) as definition from `dimensions.metrics` as metrics left join `dimensions.metric_instances` as instances on instances.metric_id = metrics.metric_id and instances.entity_ref = 'usdc' where metrics.entity_id = 'asset' order by metrics.metric_id ``` # Perpetuals Source: https://tokenterminal.com/docs/catalog/perpetuals/index Every perpetual and order-book market: trades, open interest, funding and liquidations, across every venue. Trades, open interest, funding, liquidations and fees for every perpetual and order-book market Token Terminal tracks, from the project down to the individual market and the token it settles in. ## Coverage A tab per grain, then the events and the chains. Each tab says what one row is, and a tick marks every app that reports it. **Project** A project is the business behind the venue, such as `hyperliquid`. One row per project per day, every app and chain together.
App Project Exchange notional volume Interface notional volume Trading volume Fees Supply-side fees Revenue
`dreamcash-perps``hyperliquid`✓✓✓✓✓✓
`entropyio-perps``hyperliquid`✓✓✓✓✓✓
`felix-perps``hyperliquid`✓✓✓✓✓✓
`hyena-perps``hyperliquid`✓✓✓✓✓✓
`hyperliquid-outcome-markets``hyperliquid`✓✓✓✓✓✓
`hyperliquid-perps``hyperliquid`✓✓✓✓✓✓
`hyperliquid-spot``hyperliquid`✓✓✓✓✓✓
`kinetiq-perps``hyperliquid`✓✓✓✓✓✓
`paragon-perps``hyperliquid`✓✓✓✓✓✓
`tradexyz-perps``hyperliquid`✓✓✓✓✓✓
`ventuals-perps``hyperliquid`✓✓✓✓✓✓
**App** An app is one deployed venue or interface, such as `hyperliquid-perps`. One row per app per day, across every chain it runs on.
App Project Interface notional volume Trading volume Fees Supply-side fees Revenue
`dreamcash-perps``hyperliquid`✓✗✗✗✗
`entropyio-perps``hyperliquid`✓✗✗✗✗
`felix-perps``hyperliquid`✓✗✗✗✗
`hyena-perps``hyperliquid`✓✗✗✗✗
`hyperliquid-outcome-markets``hyperliquid`✗✓✓✓✓
`hyperliquid-perps``hyperliquid`✓✗✓✓✓
`hyperliquid-spot``hyperliquid`✗✓✓✓✓
`kinetiq-perps``hyperliquid`✓✗✗✗✗
`paragon-perps``hyperliquid`✓✗✗✗✗
`tradexyz-perps``hyperliquid`✓✗✗✗✗
`ventuals-perps``hyperliquid`✓✗✗✗✗
**Perp market** A perpetual market is a contract that tracks a price and never expires, such as Hyperliquid's `BTC Perpetual`. One row per market per day.
App Project Notional volume Open interest Funding rate Liquidations Active traders Fees Revenue
`dreamcash-perps``hyperliquid`✓✓✓✓✓✓✓
`entropyio-perps``hyperliquid`✓✓✓✓✓✓✓
`felix-perps``hyperliquid`✓✓✓✓✓✓✓
`hyena-perps``hyperliquid`✓✓✓✓✓✓✓
`hyperliquid-perps``hyperliquid`✓✓✓✓✓✓✓
`kinetiq-perps``hyperliquid`✓✓✓✓✓✓✓
`paragon-perps``hyperliquid`✓✓✓✓✓✓✓
`tradexyz-perps``hyperliquid`✓✓✓✓✓✓✓
`ventuals-perps``hyperliquid`✓✓✓✓✓✓✓
`mux-perps``mux`✗✗✗✓✗✗✗
**Perp market token** A perpetual market token is one market paired with the token its positions settle in, such as `BTC Perpetual` settled in `USDC`. One row per market and settlement token per day.
App Project Notional volume Fees Supply-side fees Revenue
`dreamcash-perps``hyperliquid`✓✓✓✓
`entropyio-perps``hyperliquid`✓✓✓✓
`felix-perps``hyperliquid`✓✓✓✓
`hyena-perps``hyperliquid`✓✓✓✓
`hyperliquid-perps``hyperliquid`✓✓✓✓
`kinetiq-perps``hyperliquid`✓✓✓✓
`paragon-perps``hyperliquid`✓✓✓✓
`tradexyz-perps``hyperliquid`✓✓✓✓
`ventuals-perps``hyperliquid`✓✓✓✓
**Order book market** An order-book market is a cash market where the token itself changes hands through a book of resting orders, such as Hyperliquid's `HYPE/USDC` spot book. One row per market per day.
App Project Trading volume Fees Supply-side fees Revenue
`hyperliquid-outcome-markets``hyperliquid`✓✓✓✓
`hyperliquid-spot``hyperliquid`✓✓✓✓
**Order book market token** An order-book market token is one market paired with the token it quotes in, such as `HYPE/USDC` quoted in `USDC`. One row per market and quote token per day.
App Project Trading volume Fees Supply-side fees Revenue
`hyperliquid-outcome-markets``hyperliquid`✓✓✓✓
`hyperliquid-spot``hyperliquid`✓✓✓✓
**Events** One row per trade or liquidation fill, at the moment it happened onchain. Sizes are in units of the underlying asset; execution prices are in the HyperCore settlement token or in USD on MUX.
App Project Perpetual trades Liquidations Order book trades
`dreamcash-perps``hyperliquid`✓✓✗
`entropyio-perps``hyperliquid`✓✓✗
`felix-perps``hyperliquid`✓✓✗
`hyena-perps``hyperliquid`✓✓✗
`hyperliquid-outcome-markets``hyperliquid`✗✗✓
`hyperliquid-perps``hyperliquid`✓✓✗
`hyperliquid-spot``hyperliquid`✗✗✓
`kinetiq-perps``hyperliquid`✓✓✗
`paragon-perps``hyperliquid`✓✓✗
`tradexyz-perps``hyperliquid`✓✓✗
`ventuals-perps``hyperliquid`✓✓✗
`mux-perps``mux`✓✓✗
**Chains** Every chain the section covers.
Chain Apps
`arbitrum``mux-perps`
`avalanche``mux-perps`
`bsc``mux-perps`
`fantom``mux-perps`
`hypercore``dreamcash-perps`, `entropyio-perps`, `felix-perps`, `hyena-perps`, `hyperliquid-outcome-markets`, `hyperliquid-perps`, `hyperliquid-spot`, `kinetiq-perps`, `paragon-perps`, `tradexyz-perps`, `ventuals-perps`
`optimism``mux-perps`
## Tables [Metrics](/docs/catalog/perpetuals/metrics) holds the daily table schemas at each grain and example queries. [Registry](/docs/catalog/perpetuals/registry) holds the identity tables for both market kinds. Each event has its own page and its own table: [Trades](/docs/catalog/perpetuals/trades) and [Liquidations](/docs/catalog/perpetuals/liquidations). # Liquidations Source: https://tokenterminal.com/docs/catalog/perpetuals/liquidations Individual perpetual market liquidations. One row per liquidation fill on a perpetual market, keeping the leg of the party whose position was force-closed. `trade_amount` is the size closed on that fill, and `price` is what it filled at. ## Columns
Column Type Description
`block_timestamp` `TIMESTAMP` Time of the block containing the liquidation fill. Partition column.
`block_number` `INT64` Number of the block containing the liquidation fill.
`transaction_hash` `STRING` Hash of the transaction that emitted the forced fill. Shared by every fill of the same liquidation.
`trade_id` `INT64` Forced-fill identifier on HyperCore; fingerprint of chain, transaction hash and log index on MUX. Part of the row key with `block_timestamp`, `perp_market_id`, `liquidated_user_address` and `crossed`.
`perp_market_id` `STRING` Market the position was liquidated in, keyed like [`dimensions.perp_markets`](/docs/catalog/perpetuals/registry).
`interface_app_id` `STRING` The builder credited for the market, read from the registry.
`exchange_app_id` `STRING` The venue that force-closed the position. The same liquidation is credited under both app columns, so group by one of them for a total.
`token_id` `STRING` The market's settlement token, keyed like [`dimensions.tokens`](/docs/catalog/tokens/registry). Null on MUX markets, which accept several collateral tokens.
`chain_id` `STRING` Chain the liquidation happened on.
`project_id` `STRING` Project the exchange app belongs to.
`liquidated_user_address` `STRING` Account whose position was force-closed. Part of the row key, and a position closed in pieces spans one row per fill under this address.
`side` `STRING` The position that was force-closed: `A` for a long, `B` for a short.
`crossed` `BOOL` True on a HyperCore taker leg or a MUX pool liquidation; false on a HyperCore maker leg.
`price` `BIGNUMERIC` Execution price in the settlement token on HyperCore and in USD on MUX.
`trade_amount` `BIGNUMERIC` Size force-closed on this fill, in units of the underlying asset. Times `price` it is the liquidated notional in the HyperCore settlement token or in USD on MUX.
`mark_price` `BIGNUMERIC` Mark price the liquidation was triggered at. Null on MUX executions.
`method` `STRING` How the position was closed, as the venue labels its liquidation method. `liquidation` on MUX.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One market, one day** A position closed in pieces spans one row per fill, so `liquidated_user_address` repeats down the result for a single force-close. ```sql theme={null} select liquidations.block_timestamp, liquidations.trade_id, liquidations.liquidated_user_address, liquidations.side, liquidations.price, liquidations.trade_amount, liquidations.mark_price, liquidations.method from `facts_perp_markets.liquidations` as liquidations where liquidations.perp_market_id = 'hlbtc-hypercore' and liquidations.chain_id = 'hypercore' and liquidations.block_timestamp >= timestamp('2026-08-01') and liquidations.block_timestamp < timestamp('2026-08-02') order by liquidations.block_timestamp limit 100 ``` **Long vs short liquidations** `side` is the position that was closed, so summing `trade_amount * price` under each value separates the two. MUX execution prices are in USD, and the result matches the daily tables on [Metrics](/docs/catalog/perpetuals/metrics). ```sql theme={null} select date(liquidations.block_timestamp) as day, sum(if(liquidations.side = 'A', liquidations.trade_amount * liquidations.price, 0)) as liquidation_volume_long, sum(if(liquidations.side = 'B', liquidations.trade_amount * liquidations.price, 0)) as liquidation_volume_short from `facts_perp_markets.liquidations` as liquidations where liquidations.exchange_app_id = 'mux-perps' and liquidations.chain_id = 'arbitrum' and liquidations.block_timestamp >= timestamp('2026-08-01') and liquidations.block_timestamp < timestamp('2026-08-08') group by day order by day ``` **Most liquidated accounts** `liquidated_user_address` is the account force-closed, and grouping on it adds every fill of every position it lost in the window. ```sql theme={null} select liquidations.liquidated_user_address, count(*) as fills, sum(liquidations.trade_amount * liquidations.price) as liquidated_notional from `facts_perp_markets.liquidations` as liquidations where liquidations.chain_id = 'hypercore' and liquidations.block_timestamp >= timestamp('2026-08-01') and liquidations.block_timestamp < timestamp('2026-08-08') group by liquidations.liquidated_user_address order by liquidated_notional desc limit 25 ``` # Metrics Source: https://tokenterminal.com/docs/catalog/perpetuals/metrics Daily perpetual and order-book figures per project, app, market and token. Notional volume, open interest, funding, liquidations, trading volume, fees and revenue, in USD. One row per thing per day, at eight grains: project, project and chain, app, app and chain, and each market kind with its token grain. ## Tables > [!NOTE] > > Daily perpetual and order-book fees, revenue and volume cover closed UTC days and follow the availability cutoff of each market’s chain. A tab per grain. [Coverage](/docs/catalog/perpetuals) shows which apps report which measure. **Project** One row per project per day. Notional volume comes in two lenses, exchange and interface; read one of them.
Table Value column What it holds
`metrics_projects.notional_trading_volume_exchange_daily``notional_trading_volume`Notional value of perpetual futures traded, attributed to the project whose matching engine settled the trade.
`metrics_projects.notional_trading_volume_interface_daily``notional_trading_volume`Notional value of perpetual futures traded, attributed to the project whose interface the trade was placed through.
`metrics_projects.trading_volume_daily``trading_volume`Total value of trades executed.
`metrics_projects.fees_daily``fees`Total fees paid by users.
`metrics_projects.fees_supply_side_daily``fees_supply_side`Fees paid out to the supply side.
`metrics_projects.revenue_daily``revenue`Fees retained by the protocol.
**Project × chain** One row per project and chain per day.
Table Value column What it holds
`metrics_projects_by_chain.notional_trading_volume_exchange_daily``notional_trading_volume`Notional value of perpetual futures traded, attributed to the project whose matching engine settled the trade.
`metrics_projects_by_chain.notional_trading_volume_interface_daily``notional_trading_volume`Notional value of perpetual futures traded, attributed to the project whose interface the trade was placed through.
`metrics_projects_by_chain.trading_volume_daily``trading_volume`Total value of trades executed.
`metrics_projects_by_chain.fees_daily``fees`Total fees paid by users.
`metrics_projects_by_chain.fees_supply_side_daily``fees_supply_side`Fees paid out to the supply side.
`metrics_projects_by_chain.revenue_daily``revenue`Fees retained by the protocol.
**App** One row per app per day. The exchange lens credits the venue whose matching engine settled the trade and the interface lens the app the trade was placed through.
Table Value column What it holds
`metrics_apps.notional_trading_volume_exchange_daily``notional_trading_volume`Notional value of perpetual futures traded, attributed to the app whose matching engine settled the trade.
`metrics_apps.notional_trading_volume_interface_daily``notional_trading_volume`Notional value of perpetual futures traded, attributed to the app whose interface the trade was placed through.
`metrics_apps.trading_volume_daily``trading_volume`Value of trades executed by the app, measured on the quote leg at execution price.
`metrics_apps.fees_daily``fees`Fees paid by users of the app across every chain it runs on.
`metrics_apps.fees_supply_side_daily``fees_supply_side`Fees the app passed through to builders and, on HIP-3 markets, to market deployers.
`metrics_apps.revenue_daily``revenue`Fees the app retained across every chain it runs on.
**App × chain** One row per app and chain per day.
Table Value column What it holds
`metrics_apps_by_chain.notional_trading_volume_exchange_daily``notional_trading_volume`Notional value of perpetual futures traded, attributed to the app whose matching engine settled the trade.
`metrics_apps_by_chain.notional_trading_volume_interface_daily``notional_trading_volume`Notional value of perpetual futures traded, attributed to the app whose interface the trade was placed through.
`metrics_apps_by_chain.trading_volume_daily``trading_volume`Value of trades executed by the app, measured on the quote leg at execution price.
`metrics_apps_by_chain.fees_daily``fees`Fees paid by users of the app across every chain it runs on.
`metrics_apps_by_chain.fees_supply_side_daily``fees_supply_side`Fees the app passed through to builders and, on HIP-3 markets, to market deployers.
`metrics_apps_by_chain.revenue_daily``revenue`Fees the app retained across every chain it runs on.
**Perp market** One row per perpetual market per day. The money tables also have `chain_id`, `project_id` and `app_id`; the position and trader tables are keyed on the market alone.
Table Value column What it holds
`metrics_perp_markets.price_daily``price`Mark price of the perpetual futures market.
`metrics_perp_markets.notional_trading_volume_exchange_daily``notional_trading_volume`Notional value traded in the perpetual futures market, attributed to the app whose matching engine settled the trade.
`metrics_perp_markets.notional_trading_volume_interface_daily``notional_trading_volume`Notional value traded in the perpetual futures market, attributed to the app whose interface the trade was placed through.
`metrics_perp_markets.trade_count_daily``trade_count`Number of trades executed in the perpetual futures market.
`metrics_perp_markets.daily_active_traders_daily``daily_active_traders`Distinct traders active in the perpetual futures market.
`metrics_perp_markets.open_interest_daily``open_interest`Notional value of open positions in the perpetual futures market.
`metrics_perp_markets.open_interest_long_daily``open_interest_long`Notional value of open long positions in the perpetual futures market.
`metrics_perp_markets.open_interest_short_daily``open_interest_short`Notional value of open short positions in the perpetual futures market.
`metrics_perp_markets.volume_to_open_interest_daily``volume_to_open_interest`Notional trading volume divided by open interest.
`metrics_perp_markets.daily_active_traders_long_daily``daily_active_traders_long`Distinct traders with long positions in the perpetual futures market.
`metrics_perp_markets.daily_active_traders_short_daily``daily_active_traders_short`Distinct traders with short positions in the perpetual futures market.
`metrics_perp_markets.position_size_average_long_daily``position_size_average_long`Average notional size of long positions in the perpetual futures market.
`metrics_perp_markets.position_size_average_short_daily``position_size_average_short`Average notional size of short positions in the perpetual futures market.
`metrics_perp_markets.position_size_median_long_daily``position_size_median_long`Median notional size of long positions in the perpetual futures market.
`metrics_perp_markets.position_size_median_short_daily``position_size_median_short`Median notional size of short positions in the perpetual futures market.
`metrics_perp_markets.trader_share_long_top10_daily``trader_share_long_top10`Share of long open interest held by the ten largest long traders.
`metrics_perp_markets.trader_share_short_top10_daily``trader_share_short_top10`Share of short open interest held by the ten largest short traders.
`metrics_perp_markets.funding_rate_daily``funding_rate`Daily funding rate paid between long and short positions in the perpetual futures market.
`metrics_perp_markets.liquidation_volume_long_daily``liquidation_volume_long`Notional value of long positions force-closed in the perpetual futures market.
`metrics_perp_markets.liquidation_volume_short_daily``liquidation_volume_short`Notional value of short positions force-closed in the perpetual futures market.
`metrics_perp_markets.fees_daily``fees`Fees paid by traders on the perpetual market.
`metrics_perp_markets.revenue_daily``revenue`Fees retained by the protocol on the perpetual market, net of the builder tip and HIP-3 deployer cut.
`metrics_perp_markets.fees_supply_side_daily``fees_supply_side`Fees passed through on the perpetual market, being the builder-code tip plus the HIP-3 deployer's cut.
**Perp market token** One row per perpetual market and settlement token per day. Amounts become dollars here, and `fees` equals `revenue` plus `fees_supply_side` for the same market, token and day.
Table Value column What it holds
`metrics_perp_markets_by_token.notional_trading_volume_daily``notional_trading_volume`Notional value traded in the perpetual futures market, price times trade amount over crossed (taker) legs.
`metrics_perp_markets_by_token.notional_trading_volume_exchange_daily``notional_trading_volume`Notional value traded in the perpetual futures market, attributed to the app whose matching engine settled the trade.
`metrics_perp_markets_by_token.notional_trading_volume_interface_daily``notional_trading_volume`Notional value traded in the perpetual futures market, attributed to the app whose interface the trade was placed through.
`metrics_perp_markets_by_token.fees_daily``fees`Fees paid by traders on the perpetual market.
`metrics_perp_markets_by_token.revenue_daily``revenue`Fees retained by the protocol on the perpetual market, net of the builder tip and HIP-3 deployer cut.
`metrics_perp_markets_by_token.fees_supply_side_daily``fees_supply_side`Fees passed through on the perpetual market, being the builder-code tip plus the HIP-3 deployer's cut.
**Order book market** One row per order-book market per day. Every table also has `chain_id`, `project_id` and `app_id`.
Table Value column What it holds
`metrics_order_book_markets.trading_volume_daily``trading_volume`Value of trades executed in the order book market, measured on the quote leg at execution price.
`metrics_order_book_markets.fees_daily``fees`Fees paid by traders on the order-book market.
`metrics_order_book_markets.revenue_daily``revenue`Fees retained by the protocol on the order-book market, net of the builder tip.
`metrics_order_book_markets.fees_supply_side_daily``fees_supply_side`Fees passed through on the order-book market, being builder-code tips.
**Order book market token** One row per order-book market and quote token per day. Amounts become dollars here, and `fees` equals `revenue` plus `fees_supply_side` for the same market, token and day.
Table Value column What it holds
`metrics_order_book_markets_by_token.trading_volume_daily``trading_volume`Value of trades executed in the order book market, measured on the quote leg at execution price.
`metrics_order_book_markets_by_token.fees_daily``fees`Fees paid by traders on the order-book market.
`metrics_order_book_markets_by_token.revenue_daily``revenue`Fees retained by the protocol on the order-book market, net of the builder tip.
`metrics_order_book_markets_by_token.fees_supply_side_daily``fees_supply_side`Fees passed through on the order-book market, being builder-code tips.
## Sample queries **Apps by volume** The same trades also sit in `metrics_apps.notional_trading_volume_exchange_daily` credited to the matching venue, and summing both lenses counts every trade twice. ```sql theme={null} select app_id, sum(notional_trading_volume) as volume from `metrics_apps.notional_trading_volume_interface_daily` where timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') group by app_id order by volume desc ``` **Project volume by chain** `chain_id` on a per-chain table is the chain the market settled on, and one project's chain rows add back to its `metrics_projects` row for the same day. ```sql theme={null} select chain_id, sum(notional_trading_volume) as volume from `metrics_projects_by_chain.notional_trading_volume_interface_daily` where project_id = 'hyperliquid' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') group by chain_id order by volume desc ``` **One market's series** Each measure is its own table, so a row with all three is a join on `perp_market_id` and `timestamp`. Join with `full join`: a market has open interest on a day nothing traded. ```sql theme={null} with price as ( select timestamp, price from `metrics_perp_markets.price_daily` where perp_market_id = 'hlbtc-hypercore' and timestamp >= timestamp('2026-06-01') ), volume as ( select timestamp, notional_trading_volume from `metrics_perp_markets.notional_trading_volume_exchange_daily` where perp_market_id = 'hlbtc-hypercore' and timestamp >= timestamp('2026-06-01') ), open_interest as ( select timestamp, open_interest from `metrics_perp_markets.open_interest_daily` where perp_market_id = 'hlbtc-hypercore' and timestamp >= timestamp('2026-06-01') ) select timestamp, price.price, volume.notional_trading_volume, open_interest.open_interest from price full join volume using (timestamp) full join open_interest using (timestamp) order by timestamp ``` **Pool liquidations** Long and short liquidation measures are separate USD tables. Join each to the registry on `perp_market_id` to select the venue and settlement chain. ```sql theme={null} with liquidations as ( select timestamp, perp_market_id, 'long' as side, liquidation_volume_long as value from `metrics_perp_markets.liquidation_volume_long_daily` where timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') union all select timestamp, perp_market_id, 'short' as side, liquidation_volume_short as value from `metrics_perp_markets.liquidation_volume_short_daily` where timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') ) select liquidations.timestamp, liquidations.side, sum(liquidations.value) as liquidated_notional_usd from liquidations join `dimensions.perp_markets` as markets using (perp_market_id) where markets.exchange_app_id = 'mux-perps' and markets.chain_id = 'arbitrum' group by liquidations.timestamp, liquidations.side order by liquidations.timestamp, liquidations.side ``` **Order books by volume** `order_book_market_id` joins the registry for the pair name, and `trading_volume` counts one side of each match. ```sql theme={null} select daily.order_book_market_id, markets.name, daily.app_id, daily.trading_volume from `metrics_order_book_markets.trading_volume_daily` as daily join `dimensions.order_book_markets` as markets using (order_book_market_id) where daily.timestamp = timestamp('2026-08-01') order by daily.trading_volume desc limit 25 ``` **Sector total** Filter on `primary_market_sector`, the sector the Explorer lists the project under, so the total matches the Explorer and counts every project once. ```sql theme={null} select daily.timestamp, sum(daily.notional_trading_volume) as sector_volume from `metrics_perp_markets.notional_trading_volume_exchange_daily` as daily join `dimensions.projects` as projects on projects.project_id = daily.project_id where projects.primary_market_sector = 'derivatives' and daily.timestamp >= timestamp('2026-08-01') group by daily.timestamp order by daily.timestamp ``` # Registry Source: https://tokenterminal.com/docs/catalog/perpetuals/registry Market identity for both market kinds: what they track, what they settle in, and which apps get credit. The identity tables behind every perpetual and order-book figure. Every fact and metric joins to one of them, and [Coverage](/docs/catalog/perpetuals) introduces each grain. ## Tables **Projects** One row per project in the catalog.
Column Type Description
`project_id`STRINGThe project, such as `aave`.
`slug`STRINGThe project's key in Token Terminal page URLs. It differs from `project_id` where the page URL is hyphenated (`redstone-chain` for `redstonechain`).
`url`STRINGThe project's page on the Token Terminal Explorer.
`name`STRINGDisplay name.
`symbol`STRINGTicker of the project's token, where it has one.
`logo`STRINGPublic URL of the project logo, a PNG. Its `?logo_hash=` suffix changes whenever the image does. Null for a project whose image was never uploaded.
`description`STRUCTThe project copy: `what` the project is, `who` it serves and `how` it works.
`links`ARRAY\The project's links as `type` and `url` pairs (website, x, docs, github). `type` is the label as written, so `twitter` and `x` both occur.
`market_sectors`ARRAY\Every market sector the project belongs to, as tag ids, primary first. Unnesting it yields one row per sector.
`primary_market_sector`STRINGThe market sector the project is listed under: the first element of `market_sectors`. One value per row.
`listing_date`TIMESTAMPWhen the project was listed on Token Terminal.
`coingecko_id`STRINGThe project token's CoinGecko id.
`coinmarketcap_id`STRINGThe project token's CoinMarketCap id.
**Apps** One row per app in the catalog.
Column Type Description
`app_id`STRINGThe app, such as `aave-v3`.
`project_id`STRINGThe project operating it.
`name`STRINGDisplay name.
`market_sectors`ARRAY\Every sector the app is tagged with.
`primary_market_sector`STRINGThe first of those, for grouping.
`created_at`TIMESTAMPWhen the app was added.
**Perp markets** One row per perpetual futures market. Each market credits two apps, the venue that settles its trades and the interface it is listed under.
Column Type Description
`perp_market_id` `STRING` Identifier of the market: the registered market key joined with the chain on HyperCore; `{pool_address}:{asset_index}-{chain_id}` on MUX.
`project_id` `STRING` Project the exchange app belongs to.
`interface_app_id` `STRING` The builder credited for the market. Every fill in the market has this one value, and a market's whole volume lands under one interface app.
`chain_id` `STRING` Chain the market settles on.
`exchange_app_id` `STRING` The venue that settles the trades. It matches `interface_app_id` on a venue's own markets and differs on a builder-deployed HIP-3 market, where the engine is `hyperliquid-perps` and the interface is the listing builder.
`quote_asset_id` `STRING` The token positions settle in, keyed like `dimensions.assets`. Null on MUX markets, which accept several collateral tokens and price in USD.
`base_reference_asset_id` `STRING` The reference asset whose price the market follows, keyed like `dimensions.reference_assets`. Null where the market's asset has no reference-asset mapping.
`name` `STRING` Readable market name, for example `BTC Perpetual`.
`status` `STRING` Listing status from the market registry, such as `active`. Null for markets identified from executions.
**Order book markets** One row per order-book market that has traded, covering spot books and outcome markets. An order-book market runs under a single app, and has one credit column where a perpetual market has a pair.
Column Type Description
`order_book_market_id` `STRING` Identifier of the market: the venue's book identifier joined with the chain.
`project_id` `STRING` Project the operating app belongs to.
`app_id` `STRING` The app running the book.
`chain_id` `STRING` Chain the book settles on.
`quote_asset_id` `STRING` The token volume is measured in, keyed like `dimensions.assets`. Every accepted quote token is a dollar stablecoin (`usdc`, `usdh`, `usdt0`, `usde`), so a trade's size times its price is already its dollar value.
`base_symbol` `STRING` Symbol of the traded token, as the venue lists it. Several contracts can share one symbol.
`name` `STRING` Readable pair name, for example `HYPE/USDC`.
`created_at` `TIMESTAMP` Time of the first trade seen in the market, which is what puts the row in this table.
## Sample queries **Markets per interface app** `interface_app_id` is the builder a market is listed under, and on a venue's own markets it holds the same value as `exchange_app_id`. ```sql theme={null} select interface_app_id, count(*) as markets from `dimensions.perp_markets` group by interface_app_id order by markets desc ``` **Builder-deployed markets** A HIP-3 market is one where the matching engine and the listing builder are different apps. Compare `exchange_app_id` against `interface_app_id`. ```sql theme={null} select perp_market_id, name, exchange_app_id, interface_app_id, base_reference_asset_id from `dimensions.perp_markets` where exchange_app_id != interface_app_id order by interface_app_id, perp_market_id ``` **Order books per app and quote asset** `quote_asset_id` is the token the book prices in, and every accepted one is a dollar stablecoin, so grouping by it splits the books by settlement currency. ```sql theme={null} select app_id, quote_asset_id, count(*) as markets from `dimensions.order_book_markets` group by app_id, quote_asset_id order by markets desc ``` **Pool markets by chain** MUX market identifiers combine the pool address, asset index and settlement chain. A market can accept several collateral tokens, and its reference asset identifies what its price follows. ```sql theme={null} select perp_market_id, chain_id, name, base_reference_asset_id, quote_asset_id from `dimensions.perp_markets` where exchange_app_id = 'mux-perps' order by chain_id, perp_market_id ``` # Trades Source: https://tokenterminal.com/docs/catalog/perpetuals/trades Individual perpetual and order-book trades. One row per leg of a perpetual fill, and one row per order-book fill. `trade_amount` is the size traded on a perpetual leg, and `trade_amount_raw` the same size as a decimal string on an order-book fill. ## Columns **Perpetual** `facts_perp_markets.trades` holds one row per leg, keyed by `block_timestamp`, `perp_market_id`, `trade_id`, `trader_address` and `crossed`. HyperCore fills have maker and taker legs; MUX pool executions have one trader leg.
Column Type Description
`block_timestamp` `TIMESTAMP` Time of the block containing the trade. Partition column.
`block_number` `INT64` Number of the block containing the trade.
`trade_id` `INT64` Fill identifier shared by both HyperCore legs; fingerprint of chain, transaction hash and log index on MUX. Part of the row key with `block_timestamp`, `perp_market_id`, `trader_address` and `crossed`.
`perp_market_id` `STRING` Market the trade executed in, keyed like [`dimensions.perp_markets`](/docs/catalog/perpetuals/registry).
`interface_app_id` `STRING` The builder credited for the market, read from the registry. Every fill in a market has the same value.
`exchange_app_id` `STRING` The venue that executed the trade. The same fill is credited under both app columns, so group by one of them for a total.
`token_id` `STRING` The market's settlement token, keyed like [`dimensions.tokens`](/docs/catalog/tokens/registry). Null on MUX markets, which accept several collateral tokens.
`chain_id` `STRING` Chain the trade executed on.
`project_id` `STRING` Project the exchange app belongs to.
`trader_address` `STRING` Address of the trader on this leg. Part of the row key.
`side` `STRING` Which side this leg is: `B` for the buyer, `A` for the seller.
`crossed` `BOOL` True on a HyperCore taker leg or a MUX pool execution; false on a HyperCore maker leg.
`price` `BIGNUMERIC` Execution price in the settlement token on HyperCore and in USD on MUX.
`fee` `BIGNUMERIC` Fee charged on this leg, in `fee_token`, before sharing. Null on MUX executions, where fees can involve several tokens.
`fee_token` `STRING` Token the fee was charged in. Null on MUX executions.
`builder_fee` `BIGNUMERIC` The front end's share inside that fee. Null on MUX executions.
`deployer_fee` `BIGNUMERIC` The market deployer's share inside that fee. Null on MUX executions.
`trade_amount` `BIGNUMERIC` Size traded on this leg, in units of the underlying asset. Times `price` it is the leg's notional in the HyperCore settlement token or in USD on MUX.
**Order book** `facts_order_book_markets.trades` holds one row per fill, with the maker and the taker on the same row as `maker_*` and `taker_*` columns. Amounts are decimal strings, following the datashare's convention for fact amounts, and `safe_cast(price_raw as bignumeric)` puts one back into arithmetic.
Column Type Description
`block_timestamp` `TIMESTAMP` Time of the block containing the fill. Partition column.
`block_number` `INT64` Number of the block containing the fill.
`unique_id` `INT64` Row key: fingerprint of `order_book_market_id`, `trade_id` and `block_timestamp`.
`trade_id` `INT64` Identifier of the fill within its market and block.
`order_book_market_id` `STRING` Market the trade executed in, keyed like [`dimensions.order_book_markets`](/docs/catalog/perpetuals/registry).
`app_id` `STRING` The app running the book, read from the registry.
`token_id` `STRING` The market's quote token, keyed like [`dimensions.tokens`](/docs/catalog/tokens/registry).
`chain_id` `STRING` Chain the trade executed on.
`project_id` `STRING` Project the operating app belongs to.
`maker_address` `STRING` Address of the maker, whose order was resting on the book. Null on a single-leg match.
`taker_address` `STRING` Address of the taker, who accepted the resting order. Null on a single-leg match.
`maker_side` `STRING` Which way the maker traded: `B` for a buy, `A` for a sell. Null on a single-leg match with a maker side missing.
`taker_side` `STRING` Which way the taker traded: `B` for a buy, `A` for a sell. Null on a single-leg match with a taker side missing.
`match_leg_count` `INT64` How many legs the match wrote: two on an ordinary fill, one on a HIP-4 outcome-market mint or burn, which settles against the venue itself.
`price_raw` `STRING` Price the trade filled at, in the quote token, as a decimal string.
`trade_amount_raw` `STRING` How much was traded, in the base token, as a decimal string. Times `price_raw` it is the fill's value, which [Metrics](/docs/catalog/perpetuals/metrics) turns into dollars on the market-and-token tables.
`maker_fee_raw` `STRING` Fee charged on the maker's side, in `maker_fee_token`, as a decimal string.
`taker_fee_raw` `STRING` Fee charged on the taker's side, in `taker_fee_token`, as a decimal string.
`maker_fee_token` `STRING` Token the maker's fee was charged in.
`taker_fee_token` `STRING` Token the taker's fee was charged in. The taker is charged in the token received, so this is either side of the pair.
`maker_builder_fee_raw` `STRING` The front end's share inside the maker's fee, as a decimal string.
`taker_builder_fee_raw` `STRING` The front end's share inside the taker's fee, as a decimal string.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One market, one day** `trade_amount` is the size in whatever the market tracks and `price` the settlement-token price it filled at; multiply them for the leg's notional value. ```sql theme={null} select trades.block_timestamp, trades.trade_id, trades.trader_address, trades.side, trades.crossed, trades.price, trades.trade_amount, trades.fee from `facts_perp_markets.trades` as trades where trades.perp_market_id = 'hlbtc-hypercore' and trades.chain_id = 'hypercore' and trades.block_timestamp >= timestamp('2026-08-01') and trades.block_timestamp < timestamp('2026-08-02') order by trades.block_timestamp limit 100 ``` **Pool volume by market** MUX executions have one trader leg with `crossed = true`, and `price * trade_amount` is the executed notional in USD. The registry supplies the market name through `perp_market_id`. ```sql theme={null} select trades.perp_market_id, markets.name, sum(trades.price * trades.trade_amount) as notional_volume_usd from `facts_perp_markets.trades` as trades join `dimensions.perp_markets` as markets using (perp_market_id) where trades.exchange_app_id = 'mux-perps' and trades.chain_id = 'arbitrum' and trades.crossed and trades.block_timestamp >= timestamp('2026-08-01') and trades.block_timestamp < timestamp('2026-08-02') group by trades.perp_market_id, markets.name order by notional_volume_usd desc ``` **One order book, one day** `price_raw` and `trade_amount_raw` are decimal strings, and `safe_cast` to `bignumeric` puts them back into arithmetic. ```sql theme={null} select trades.block_timestamp, trades.trade_id, trades.maker_address, trades.taker_address, trades.taker_side, safe_cast(trades.price_raw as bignumeric) as price, safe_cast(trades.trade_amount_raw as bignumeric) as trade_amount from `facts_order_book_markets.trades` as trades where trades.order_book_market_id = '@107-hypercore' and trades.chain_id = 'hypercore' and trades.block_timestamp >= timestamp('2026-08-01') and trades.block_timestamp < timestamp('2026-08-02') order by trades.block_timestamp limit 100 ``` **Order book volume** One row is one fill, and the product of price and size is counted once per trade. `match_leg_count` reads 1 on a mint or burn, where the match has a single leg. ```sql theme={null} select date(trades.block_timestamp) as day, sum(safe_cast(trades.price_raw as bignumeric) * safe_cast(trades.trade_amount_raw as bignumeric)) as trading_volume from `facts_order_book_markets.trades` as trades where trades.order_book_market_id = '@107-hypercore' and trades.chain_id = 'hypercore' and trades.block_timestamp >= timestamp('2026-08-01') and trades.block_timestamp < timestamp('2026-08-08') group by day order by day ``` # Agentic payments Source: https://tokenterminal.com/docs/catalog/popular-datasets/agentic-payments Payments software makes without a person in the loop, by asset. An agentic payment is a transfer made under the x402 standard, which lets software pay for something without a person in the loop. `transfer_count_agentic` counts those payments, and it is part of `transfer_count` for the same asset and day, so the two never add together. Circle Gateway settles its x402 payments in batches that credit each seller with a net amount, so on chains where Gateway runs a batch counts as one payment per seller it credits, at that net value, and the paying addresses are not part of the user counts. ## Coverage Every issuer with agentic transfers, and the chains they happened on. One row per issuer.
Issuer Chains
`agora``polygon`, `solana`
`circle``algorand`, `arc`, `base`, `celo`, `polygon`, `solana`, `xdc`
`jpycoin``polygon`
`phantom``solana`
`ripio``celo`
`stablecoin``base`
`tether``celo`, `polygon`, `solana`
`worldlibertyfinancial``solana`
## Tables **Asset** One row per asset per day. Each measure is its own table in `metrics_assets`, named for its value column plus `_daily`.
Column Type Description
`timestamp`TIMESTAMPMidnight UTC of the day measured.
`asset_id`STRINGIdentifier of the asset, for example `usdc`. Joins `dimensions.assets`.
`transfer_count_agentic_native`FLOAT64Number of agentic (x402) transfers on the day, summed across the asset's natively-issued deployments.
`transfer_count_agentic_bridged`FLOAT64Number of agentic (x402) transfers on the day, summed across the asset's bridged deployments.
`transfer_count_agentic`FLOAT64Number of agentic (x402) transfers on the day, summed across every deployment. A genuine total.
`transfer_volume_agentic_native`FLOAT64Value transferred by agentic (x402) flows on the day, USD, summed across the asset's natively-issued deployments.
`transfer_volume_agentic_bridged`FLOAT64Value transferred by agentic (x402) flows on the day, USD, summed across the asset's bridged deployments.
`transfer_volume_agentic`FLOAT64Value transferred by agentic (x402) flows on the day, USD, summed across every deployment. A genuine total.
`daily_active_users_agentic`INT64Distinct addresses making agentic (x402) payments in the asset on the day, across every deployment.
`weekly_active_users_agentic`INT64Distinct addresses making agentic (x402) payments in the asset over the trailing week, across every deployment.
`monthly_active_users_agentic`INT64Distinct addresses making agentic (x402) payments in the asset over the trailing month, across every deployment.
**Deployment** One row per deployment per day. Each measure is its own table in `metrics_asset_tokens`, named for its value column plus `_daily`.
Column Type Description
`timestamp`TIMESTAMPMidnight UTC of the day measured.
`asset_token_id`STRINGIdentifier of the deployment, formatted `{asset_id}-{token_address}-{chain_id}`. Joins `dimensions.asset_tokens`.
`transfer_count_agentic_native`FLOAT64Number of agentic (x402) transfers on the deployment on the day. Natively-issued deployments only.
`transfer_count_agentic_bridged`FLOAT64Number of agentic (x402) transfers on the deployment on the day. Bridged deployments only.
`transfer_count_agentic`FLOAT64Number of agentic (x402) transfers on the deployment on the day, whichever side it sits on.
`transfer_volume_agentic_native`FLOAT64Value transferred by agentic (x402) flows on the deployment on the day, USD. Natively-issued deployments only.
`transfer_volume_agentic_bridged`FLOAT64Value transferred by agentic (x402) flows on the deployment on the day, USD. Bridged deployments only.
`transfer_volume_agentic`FLOAT64Value transferred by agentic (x402) flows on the deployment on the day, USD, whichever side it sits on.
`daily_active_users_agentic_native`INT64Distinct addresses making agentic (x402) payments in the deployment on the day. Natively-issued deployments only.
`daily_active_users_agentic_bridged`INT64Distinct addresses making agentic (x402) payments in the deployment on the day. Bridged deployments only.
`weekly_active_users_agentic_native`INT64Distinct addresses making agentic (x402) payments in the deployment over the trailing week. Natively-issued deployments only.
`weekly_active_users_agentic_bridged`INT64Distinct addresses making agentic (x402) payments in the deployment over the trailing week. Bridged deployments only.
`monthly_active_users_agentic_native`INT64Distinct addresses making agentic (x402) payments in the deployment over the trailing month. Natively-issued deployments only.
`monthly_active_users_agentic_bridged`INT64Distinct addresses making agentic (x402) payments in the deployment over the trailing month. Bridged deployments only.
## Sample queries **Assets by agentic payments** Each measure is its own table, so this joins three of them on `asset_id` at one `timestamp`. `transfer_count` is the denominator that turns the count into a share of the asset's activity. ```sql theme={null} with agentic as ( select asset_id, transfer_count_agentic from `metrics_assets.transfer_count_agentic_daily` where timestamp = timestamp('2026-08-20') and transfer_count_agentic > 0 ), volume as ( select asset_id, transfer_volume_agentic from `metrics_assets.transfer_volume_agentic_daily` where timestamp = timestamp('2026-08-20') ), total as ( select asset_id, transfer_count from `metrics_assets.transfer_count_daily` where timestamp = timestamp('2026-08-20') ) select assets.name, assets.symbol, agentic.transfer_count_agentic, volume.transfer_volume_agentic, safe_divide(agentic.transfer_count_agentic, total.transfer_count) as agentic_share from agentic left join volume using (asset_id) left join total using (asset_id) join `dimensions.assets` as assets using (asset_id) order by agentic.transfer_count_agentic desc limit 25 ``` **One asset over time** A `full join` on `timestamp` keeps a day with payments but no payer count, and the reverse. Bound `timestamp` on every side: an unbounded side reads its whole table. ```sql theme={null} with payments as ( select timestamp, transfer_count_agentic from `metrics_assets.transfer_count_agentic_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ), payers as ( select timestamp, daily_active_users_agentic from `metrics_assets.daily_active_users_agentic_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ), payers_monthly as ( select timestamp, monthly_active_users_agentic from `metrics_assets.monthly_active_users_agentic_daily` where asset_id = 'usdc' and timestamp >= timestamp('2026-06-01') ) select timestamp, payments.transfer_count_agentic, payers.daily_active_users_agentic, payers_monthly.monthly_active_users_agentic from payments full join payers using (timestamp) full join payers_monthly using (timestamp) order by timestamp ``` **By chain** The deployment tables have `asset_token_id` alone, so the chain comes from `dimensions.asset_tokens`. ```sql theme={null} select daily.timestamp, deployments.chain_id, daily.transfer_count_agentic from `metrics_asset_tokens.transfer_count_agentic_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) where daily.timestamp >= timestamp('2026-08-01') and deployments.asset_id = 'usdc' and daily.transfer_count_agentic > 0 order by daily.timestamp, daily.transfer_count_agentic desc ``` # Fact sheets Source: https://tokenterminal.com/docs/catalog/popular-datasets/fact-sheets What an issuer discloses about a tokenized asset, each value with its evidence, and the security it references. Legal, regulatory and market terms of every tokenized asset, as its issuer discloses them, with the security a tokenized stock or fund references. Every term has a status, and every researched term has evidence: the confidence, the reasoning and the cited passages behind the value. ## Coverage Every issuer with a researched asset, and the chains its assets are deployed on. One row per issuer.
Issuer Chains
`22xfund``ethereum`
`3jane``ethereum`
`a7a5``ethereum`, `tron`
`aave``arbitrum`, `avalanche`, `base`, `ethereum`, `gnosis`, `ink`, `monad`, `plasma`
`abt``ethereum`
`aegis``avalanche`, `bsc`, `ethereum`
`agant``arc`, `base`, `ethereum`, `solana`, `tempo`
`agora``arbitrum`, `avalanche`, `bsc`, `coredao`, `ethereum`, `immutablezkevm`, `katananetwork`, `mantle`, `monad`, `polygon`, `solana`, `sui`
`aktionariat``ethereum`, `optimism`
`allunity``arbitrum`, `arc`, `base`, `ethereum`, `optimism`, `polygon`, `solana`, `stellar`, `tempo`
`alphaledger``solana`
`anchored``arbitrum`, `base`, `ethereum`, `monad`, `robinhoodchain`
`anchoredcoins``bsc`, `ethereum`
`anzen``arbitrum`, `base`, `blast`, `ethereum`
`anzens``cardano`
`apyx``base`, `bsc`, `ethereum`, `solana`
`archax``hedera`, `xdc`
`aryze``bsc`, `ethereum`, `linea`, `polygon`
`asseto``bsc`, `ethereum`
`astera``linea`
`audx``ethereum`, `polygon`
`australiandigitaldollar``arc`, `base`, `ethereum`, `hedera`, `ripple`, `solana`, `stellar`, `xdc`
`auxite``base`
`avantprotocol``avalanche`, `monad`
`backpack``solana`
`bilira``arc`, `avalanche`, `base`, `bsc`, `ethereum`, `plasma`, `polygon`, `solana`, `worldchain`
`binance``bsc`
`bitbond``stellar`
`bitso``arbitrum`, `arc`, `avalanche`, `ethereum`, `polygon`
`blox``arbitrum`, `base`, `solana`
`bnymellon``ethereum`
`bralexyz``base`, `solana`
`braza``ripple`
`bridge``ethereum`, `polygon`, `sui`
`capapp``ethereum`, `katananetwork`, `megaeth`, `tempo`
`centrifuge``arbitrum`, `avalanche`, `base`, `bsc`, `celo`, `ethereum`, `monad`, `optimism`, `plumenetwork`, `solana`, `stellar`
`cfxlabs``solana`
`circle``algorand`, `aptos`, `arbitrum`, `arc`, `avalanche`, `base`, `berachain`, `bobanetwork`, `bsc`, `cardano`, `celo`, `ethereum`, `gnosis`, `hedera`, `hypercore`, `hyperevm`, `injective`, `injectiveevm`, `ink`, `linea`, `monad`, `near`, `optimism`, `plasma`, `polkadotassethub`, `polygon`, `ripple`, `scroll`, `seievm`, `solana`, `sonic`, `stacks`, `starknet`, `stellar`, `sui`, `tempo`, `tron`, `unichain`, `worldchain`, `xdc`, `xlayer`, `zksyncera`
`cod3x``base`
`coinbase``base`
`coinshift``ethereum`
`colbfinance``bsc`
`comtech``xdc`
`cosimo``ethereum`
`creditagricole``ethereum`
`cropto``mantraevm`, `polygon`
`crown``base`, `ethereum`
`ctrlalt``ripple`
`czodiac``bsc`
`defifranc``ethereum`
`deuro``arbitrum`, `base`, `ethereum`, `optimism`, `polygon`
`diamondstandard``ethereum`, `hedera`
`digishare``ethereum`
`dinari``arbitrum`, `avalanche`, `base`, `blast`, `ethereum`, `hypercore`, `hyperevm`
`dtrinity``ethereum`, `fraxtal`, `katananetwork`, `ronin`, `sonic`
`ebisu``ethereum`
`ethena``aptos`, `arbitrum`, `avalanche`, `base`, `berachain`, `blast`, `bsc`, `ethereum`, `fraxtal`, `hypercore`, `hyperevm`, `ink`, `linea`, `manta`, `megaeth`, `monad`, `optimism`, `plasma`, `robinhoodchain`, `scroll`, `solana`, `sui`, `tempo`, `xlayer`, `zksyncera`
`etherfuse``base`, `monad`, `polygon`, `solana`, `stellar`
`falconfinance``bsc`, `ethereum`, `xdc`
`fathom``xdc`
`fd121limited``arbitrum`, `bsc`, `ethereum`, `solana`, `sui`
`fidelity``ethereum`
`figure``solana`, `stellar`
`finest``cardano`
`fireblocks``bsc`, `ethereum`
`fortetechsolutions``avalanche`, `ethereum`
`frankencoin``arbitrum`, `avalanche`, `base`, `ethereum`, `gnosis`, `optimism`, `polygon`, `sonic`
`franklintempleton``aptos`, `arbitrum`, `avalanche`, `base`, `bsc`, `ethereum`, `polygon`, `solana`, `stellar`
`frax``arbitrum`, `bsc`, `ethereum`, `fraxtal`
`fraxstablecoin``aptos`, `arbitrum`, `avalanche`, `base`, `berachain`, `blast`, `bsc`, `ethereum`, `fraxtal`, `ink`, `katananetwork`, `linea`, `optimism`, `plumenetwork`, `polygon`, `scroll`, `seievm`, `solana`, `sonic`, `tempo`, `unichain`, `worldchain`, `zksyncera`
`fxprotocol``ethereum`
`gaib``ethereum`
`galaxydigital``solana`
`gemini``ethereum`
`glodollar``arbitrum`, `base`, `celo`, `ethereum`, `optimism`, `polygon`, `stellar`
`goldfishgold``ethereum`
`groma``base`
`gyroscope``arbitrum`, `avalanche`, `base`, `ethereum`, `gnosis`, `optimism`, `polygon`
`hastra``ethereum`, `solana`
`homecoin``ethereum`
`hylo``solana`
`hyperstable``hypercore`, `hyperevm`
`hyperwave``base`, `ethereum`, `hyperevm`
`indigo``cardano`
`infinifi``ethereum`, `tempo`
`interestprotocol``ethereum`
`inversefinance``arbitrum`, `base`, `bsc`, `ethereum`, `fantom`, `optimism`
`jpmorgan``ethereum`, `solana`
`justoken``ripple`
`kaio``aptos`, `avalanche`, `ethereum`, `hedera`, `near`, `polygon`, `seievm`, `solana`, `xdc`
`kinesis``ethereum`
`kinka``cardano`, `ethereum`
`levelprotocol``ethereum`
`libeara``arbitrum`, `avalanche`, `ethereum`, `solana`
`liquity``arbitrum`, `avalanche`, `base`, `berachain`, `ethereum`, `hyperevm`, `optimism`, `scroll`, `sonic`
`listadao``bsc`
`mainstreet``ethereum`, `sonic`
`makerdao``arbitrum`, `avalanche`, `base`, `bsc`, `cardano`, `ethereum`, `near`, `optimism`, `polygon`, `solana`, `starknet`, `unichain`, `xlayer`
`matrixdock``arbitrum`, `arc`, `bsc`, `ethereum`, `hyperevm`, `polygon`, `solana`, `stellar`, `sui`, `tron`
`mento``celo`
`mentolabs``celo`, `monad`
`mercadobitcoin``ethereum`, `polygon`, `rootstock`
`mesh``stellar`
`metawealth``ethereum`, `solana`
`metronome``base`, `ethereum`, `optimism`, `plasma`
`midas``base`, `bsc`, `ethereum`, `katananetwork`, `monad`, `optimism`, `plasma`, `rootstock`, `starknet`
`mimocapital``ethereum`, `fantom`, `polygon`
`mnee``ethereum`
`monerium``arbitrum`, `base`, `ethereum`, `gnosis`, `linea`, `osmosis`, `polygon`, `scroll`
`moneta``cardano`
`moneyonchain``arbitrum`, `rootstock`
`monolithmarket``ethereum`
`moola``celo`
`mountainprotocol``arbitrum`, `avalanche`, `base`, `celo`, `ethereum`, `optimism`, `polygon`, `zksyncera`
`mudigital``monad`
`multipli``arbitrum`, `base`, `ethereum`, `monad`, `robinhoodchain`, `xlayer`
`mzero``ethereum`, `monad`, `solana`
`nativemarkets``hypercore`, `hyperevm`
`nereusfinance``avalanche`
`nest``arbitrum`, `arc`, `ethereum`, `plasma`, `plumenetwork`, `solana`
`neutrl``ethereum`
`newrails``monad`
`noon``ethereum`, `starknet`, `zksyncera`
`nyala``polygon`
`ondo``aptos`, `arbitrum`, `bsc`, `ethereum`, `mantle`, `polygon`, `ripple`, `seievm`, `solana`, `stellar`, `sui`
`onre``solana`
`openedendigital``arbitrum`, `base`, `bsc`, `ethereum`, `ripple`, `solana`
`openstandard``base`, `ethereum`, `solana`, `tempo`
`opentrade``avalanche`, `ethereum`
`origin``ethereum`
`oro``solana`
`palmusd``ethereum`
`pareto``ethereum`
`paxos``arbitrum`, `cardano`, `ethereum`, `ink`, `polygon`, `robinhoodchain`, `solana`, `stellar`, `xlayer`
`paytrie``arbitrum`, `base`, `ethereum`, `linea`, `polygon`
`perena``solana`
`piku``ethereum`
`pleasinggold``arbitrum`
`prestocks``solana`
`prismafinance``ethereum`
`quantoz``algorand`, `ethereum`, `polygon`, `ripple`
`raac``ethereum`
`raft``ethereum`
`re``avalanche`, `base`, `ethereum`, `tempo`
`realfi``cardano`
`reality``arbitrum`
`redswan``stellar`
`reental``polygon`
`remora``solana`
`republicnote``avalanche`, `solana`
`reserve``base`
`reservoirxyz``arbitrum`, `avalanche`, `base`, `berachain`, `bsc`, `ethereum`, `hyperevm`, `seievm`, `solana`, `sonic`, `tempo`, `unichain`, `worldchain`
`resolv``arbitrum`, `base`, `berachain`, `bsc`, `ethereum`, `hyperevm`, `plasma`
`resupply``ethereum`
`ribdigital``bsc`, `ethereum`, `tron`
`rif``arbitrum`, `rootstock`
`ripio``base`, `bsc`, `ethereum`, `gnosis`, `hypercore`, `polygon`, `worldchain`
`ripplelabs``ethereum`, `ripple`
`robinhood``arbitrum`, `robinhoodchain`
`saturn``bsc`, `ethereum`, `monad`
`sbishinseitrust``ethereum`
`schumanfinancial``avalanche`, `ethereum`, `plasma`, `polygon`, `ripple`, `solana`
`scienceblockchain``ethereum`
`securitize``algorand`, `aptos`, `arbitrum`, `avalanche`, `bsc`, `ethereum`, `ink`, `mantle`, `optimism`, `polygon`, `seievm`, `solana`, `sui`, `tempo`, `tron`, `xdc`, `zksyncera`
`shift``solana`
`sivo``ethereum`
`smardex``ethereum`
`societegenerale``ethereum`, `ripple`, `solana`, `stellar`
`sofi``ethereum`, `solana`
`solayer``solana`
`solomonlabs``solana`
`solstice``solana`
`soulpeg``bsc`
`sperax``arbitrum`
`spicevc``ethereum`
`spiko``arbitrum`, `base`, `ethereum`, `polygon`, `solana`, `starknet`, `stellar`
`st0x``base`, `ethereum`, `hyperevm`
`stablecoin``arbitrum`, `avalanche`, `base`, `ethereum`, `optimism`, `polygon`, `solana`, `stellar`, `tempo`
`stablecorp``arc`, `ethereum`, `stellar`
`stablemint``arbitrum`, `base`, `ethereum`
`stableslabs``arbitrum`, `base`, `bsc`, `ethereum`
`stablestock``bsc`
`stablr``ethereum`
`standx``bsc`, `solana`
`stasis``algorand`, `arbitrum`, `ethereum`, `gnosis`, `polygon`, `stellar`, `xdc`
`straitsx``arbitrum`, `avalanche`, `base`, `ethereum`, `hedera`, `polygon`, `ripple`
`strata``ethereum`
`stream``avalanche`, `ethereum`, `plasma`
`streamex``base`
`stusdt``ethereum`, `tron`
`superstate``ethereum`, `solana`
`swarmmarkets``base`, `bsc`, `ethereum`, `hyperevm`, `plasma`, `polygon`
`sygnum``arbitrum`, `zksyncera`
`tangent``ethereum`
`tangible``base`, `ethereum`, `optimism`
`tenbinlabs``ethereum`
`tether``aptos`, `arbitrum`, `avalanche`, `berachain`, `bsc`, `cardano`, `celo`, `ethereum`, `flowevm`, `hypercore`, `hyperevm`, `injective`, `ink`, `linea`, `megaeth`, `monad`, `near`, `optimism`, `plasma`, `polkadotassethub`, `polygon`, `rootstock`, `scroll`, `seievm`, `solana`, `sonic`, `starknet`, `stellar`, `sui`, `tempo`, `ton`, `tron`, `unichain`, `xlayer`, `zksyncera`
`theo``arbitrum`, `base`, `ethereum`, `hypercore`, `hyperevm`
`token``avalanche`, `polygon`
`tokenisedgbp``avalanche`, `base`, `bsc`, `ethereum`, `polygon`, `solana`
`tokeny``avalanche`, `base`
`torifinance``ethereum`
`tradable``zksyncera`
`transfero``algorand`, `arbitrum`, `avalanche`, `base`, `bsc`, `celo`, `ethereum`, `gnosis`, `linea`, `optimism`, `polygon`, `rootstock`, `solana`, `tron`
`tronusdd``bsc`, `ethereum`
`trystable``solana`
`unitedstables``bsc`, `ethereum`, `robinhoodchain`, `tron`
`usdai``arbitrum`, `base`, `ethereum`, `plasma`
`usdkg``ethereum`, `tron`
`usdufinance``ethereum`
`usual``arbitrum`, `ethereum`
`virtue``iota`
`vnx``arbitrum`, `avalanche`, `base`, `celo`, `ethereum`, `fraxtal`, `polygon`, `ripple`, `solana`, `stellar`
`wisdomtree``arbitrum`, `avalanche`, `base`, `ethereum`, `optimism`, `plumenetwork`, `solana`, `stellar`
`worldlibertyfinancial``aptos`, `bsc`, `ethereum`, `mantle`, `monad`, `morph`, `plumenetwork`, `solana`, `tron`, `xlayer`
`wspn``ethereum`, `polygon`, `viction`
`wyoming``arbitrum`, `avalanche`, `base`, `ethereum`, `hedera`, `optimism`, `polygon`, `solana`
`xstocks``arbitrum`, `bsc`, `ethereum`, `hyperevm`, `ink`, `mantle`, `optimism`, `solana`, `ton`, `xlayer`
`xsy``base`
`yamatoprotocol``ethereum`
`yieldfi``arbitrum`, `base`, `ethereum`, `katananetwork`, `optimism`, `plumenetwork`, `sonic`
`yieldoptimizer``base`
`yuzumoney``monad`, `plasma`
`zeconomy``ethereum`, `ripple`
## Tables **Disclosures** One row per asset, in `dimensions.asset_disclosures`. A term whose value depends on the issuing entity or the holder market is an `ARRAY>`, one element per jurisdiction.
ColumnTypeDescription
`asset_id``STRING`The asset, such as `usdc`; joins [`dimensions.assets`](/docs/catalog/assets/registry).
`retrieved_at``TIMESTAMP`When the issuer's documents were read for this row.
`_status``STRING`The status of every term, one companion per term column, including the registry and warehouse facts with no evidence column: `disclosed` when the term has a value, `not_available` when the term applies to the asset's sector and its value is null, and `not_applicable` when the term is out of scope for the asset's sector.
`website``STRING`The issuer page that names this token; naming the instrument is enough, the page need not link its terms.
`claim_type``STRING`What a holder holds. `issuer_sponsored`: a direct claim on or ownership of the issuer's instrument. `synthetic_collateralized`: a contractual exposure backed by dedicated collateral. `synthetic_uncollateralized`: a contractual exposure without it.
`issuance_status``STRING`Whether the issuer still creates the token. `active`, `paused` (issuance suspended, redemption open), `legacy_redemption_only` or `sunset`.
`sector``ARRAY`Sectors of the underlying exposure (`information_technology`, `financials`, `government_debt`, `commodities`), not of the tokenization provider. Tokenized funds and tokenized stocks only; null elsewhere.
`region``ARRAY`Regions of the underlying economic exposure (`north_america`, `europe`, `greater_china`, `global`), not the issuer domicile. Tokenized funds and tokenized stocks only; null elsewhere.
`reference_ratio``FLOAT64`Units of the reference asset one token represents by design (1 for a dollar stablecoin, 1 troy ounce for a gold token). Null when the token tracks a floating NAV.
`reserve_composition``ARRAY`Asset categories in the reserve backing a stablecoin, from the latest attestation (`cash`, `bank_deposits`, `treasury_bills`, `repurchase_agreements`, `money_market_funds`, `commercial_paper`, `corporate_bonds`, `precious_metals`, `crypto_assets`, `secured_loans`, `other`). Stablecoins only; null elsewhere.
`issuer_legal_entity``ARRAY`Legal name of the entity that issues the token to the holders the document governs, distinct from its parent, manager, platform and distributors. One element per issuing entity, keyed by the jurisdiction it issues under, `value` typed `STRING`.
`affiliate_entity``ARRAY`Legal name of a group entity of the issuer that contracts with, or is licensed to serve, holders in one market under that market's own holder document without issuing the token, such as the Singapore affiliate behind a Singapore addendum. Never an issuer: `issuer_legal_entity`, `domicile`, `issuer_lei` and `issuer_cik` hold issuers only. One element per affiliate, keyed by the market whose document names it, `value` typed `STRING`.
`domicile``ARRAY`Incorporation country of the issuing entity, ISO 3166-1 alpha-2. One element per issuing entity, keyed by the jurisdiction it issues under, `value` typed `STRING`.
`governing_law``ARRAY`Country whose law governs the contract between holder and issuer, or the affiliate a market document makes the counterparty, from the governing-law clause of the holder document, ISO 3166-1 alpha-2; the law chosen may differ from the key, terms for US holders governed by Singapore law reading jurisdiction `US` with `value` `SG`. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `STRING`.
`governing_law_subdivision``ARRAY`State, province or canton named in the governing-law clause (Delaware, New York, Zug), ISO 3166-2. Null when the clause names only a country. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `STRING`.
`dispute_resolution_country``ARRAY`Country of the court or arbitration seat named in the dispute-resolution clause of the holder document, ISO 3166-1 alpha-2. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `STRING`.
`regulatory_framework``ARRAY`Regime under which the instrument is issued or offered to the holders the document governs (`us_reg_d`, `us_reg_s`, `us_money_transmitter`, `us_national_trust_bank`, `eu_mica`, `eu_prospectus`, `ch_dlt_act`, `sg_mas`, `unregulated` and the other regimes of the closed list), not the licence of a distributor; every regime attached to that entity's offering keeps the key of the entity it attaches to, so `us_reg_s` on a BVI issuer sits under `VG` and `sg_mas` held by a Singapore affiliate sits under `SG`. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `ARRAY`.
`regulator``ARRAY`Supervisory authority of the issuer, of an affiliate a market's holder document names, or of the instrument, every authority supervising that entity or named by its holder document. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `ARRAY`.
`bankruptcy_remote``BOOL`True when a legal document states that the backing assets sit outside the issuer estate on insolvency (trust, bankruptcy-remote vehicle, statutory segregation).
`account_segregation``BOOL`True when a document states that backing or holder assets are held in accounts segregated from the issuer's operating funds.
`mica_marker``STRING`Classification under MiCA by legal nature and peg, independent of authorization: `emt_by_peg`, `art_by_peg`, `other_crypto_asset` or `out_of_scope_financial_instrument`.
`voting_rights``BOOL`True when token holders can vote or direct the votes of the underlying shares. Tokenized stocks only; null elsewhere.
`dividend_eligibility``BOOL`True when token holders are entitled to dividends or distributions declared on the underlying share. Tokenized stocks only; null elsewhere.
`platform``STRING`Tokenization platform, when distinct from the legal issuer.
`manager``STRING`Investment manager of a tokenized fund. Tokenized funds only; null elsewhere.
`sub_advisor``STRING`Delegated investment adviser of a tokenized fund, when disclosed. Tokenized funds only; null elsewhere.
`custodian``STRING`Institution holding the real-world assets that back the token. Several providers are separated by semicolons.
`crypto_custodian``STRING`Third party holding the keys that control the token contract, mint authority or issuer treasury wallets.
`fund_administrator``STRING`Provider that calculates NAV and keeps the fund books. Tokenized funds only; null elsewhere.
`transfer_agent``STRING`Transfer agent of record for the legal holder register of the security or share class. Tokenized funds and tokenized stocks only; null elsewhere.
`digital_transfer_agent``STRING`Entity that keeps the on-chain holder ledger, when distinct from `transfer_agent`. Tokenized funds and tokenized stocks only; null elsewhere.
`broker``ARRAY`Executing brokers named for the token, traditional or crypto, one element per executing broker. Tokenized funds and tokenized stocks only; null elsewhere.
`auditor``STRING`Firm that audits or attests the backing of the token or, for a native share, the issuer's financial statements.
`attestation_frequency``STRING`Cadence of published reserve attestations or audits: `daily`, `weekly`, `monthly`, `quarterly`, `annual`, `irregular` or `none`. Stablecoins only; null elsewhere.
`security_trustee``STRING`Trustee or security agent holding collateral or a security interest for token holders, typical of notes and certificates. Tokenized funds and tokenized stocks only; null elsewhere.
`storage_location``ARRAY`Countries of the vaults holding the physical commodity, ISO 3166-1 alpha-2. Tokenized commodities only; null elsewhere.
`primary_route``STRING`How a holder enters and exits directly on the issuer side, which the other primary-market columns refer to: `issuer_mint_redeem`, `fund_subscription`, `transfer_agent_conversion`, `issuer_operated_venue` or `none`.
`eligible_investors``ARRAY`Investor classes that may use the primary route (`retail`, `professional`, `accredited`, `qualified_investor`, `qualified_purchaser`, `institutional`), one element per investor class.
`eligible_jurisdictions``ARRAY`Investor residences eligible for the primary route: ISO alpha-2 country codes or the region codes `global`, `eea`, `gcc`. Places carved out of them are in `excluded_jurisdictions`.
`excluded_jurisdictions``ARRAY`Investor residences excluded from the primary route although `eligible_jurisdictions` covers them: ISO alpha-2 country codes, the region codes `eea` and `gcc`, and `sanctioned` for jurisdictions under applicable sanctions. `global` in `eligible_jurisdictions` with `US` here reads as open to everyone outside the United States.
`kyc_required``BOOL`True when the primary route requires KYC.
`right_to_redeem``BOOL`True when the instrument terms give holders a right to exit through the primary route.
`physical_redemption``BOOL`True when holders can redeem a commodity token for physical delivery. Tokenized commodities only; null elsewhere.
`base_assets``ARRAY`Currencies or assets accepted on entry and paid on exit through the primary route, one element per accepted currency or asset: ISO currency codes for fiat, tickers for crypto, a short name for a physical asset, or `underlying shares` for the underlying share delivered in kind.
`min_investment``FLOAT64`Minimum entry through the primary route, in the currency or unit the document states.
`min_redemption``FLOAT64`Minimum exit through the primary route, in the currency or unit the document states.
`subscription_time``STRING`How long entry settles, from a valid funded order to tokens credited: `instant`, `daily` (T+0 or T+1 business day), `weekly` (two to five business days), `monthly`, `quarterly` or `other`. For a vehicle that deals periodically, the wait for the next dealing window is part of the band.
`redemption_time``STRING`How long exit settles, from a valid redemption request to proceeds received: `instant`, `daily` (T+0 or T+1 business day), `weekly` (two to five business days), `monthly`, `quarterly` or `other`. For a vehicle that deals periodically, the wait for the next dealing window is part of the band.
`is_open_ended``BOOL`True when the fund issues and redeems on an ongoing basis rather than as a closed-ended vehicle. Tokenized funds only; null elsewhere.
`lockup_period``FLOAT64`Lockup in months. Tokenized funds only; null elsewhere.
`management_fee``FLOAT64`Annual management fee in basis points. Tokenized funds and tokenized stocks only; null elsewhere.
`storage_fee``FLOAT64`Annual custody or storage fee charged to holders, in basis points. Tokenized commodities only; null elsewhere.
`dividend_handling``STRING`How dividends reach token holders: `distributed_in_cash`, `distributed_in_token`, `reinvested`, `retained_by_issuer`, `none`. Tokenized stocks only; null elsewhere.
`isin``STRING`ISIN of the instrument, from the issuer's own pages or the LEI-to-ISIN register. Tokenized funds and tokenized stocks only; null elsewhere.
`cusip``STRING`CUSIP derived from a US or Canadian ISIN. Tokenized funds and tokenized stocks only; null elsewhere.
`figi``STRING`FIGI of the instrument, from OpenFIGI. Tokenized funds and tokenized stocks only; null elsewhere.
`inception_date``STRING`Date of the first on-chain mint across the token's deployments, ISO 8601. No evidence column.
`inception_date_status``STRING`Status of `inception_date`, only ever `disclosed` or `not_available`: a null date means no deployment has an observed first mint yet, a gap in Token Terminal's own chain coverage rather than a statement about the issuer.
`asset_class``STRING`Asset type from the registry: `stablecoin`, `tokenized_funds`, `tokenized_stocks` or `tokenized_commodities`. No evidence column.
`underlying_ticker``STRING`Listed ticker of the equity a tokenized stock tracks, from the registry. Tokenized stocks only; null elsewhere. No evidence column.
`underlying_security_id``STRING`Stable registry ID of the exact underlying security, distinguished by legal issuer and share class; joins [`dimensions.underlying_securities`](/docs/catalog/real-world-assets/registry) on `security_id`.
`underlying_fund_relationship``STRING`Relationship between the token and the referenced fund: `same_fund` (the token directly represents units in the fund), `separate_fund` (the tokenized fund invests in a separate fund) or `certificate` (a certificate or structured note tracking the fund).
`underlying_isin``STRING`ISIN of the exact security the asset references, as its issuer's own documents state it; the evidence is why the asset maps to it. Joins [`dimensions.underlying_securities`](/docs/catalog/real-world-assets/registry) on `isin`.
`underlying_share_class``STRING`The exact class or units of the underlying security. Different classes are distinct securities.
`underlying_website``STRING`Official product or investor-relations page of the underlying security, rather than the tokenization program.
`underlying_fund_brand``STRING`Brand under which the underlying fund is marketed, kept separate from its legal issuer and operational providers.
`underlying_fund_sponsor``STRING`Entity explicitly appointed as sponsor of the underlying fund.
`underlying_fund_manager``STRING`Firm explicitly appointed to make investment decisions for the underlying fund's portfolio, separate from its administrator and from the manager of a separate tokenized fund.
`underlying_fund_administrator``STRING`Firm appointed to calculate the underlying fund's net asset value and keep its accounting records, separate from issuer, sponsor, investment manager, custodian and trustee.
`underlying_fund_trustee``STRING`Entity explicitly appointed as trustee of the underlying fund, separate from holding collateral or security interests for token holders.
`reference_asset``STRING`Identifier of the reference asset the token tracks, from the registry; joins [`dimensions.reference_assets`](/docs/catalog/assets/registry). No evidence column.
`issuer_project``STRING`Project id of the issuer, from the registry; joins [`dimensions.projects`](/docs/catalog/projects/registry). No evidence column.
`issuer_lei``ARRAY`LEI of the issuing entity per jurisdiction, from the GLEIF register. One element per issuing entity, keyed by the jurisdiction it issues under, `value` typed `STRING`.
`issuer_cik``ARRAY`SEC CIK of the issuing entity per jurisdiction, from EDGAR. One element per issuing entity, keyed by the jurisdiction it issues under, `value` typed `STRING`.
`fanned_out_from``STRING`For a token issued in bulk under one wrapper program (a tokenized stock, a commodity ETF wrapper or a tokenized fund), the program whose legal and operational terms are established on a sample of its tokens and apply to the rest; this column names that program. Null when no fan-out provenance is recorded on the row; null is not proof that every value was established on this token itself, since missing provenance cannot establish source ownership. No evidence column.
`fanned_out_from_status``STRING`Status of `fanned_out_from`: `disclosed` when the row came from a program and `not_available` when it did not. A value is non-null exactly when the status is `disclosed`.
**Underlying securities** One row per security a tokenized asset references, keyed by ISIN, with the values looked up for it in public registers (OpenFIGI, GLEIF, SEC EDGAR). An asset links to its row through `underlying_security_id` and `underlying_isin` on `dimensions.asset_disclosures`.
Column Type Description
`security_id` `STRING` Identifier of the security, formatted `{ticker}-{isin}` or `{class}-{isin}`, such as `1-kyg217651051`. Joins `dimensions.asset_disclosures.underlying_security_id`.
`security_class` `STRING` `equity` or `etf`.
`looked_up_at` `TIMESTAMP` When the register values were fetched. Null before the first lookup.
`inserted_at` `TIMESTAMP` When the registry snapshot behind the row was published.
`isin` `STRING` ISIN of the security. Joins `dimensions.asset_disclosures.underlying_isin`.
`name` `STRING` Security name as OpenFIGI records it for this ISIN, such as `BERKSHIRE HATHAWAY INC-CL B`.
`ticker` `STRING` Ticker of the US composite listing as OpenFIGI records it, such as `BRK/B`.
`security_type` `STRING` OpenFIGI security type, such as `Common Stock` or `ETP`.
`figi` `STRING` Share-class FIGI from OpenFIGI, the one FIGI that is the same in every country.
`cusip` `STRING` CUSIP embedded in a US or Canadian ISIN, kept when OpenFIGI maps it back to the same share class.
`issuer_name` `STRING` Legal name of the issuer on its GLEIF LEI record.
`issuer_lei` `STRING` LEI of the issuer from GLEIF. For a fund that is one series of a multi-fund trust, the trust's LEI.
`issuer_cik` `STRING` SEC Central Index Key of the issuer. SEC registrants only.
`issuer_jurisdiction` `STRING` Where the issuer is incorporated, as the ISO 3166 code on its GLEIF LEI record, such as `US-DE`.
`exchange` `STRING` Exchange the SEC lists for the issuer's ticker, such as `NYSE`. SEC registrants only.
`sic` `STRING` Standard Industrial Classification code the SEC assigns to the issuer. SEC registrants only.
`industry` `STRING` The SEC's description of the issuer's SIC code, such as `Fire, Marine & Casualty Insurance`.
`sector` `STRING` Sector mapped from the SIC code for equities, such as `financials`. Null where the code names no single sector, and for funds.
`sec_filings` `STRING` EDGAR page listing the issuer's SEC filings. SEC registrants only.
**Disclosure fields** One row per disclosure field of `dimensions.asset_disclosures`: the section heading, label and definition shown next to each disclosed term, and the definition of each closed-set value, in display order.
Column Type Description
`field_id` `STRING` The column of `dimensions.asset_disclosures` this row describes, such as `claim_type`.
`section_id` `STRING` Key of the section the field sits in: `identity`, `legal`, `providers`, `primary_market`, `identifiers` or `underlying`.
`section_title` `STRING` Heading shown above the section, such as `Legal and regulatory`.
`section_order` `INT64` Position of the section, from 1.
`field_order` `INT64` Position of the field within its section, from 1.
`title` `STRING` Label of the field, such as `Claim type`.
`definition` `STRING` One-sentence definition shown with the label.
`values` `ARRAY` One element per value a closed-set field can hold: `value` as stored in the column, `title`, its short display name, and `definition`, the sentence that explains it. Empty for a free-text field.
`inserted_at` `TIMESTAMP` When the registry snapshot behind the row was published.
**Underlying security fields** One row per column of `dimensions.underlying_securities`, in `dimensions.underlying_security_fields`: the section heading, label and definition shown next to each value, in display order.
Column Type Description
`field_id` `STRING` The column of `dimensions.underlying_securities` this row describes, such as `issuer_lei`.
`section_id` `STRING` Key of the section the field sits in: `security`, `issuer` or `classification`.
`section_title` `STRING` Heading shown above the section, such as `Classification`.
`section_order` `INT64` Position of the section, from 1.
`field_order` `INT64` Position of the field within its section, from 1.
`title` `STRING` Label of the field, such as `Issuer LEI`.
`definition` `STRING` One-sentence definition shown with the label.
`values` `ARRAY` One element per value a closed-set field can hold: `value` as stored in the column, `title`, its short display name, and `definition`, the sentence that explains it. Empty for a free-text field.
`inserted_at` `TIMESTAMP` When the registry snapshot behind the row was published.
## Sample queries **One asset's sheet** The identity, legal and primary-market terms of one asset as the sheet's first page shows them. A null value with status `not_available` means the issuer's documents were read and state nothing. ```sql theme={null} select disclosures.asset_id, disclosures.asset_class, disclosures.claim_type, disclosures.issuance_status, disclosures.custodian, disclosures.auditor, disclosures.primary_route, disclosures.kyc_required, disclosures.min_investment, disclosures.redemption_time, disclosures.isin from `dimensions.asset_disclosures` as disclosures where disclosures.asset_id = 'buidl' ``` **Tokenized stocks and their security** Each tokenized stock next to the share it references, joined on `underlying_security_id`. A `left join` keeps every stock, including one whose `underlying_security_id` is null. ```sql theme={null} select disclosures.asset_id, disclosures.issuer_project, securities.isin, securities.name, securities.ticker, securities.exchange, securities.sector from `dimensions.asset_disclosures` as disclosures left join `dimensions.underlying_securities` as securities on securities.security_id = disclosures.underlying_security_id where disclosures.asset_class = 'tokenized_stocks' order by disclosures.issuer_project, disclosures.asset_id ``` **Labels for a closed-set term** The display name and definition of every value `claim_type` can hold, as the sheet's last page lists them. Each closed-set field lists its values in the `values` array of `dimensions.asset_disclosure_fields`. ```sql theme={null} select fields.title as field, value.value, value.title, value.definition from `dimensions.asset_disclosure_fields` as fields cross join unnest(fields.values) as value where fields.field_id = 'claim_type' ``` **Underlying ISINs by issuer** Tokenized stocks per issuer, and how many name their underlying ISIN. `underlying_isin_status` is `not_available` where the issuer's documents were read and state none. ```sql theme={null} select disclosures.issuer_project, count(*) as tokenized_stocks, countif(disclosures.underlying_isin_status = 'disclosed') as with_isin from `dimensions.asset_disclosures` as disclosures where disclosures.asset_class = 'tokenized_stocks' group by disclosures.issuer_project order by tokenized_stocks desc ``` # Financial statements Source: https://tokenterminal.com/docs/catalog/popular-datasets/financial-statements A protocol's income statement and treasury, by reporting period. One row per project that reports fees, per period: the income statement and treasury beside the project's balances, volumes and user counts, in `reports_projects.financial_statements_quarterly` and in the `financial_statements_weekly`, `_monthly` and `_yearly` tables, which have the same columns. Flows such as `fees` are summed over the period, balances such as `tvl` are read on the period's last day with a value, and user counts such as `daily_active_users` are the average daily count. ## Coverage One row per project, ticked for every line item it reports.
Project Fees Supply-side fees Revenue Token incentives Expenses Earnings Trading volume Token trading volume Code commits Gas used Transaction count, contracts Treasury Treasury, net Total value locked Price Fully diluted market cap Circulating market cap Circulating supply Maximum token supply Token holders Active addresses, daily Core developers Active users, daily Active users, weekly Active users, monthly
`0x`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`1inch`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`aave`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`abracadabra`✓✗✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`acala`✓✓✓✗✗✗✓✓✓✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`across`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`aerodrome`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`aethir`✓✓✓✓✓✓✗✓✗✓✓✗✗✗✓✓✓✓✗✓✓✗✗✗✗
`airswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`ajuna`✓✓✓✗✗✗✓✓✓✗✗✗✗✗✓✓✗✗✗✓✓✓✓✓✓
`alephzero`✓✓✓✗✗✗✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`algorand`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`allbridge`✓✓✓✓✓✓✗✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`alongside`✓✗✓✓✓✓✗✗✗✓✓✓✗✓✗✗✗✗✗✗✓✗✗✗✗
`angle`✓✗✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗
`aperture`✓✓✓✓✓✓✓✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`apeswap`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`apollox`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`aptos`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`aragon`✓✗✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✗✓✓✓✗✗✗
`arbitrum`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`astar`✓✓✓✓✓✓✗✗✓✗✗✗✗✓✗✗✗✗✗✓✓✓✓✓✓
`aurafinance`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`avalanche`✓✓✓✗✗✗✗✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓
`aventus`✓✗✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`axelar`✓✓✓✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`axie`✓✓✓✗✗✗✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✗✗✗
`axiomtrade`✓✓✓✗✗✗✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`balancer`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`bancor`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`bankr`✓✓✓✗✗✗✓✓✗✓✓✗✗✗✓✓✓✓✗✗✓✗✓✓✓
`base`✓✓✓✓✓✓✗✗✓✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`beethoven`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`benddao`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`benqi`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`benqilsd`✓✗✗✗✗✗✗✗✗✗✗✗✗✓✗✗✗✗✗✗✗✗✓✓✓
`berachain`✓✓✓✗✗✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`betswirl`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`bifrostio`✓✓✓✓✓✓✓✓✓✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`biswap`✓✓✓✗✗✗✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`bitcoin`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`blast`✓✓✓✓✓✓✗✓✗✗✗✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`bloomtradingbot`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`bloxroute`✓✓✓✗✗✗✗✗✗✓✓✗✗✗✗✗✗✗✗✗✓✗✓✓✓
`blur`✓✓✓✓✓✓✓✓✗✓✓✓✗✗✓✓✓✓✓✓✓✗✓✓✓
`bmx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`bobanetwork`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`bonkbot`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`bouncefinance`✓✗✓✗✗✗✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓
`bsc`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`bufferfinance`✓✗✗✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`bullx`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`camelot`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`cap`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`cardano`✓✓✓✓✓✓✗✓✓✗✗✓✗✗✓✓✓✓✓✓✓✓✓✓✓
`celestia`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`celo`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`chainflip`✓✓✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✗✓✓✓
`chainlink`✓✗✓✗✗✗✗✓✓✓✓✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`circle`✓✓✓✓✓✓✓✗✓✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`clipper`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`coinshift`✓✓✓✓✓✓✗✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`compound`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`conflux`✓✓✓✗✗✗✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`connext`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`convexfinance`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`cosmos`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`cowswap`✓✓✓✓✗✗✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`cronos`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✗✗
`cryptex`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`curve`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`darwinia`✓✓✓✓✓✓✗✓✗✗✗✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`debridge`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`defisaver`✓✗✓✓✓✓✗✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✗✗✗
`deriprotocol`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`dexscreener`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`dfx`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`dinari`✓✓✓✗✗✗✗✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✗✗
`dodo`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`dogecoin`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`dolomite`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`dopex`✓✓✓✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`dreamcash`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`dydx`✓✓✓✓✓✓✗✓✓✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`edgex`✓✓✓✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✗✓✗✗✗✗✗
`eigenlayer`✓✓✓✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`elrond`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✗✗
`energyweb`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`equalizer`✓✓✓✗✗✗✓✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✗✓✓
`ethena`✓✓✓✗✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`ethereum`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`etherex`✓✓✓✓✓✓✓✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✓✓✓
`etherfi`✓✓✓✓✓✓✗✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✓✓✓
`euler`✓✓✓✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`falconfinance`✓✓✓✗✓✓✗✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✓✓✓
`fantom`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✗✗✓✗✗✗
`fathom`✓✓✓✗✗✗✓✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`felix`✓✓✓✗✗✗✗✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`filecoin`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✗✓✗✗✗
`flashbots`✓✗✓✓✗✗✗✗✓✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓
`flow`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`flyingtulip`✓✓✓✗✗✗✗✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✓✓✓
`fomo`✓✓✓✗✗✗✓✗✗✓✓✗✗✗✗✗✗✗✗✗✓✗✓✓✓
`foundation`✓✓✓✓✓✓✓✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`frax`✓✓✓✗✗✗✗✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`fraxtal`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✗✓✓✓
`friendtech`✓✓✓✓✓✓✓✓✗✓✓✓✗✓✓✓✓✓✗✓✓✗✓✓✓
`gammastrategies`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`gearbox`✓✓✓✗✗✗✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`gmgn`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`gmx`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`gnosis`✓✓✓✗✗✗✗✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓
`goldfinch`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`gravityalpha`✓✓✓✗✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓
`grove`✓✓✓✓✓✓✗✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✗✗✗
`hedera`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`hegic`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`heliopay`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`helium`✓✗✓✗✗✗✗✓✓✓✓✗✗✗✓✓✓✓✓✗✓✓✗✗✗
`hmx`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`holdstation`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`honeypop`✓✓✓✗✗✗✓✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`hop`✓✓✓✓✓✓✗✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓
`houdiniswap`✓✗✓✓✓✓✗✓✗✗✗✓✓✗✓✓✓✓✓✓✗✗✗✗✗
`hydradx`✓✓✓✗✗✓✓✓✓✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`hyena`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`hyperbridge`✓✓✓✓✓✓✗✓✗✗✗✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`hyperlend`✓✓✓✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`hyperliquid`✓✓✓✗✗✗✓✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓
`idex`✓✓✓✗✗✗✓✓✗✓✓✗✗✗✓✓✓✓✗✓✓✗✗✗✗
`immutable`✓✓✓✗✗✗✓✓✓✗✗✓✓✗✓✓✓✓✗✓✓✓✓✓✓
`indexcoop`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`injective`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓
`ink`✓✓✓✓✓✓✗✗✓✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`instadapp`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`integral`✓✓✓✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓✓✗✗✗
`internetcomputer`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✗✓✗✗✗
`iotex`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`ipor`✓✓✓✓✓✓✗✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓
`jito`✓✓✓✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓✗✗✓✓✓✓✓
`jupiter`✓✓✓✗✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✗✓✓✗✗✗
`kapitaldao`✓✓✓✓✗✓✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✗✗✗
`karura`✓✓✓✗✗✗✗✓✓✗✗✗✗✗✓✓✓✓✓✗✗✓✗✗✗
`katana`✓✓✓✓✓✓✓✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`katananetwork`✓✓✓✓✓✓✗✓✓✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`kelpdao`✓✓✓✗✗✗✗✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`kilt`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`kleros`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✓✓✓✓✗✗✗
`kusama`✓✓✓✓✓✗✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`kwenta`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`kyber`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`layer3`✓✗✓✗✓✓✗✓✗✓✓✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`layerzero`✓✓✓✗✓✓✗✓✗✓✓✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`lens`✓✓✓✓✓✓✓✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`levelfinance`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`lido`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`lighter`✓✓✓✗✗✗✗✓✗✗✗✗✗✓✓✓✓✓✗✓✗✗✗✗✗
`linea`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`liquity`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`litecoin`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓
`litentry`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`livepeer`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✗✓✓✓✗✗✗
`looksrare`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`maestro`✓✓✓✗✗✗✗✗✗✓✓✗✗✗✗✗✗✗✗✗✓✗✓✓✓
`maiar`✓✓✓✗✗✗✓✓✗✗✗✗✗✗✓✓✓✓✗✗✗✗✗✗✗
`makerdao`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`manifoldxyz`✓✓✓✓✓✓✓✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✗✗✗
`manta`✓✓✓✓✗✗✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`mantra`✓✓✓✓✓✓✓✓✓✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`maple`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`marinade`✓✓✓✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓✗✗✓✓✓✓✓
`maverick`✓✓✓✗✗✗✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`meanfinance`✓✓✓✓✓✓✓✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✗✗✗
`megaeth`✓✓✓✓✓✓✗✓✗✗✗✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`merkletrade`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓
`metavault`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`meteora`✓✓✓✗✗✗✓✓✗✓✓✗✗✓✓✓✓✓✗✗✓✗✓✓✓
`mina`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓
`monad`✓✓✓✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✗✗✓✗✓✓✓
`moonbeam`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`moonshot`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`moonwell`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`morpho`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`movement`✓✓✓✓✓✓✗✓✗✗✗✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`mummy`✓✓✓✓✓✓✗✗✓✓✓✗✗✓✗✗✗✗✓✗✓✓✓✓✓
`mux`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`mythos`✓✓✓✓✓✓✓✓✗✗✗✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`native`✓✓✓✗✗✗✓✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`near`✓✓✓✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`neuroweb`✓✓✓✓✓✓✗✓✗✗✗✗✗✗✓✓✗✗✗✓✓✗✓✓✓
`nexusmutual`✓✓✓✗✗✗✗✓✓✓✓✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`nftx`✓✓✓✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`notional`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`o1exchange`✓✓✓✗✗✗✓✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`okutrade`✓✓✓✗✗✗✓✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`okx`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`openchat`✓✓✓✗✗✗✗✓✓✗✗✓✗✗✓✗✓✓✓✗✗✓✓✓✓
`opensea`✓✓✓✓✓✓✓✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`optimism`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`opyn`✓✗✓✓✓✓✗✗✓✓✓✗✗✓✗✗✗✗✗✓✓✓✓✓✓
`orca`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✓✗✓✓✓✓✓
`origin`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`osmosis`✓✓✓✗✗✗✓✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✗✗
`pancakeswap`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`pangolin`✓✓✓✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`paragonperps`✓✓✓✗✗✗✗✗✓✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓
`peaq`✓✓✓✓✓✓✗✓✓✗✗✓✓✗✓✓✓✓✗✓✓✓✓✓✓
`pendle`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`pendulum`✓✓✓✗✗✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`perpetualprotocol`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`phala`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`phantom`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`pharaoh`✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✗✓✓✗✓✓✓
`photon`✓✓✓✗✗✗✓✗✗✓✓✗✗✗✗✗✗✗✗✗✓✗✓✓✓
`pikaprotocol`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`plasma`✓✓✓✓✓✓✗✓✗✗✗✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`pocketnetwork`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✗✓✗✗✗
`polkadot`✓✓✓✓✓✓✗✓✓✗✗✓✓✗✓✓✓✓✗✓✓✓✓✓✓
`polygon`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`polymarket`✓✓✓✓✓✓✓✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`polynomial`✓✓✓✓✓✓✗✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`pooltogether`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`premia`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`primenumbers`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`pumpfun`✓✓✓✗✗✗✓✓✗✓✓✗✗✗✓✓✓✓✗✗✓✗✓✓✓
`quickswap`✓✓✓✗✗✗✓✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`radiant`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`ramses`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`rarible`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✗✓✓✓✓✓✓
`raybot`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`raydium`✓✓✓✗✗✗✓✓✓✓✓✗✗✓✓✓✓✓✗✗✓✓✓✓✓
`reflexer`✓✗✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✗✗✗
`ren`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`reserve`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`ribbon`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`ringsprotocol`✓✓✓✓✓✓✗✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✓✓✓
`ripple`✓✓✓✓✓✓✓✓✓✗✗✗✗✓✓✓✓✓✓✗✓✓✓✓✓
`robinhood`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✗✓✓✓
`robonomics`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`ronin`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✗✓✓✓✓✓
`rootstock`✓✓✓✓✓✓✗✗✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`scroll`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`seamlessprotocol`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓
`seinetwork`✓✓✓✗✗✗✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`shadowexchange`✓✓✓✓✓✓✓✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✓✓✓
`shoebill`✓✓✓✓✓✓✗✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`silo`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`solana`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`solidlizard`✓✓✓✓✓✓✓✓✗✓✓✗✗✓✓✓✗✗✗✓✓✗✓✓✓
`soltradingbot`✓✓✓✗✗✗✗✓✗✗✗✗✗✗✓✓✗✗✗✗✗✗✓✓✓
`solv`✓✓✓✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`sonic`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`sound`✓✓✓✓✓✓✓✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`spark`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`spookyswap`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✗✓✓
`stacks`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`stader`✓✓✓✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`stakewise`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`starknet`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`steakhousefinancial`✓✓✓✓✓✓✗✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`stellar`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`sudoswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✗✓✓✓✓✓✓
`sui`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`superstate`✓✓✓✗✗✗✗✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✗✗✗
`sushiswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`swarm`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`sx`✓✗✓✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✓✓✗✓✓✗✗
`synapse`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`syncswap`✓✓✓✓✓✓✓✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`synfutures`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`synthetix`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✗✓✓✓✓✓✓
`tempo`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✗✓✓✓
`terra`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✗✓✗✗✗
`tether`✓✗✓✗✗✗✗✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✗✗✗
`tezos`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✗✓✗✗✗
`thales`✓✓✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`thegraph`✓✗✓✓✓✓✗✓✓✓✓✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`thena`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`thetanuts`✓✓✓✓✓✓✗✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`thruster`✓✓✓✓✓✓✓✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✓✓✓
`tokemak`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗
`tokenlon`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`ton`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`tornadocash`✓✗✓✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`toucan`✓✓✓✓✓✓✗✗✓✓✓✗✗✓✗✗✗✗✗✗✓✓✓✓✓
`traderjoe`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`tradexyz`✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓
`trojan`✓✓✓✗✗✗✗✗✗✓✓✗✗✗✗✗✗✗✗✗✓✗✓✓✓
`tron`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`truefi`✓✓✓✓✓✓✗✓✓✓✓✓✓✗✓✓✓✓✗✓✓✓✓✓✓
`unipilot`✓✓✓✓✓✓✗✗✓✓✓✗✗✗✗✗✗✗✗✓✓✓✓✓✓
`uniquenetwork`✓✓✓✗✗✗✓✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`uniswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`uniswaplabs`✓✓✓✓✓✓✓✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`usual`✓✗✓✗✗✗✗✓✗✓✓✗✗✓✓✓✓✓✗✓✓✗✗✗✗
`variational`✓✓✓✗✗✗✗✗✓✓✓✓✓✓✗✗✗✗✗✗✓✓✓✓✓
`velodrome`✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`ventuals`✓✓✓✗✗✗✗✗✓✗✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓
`venus`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`versedex`✓✓✓✓✓✓✓✓✗✓✓✗✗✓✓✓✓✓✓✓✓✗✓✓✓
`vertex`✓✓✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`vesta`✓✗✓✓✓✓✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`viction`✓✓✓✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✓✗✓✗✓✓✓
`virtualsprotocol`✓✓✓✗✗✗✗✓✗✓✓✗✗✗✓✓✓✓✗✗✓✗✗✗✗
`volmex`✓✓✓✓✓✓✗✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`voltz`✓✓✓✓✓✓✗✗✓✓✓✗✗✗✗✗✗✗✗✗✓✓✓✓✓
`wombat`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`worldmobilechain`✓✓✓✓✓✓✗✓✗✗✗✗✗✗✓✓✓✓✗✓✓✗✓✓✓
`x2y2`✓✓✓✓✓✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓
`xai`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓
`xdc`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓
`xoxno`✓✓✓✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✗✗✗✓✓✗✗
`xswap`✓✓✓✗✗✗✓✓✓✓✓✗✗✓✓✓✓✓✗✓✓✓✓✓✓
`zcash`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✓✗✗✓✗✗✗
`zerion`✓✗✓✓✓✓✓✗✓✓✓✓✗✗✗✗✗✗✗✗✓✓✓✓✓
`zerolend`✓✓✓✗✗✗✗✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`zksyncera`✓✓✓✓✓✓✗✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`zksyncerabridge`✓✗✓✗✗✗✗✗✗✓✓✗✗✓✗✗✗✗✗✗✓✗✓✓✓
`zora`✓✓✓✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✗✓✓✓✓✓✓
`zyberswap`✓✓✓✓✓✓✓✓✗✓✓✗✗✓✓✓✓✓✓✓✓✗✓✓✓
## Columns
Column Type Description
`project_id` STRING Project the statement belongs to, such as `aave`; joins `dimensions.projects`.
`period_start` TIMESTAMP First moment of the period.
`period_end` TIMESTAMP Last moment of the period.
`period_is_complete` BOOL False while the period is still running. Filter on it to compare finished periods, or leave it in to watch the current one forming.
`fees` FLOAT64 What users paid to use the protocol over the period, USD. A flow, so the periods inside a longer one add up to it.
`fees_supply_side` BIGNUMERIC The share of fees passed on to suppliers, USD.
`revenue` FLOAT64 Fees the protocol kept, USD. Measured directly, so for some projects it differs from `fees` minus `fees_supply_side`, sometimes materially.
`token_incentives` BIGNUMERIC Value of tokens paid out to attract usage, USD. Empty for a project that reports no incentives, which is a different thing from zero.
`expenses` BIGNUMERIC What the protocol spent over the period, USD. Empty for a project that reports no expenses, which is a different thing from zero.
`earnings` BIGNUMERIC What the protocol kept after costs, USD. Measured directly, so it can differ from `revenue` minus `expenses`, and it is negative where a protocol pays out more than it keeps.
`cost_of_revenue` BIGNUMERIC Direct supply-side cost of revenue. Summed over the period.
`operating_expenses` BIGNUMERIC Onchain operating expenses, excluding token incentives. Summed over the period.
`gross_profit` BIGNUMERIC Revenue minus cost of revenue. Summed over the period.
`trading_volume` BIGNUMERIC Cash value of the trades that took place, in USD. Summed over the period.
`transaction_volume` BIGNUMERIC USD value of transactions processed by the project. Summed over the period.
`transfer_volume` FLOAT64 USD value of assets moved through the project's bridge transfers, counted once per transfer. Summed over the period.
`token_trading_volume` FLOAT64 Trading volume of the project's own token. Summed over the period.
`code_commit_count` BIGNUMERIC Commits to public repositories. Summed over the period.
`gas_used` FLOAT64 Gas consumed by transactions calling the project's contracts. Summed over the period.
`transaction_count_contracts` BIGNUMERIC Transactions calling the project's contracts. Summed over the period.
`treasury` BIGNUMERIC Value the protocol held at the close of the period, USD. A balance read at the period end, so four quarterly figures added together mean nothing.
`treasury_net` BIGNUMERIC Value the protocol held at the close of the period in assets other than its own token, USD. Read at the period end, like `treasury`.
`tvl` BIGNUMERIC Value locked in the project's contracts at day end, in USD. Read at the close of the period.
`bridge_deposits` BIGNUMERIC USD value of assets held in the project's bridge contracts on the main chain. Read at the close of the period.
`active_loans` BIGNUMERIC Value of loans outstanding at day end, in USD. Read at the close of the period.
`assets_staked` BIGNUMERIC Value staked at day end, in USD. Read at the close of the period.
`capital_deployed` BIGNUMERIC USD value of user deposits an asset manager has allocated into investments. Read at the close of the period.
`outstanding_supply` FLOAT64 Stablecoin supply issued by the project and outstanding, in USD. Stablecoin issuers only. Read at the close of the period.
`price` FLOAT64 Project token price in USD. Read at the close of the period.
`market_cap_fully_diluted` FLOAT64 Market cap on maximum supply. Read at the close of the period.
`market_cap_circulating` FLOAT64 Market cap on circulating supply. Read at the close of the period.
`token_supply_circulating` BIGNUMERIC Circulating token supply. Read at the close of the period.
`token_supply_maximum` BIGNUMERIC Maximum token supply. Read at the close of the period.
`token_holders` BIGNUMERIC Addresses holding the project's token. Averaged over the days of the period.
`daily_active_addresses` BIGNUMERIC Distinct addresses transacting with the project's contracts per day. Averaged over the days of the period.
`monthly_active_developers` BIGNUMERIC Number of active developers. Averaged over the days of the period.
`daily_active_users` BIGNUMERIC Distinct addresses that used the project that day. A HyperLogLog estimate. Averaged over the days of the period.
`weekly_active_users` BIGNUMERIC Distinct addresses that used the project in the trailing 7 days. A HyperLogLog estimate. Averaged over the days of the period.
`monthly_active_users` BIGNUMERIC Distinct addresses that used the project in the trailing 30 days. A HyperLogLog estimate. Averaged over the days of the period.
## Sample queries **One statement** The columns come back in statement order, `fees` down to `earnings`, then the treasury. `period_is_complete` leaves out the quarter still running. ```sql theme={null} select period_start, period_end, fees, fees_supply_side, revenue, expenses, token_incentives, earnings, treasury_net from `reports_projects.financial_statements_quarterly` where project_id = 'aave' and period_is_complete order by period_start desc ``` **Most profitable protocols** The subquery pins the latest finished quarter, so the ranking reads one period. `earnings` is filled in where a project reports expenses, and the null filter keeps those rows. ```sql theme={null} select projects.name, statements.revenue, statements.earnings from `reports_projects.financial_statements_quarterly` as statements join `dimensions.projects` as projects using (project_id) where statements.period_is_complete and statements.period_start = ( select max(period_start) from `reports_projects.financial_statements_quarterly` where period_is_complete ) and statements.earnings is not null order by statements.earnings desc limit 25 ``` **Quarter over quarter** Every period a project reported is a row, so a comparison is a window function. `lag()` over `period_start` gives the prior period. ```sql theme={null} select period_start, revenue, lag(revenue) over (order by period_start) as revenue_prior, safe_divide( revenue - lag(revenue) over (order by period_start), abs(lag(revenue) over (order by period_start)) ) as revenue_change from `reports_projects.financial_statements_quarterly` where project_id = 'uniswap' and period_is_complete order by period_start desc ``` **Growing on the year** Four quarters back is the same quarter a year earlier, so `lag(revenue, 4)` partitioned by project gives the year-ago figure. The revenue floor keeps a small base from dominating the ranking. ```sql theme={null} with quarters as ( select project_id, period_start, revenue, lag(revenue, 4) over ( partition by project_id order by period_start ) as revenue_year_ago from `reports_projects.financial_statements_quarterly` where period_is_complete ) select projects.name, quarters.revenue, safe_divide(quarters.revenue - quarters.revenue_year_ago, abs(quarters.revenue_year_ago)) as revenue_yoy from quarters join `dimensions.projects` as projects using (project_id) where quarters.period_start = (select max(period_start) from quarters) and quarters.revenue > 1000000 and quarters.revenue_year_ago is not null order by revenue_yoy desc limit 25 ``` # Geographic intelligence Source: https://tokenterminal.com/docs/catalog/popular-datasets/geographic-intelligence Region of activity, funding venue and attested country for an address, with jurisdiction from venues that serve one country. Region of activity, funding source and attested country for an address. The tables here serve the region band, the funding venue and jurisdiction, the attested country, and the evidence and coverage behind them. We publish where a wallet is active, where it was funded and, for holders who opted in, the country Coinbase attested for it. Region of activity, unchanged from v1, is a UTC-offset band derived from public transaction timing. Funding source is new. Where we can trace a wallet's incoming transfers to an exchange, custodian, or fiat ramp, we publish which venue funded it, the venue's type, whether that venue address was curated by a person or detected from wallet behavior, a confidence tier of high, medium, or low, how many funding transactions back the tag, and when the funding relationship was first observed. Funding jurisdiction is the country the venue that funded the wallet is registered in and serves, published only where the venue serves a single country. A wallet funded through a regional or global exchange gets a null jurisdiction, because that value describes the venue, not the person who holds the wallet. Neither region nor funding reads a partner's KYC records, and no country is derived from how or when an address transacts, only from where the venue that funded it is registered. Attested country is different in kind: it is the country of residence Coinbase recorded when it verified the account holder, issued as an opt-in attestation the holder can revoke, and we republish it as issued without deriving anything from it. `region` on [Accounts ▸ Registry](/docs/catalog/accounts/registry) is derived from [activity hours](/docs/catalog/accounts/activity-hours): 1. Sum the address's hourly transaction counts over the trailing 90 complete UTC days, across every chain in its `chain_family`; `n` is the total. Addresses with `n` below 300 get a null `region_confidence`. 2. The trough is the 6-hour window with the smallest share of `n`; its centre hour is `t`. The UTC offset is `round(3.5 - t)`, wrapped to -11..+12, taking 03:30 as the local sleep centre. 3. The band is the one of seven that contains the offset. 4. Depth `d` = `1 - (trough share / 0.25)`; night share is the share in the 12 hours centred on the trough. 5. `high` needs `n >= 3000`, `d >= 0.70`, night `<= 0.25`; `medium` needs `n >= 1000`, `d >= 0.50`, night `<= 0.30`; `low` needs `n >= 300`, `d >= 0.30`, night `<= 0.35`; otherwise `region` and `region_confidence` are null. A second trough within 10% of the first caps confidence at `low`. ## Coverage Region: `ethereum`, `base` and `robinhoodchain` (evm). `solana` (svm). Funding: `arbitrum`, `base`, `bsc`, `ethereum` and `robinhoodchain` (evm). `solana` (svm). Attested country: every evm chain. ## Tables * [`dimensions.accounts`](/docs/catalog/accounts/registry) region, funding and attested country columns, on Accounts ▸ Registry. * [`facts_accounts.activity_hours`](/docs/catalog/accounts/activity-hours), the hourly evidence `region` is derived from. * [`reports_accounts.activity_coverage`](/docs/catalog/accounts/activity-coverage), the share of each day's active senders that are attributed and regioned. * [`reports_accounts.region_distribution`](/docs/catalog/accounts/region-distribution), a trailing 90-day snapshot of senders by region and confidence. * [`reports_accounts.region_hit_rate`](/docs/catalog/accounts/region-hit-rate), region accuracy for accounts with a known expected band. * [`dimensions.venues`](/docs/catalog/accounts/registry), the Venues tab on Accounts ▸ Registry. * [`facts_accounts.funding`](/docs/catalog/accounts/funding), the funding venue, confidence and jurisdiction behind an account. * [`facts_accounts.venue_edges`](/docs/catalog/accounts/venue-edges), the funding edges a tag is built from. * [`facts_accounts.attested_country`](/docs/catalog/accounts/attested-country), the country Coinbase attested for a wallet, and the attestation it comes from. * [`reports_accounts.funding_coverage`](/docs/catalog/accounts/funding-coverage), the share of each chain's funded wallets that resolve to a venue. * [`reports_accounts.funding_venue_distribution`](/docs/catalog/accounts/funding-venue-distribution), funded wallets by venue and confidence tier. * [`reports_accounts.funding_region_agreement`](/docs/catalog/accounts/funding-region-agreement), how often a wallet's region matches its funding venue's expected band. * [`reports_accounts.funding_hit_rate`](/docs/catalog/accounts/funding-hit-rate), curated deposit anchors against detected deposit addresses. ## Sample queries **Band distribution on one chain** The subquery pins the window ending on the latest `window_end` for `ethereum`, so the ranking reads one snapshot rather than mixing windows. ```sql theme={null} select region, region_confidence, senders, sender_share from `reports_accounts.region_distribution` where chain_id = 'ethereum' and window_end = ( select max(window_end) from `reports_accounts.region_distribution` where chain_id = 'ethereum' ) order by senders desc ``` **A project's wallets by region** `project_id` filters `dimensions.accounts` to one attributed project; `region` is null wherever `region_confidence` is null. ```sql theme={null} select chain_id, address, region, region_confidence from `dimensions.accounts` where project_id = 'coinbase' order by chain_id, region_confidence desc ``` **Coverage across chains, latest complete day** `activity_date` is fixed to yesterday because the day still running is partial and gets rewritten by the next run. ```sql theme={null} select chain_id, attributed_share, regioned_share from `reports_accounts.activity_coverage` where activity_date = date_sub(current_date(), interval 1 day) order by regioned_share desc ``` # P&L Source: https://tokenterminal.com/docs/catalog/popular-datasets/pnl What an account paid for its tokens and what they are worth now. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! One row per account per token per day: the cost basis of the position, its value at that day's price, and the realized and unrealized result. Cost basis needs a stated method, because an account that bought the same token at two prices and sold half has two defensible answers. # Prices Source: https://tokenterminal.com/docs/catalog/popular-datasets/prices One USD price per token and per curated asset, per day. A price is one USD figure at one moment, held per token contract on one chain and per curated asset. `price` is that figure, and a row appears for each day a price was taken for that day. ## Coverage Every chain we cover prices on. `algorand` `aptos` `arbitrum` `avalanche` `base` `berachain` `blast` `bob` `bobanetwork` `bsc` `cardano` `celo` `chainflip` `ethereum` `flowevm` `fraxtal` `gnosis` `gravityalpha` `hedera` `hydradx` `hydradxevm` `hyperevm` `immutablezkevm` `ink` `iotex` `katananetwork` `linea` `manta` `megaeth` `monad` `movement` `near` `opbnb` `optimism` `plasma` `polkadotassethub` `polygon` `ripple` `robinhoodchain` `rootstock` `scroll` `seievm` `solana` `sonic` `stacks` `starknet` `stellar` `sui` `tempo` `tron` `unichain` `viction` `worldchain` `xdc` `xlayer` `zksyncera` ## Tables **Token, daily** One row per token per day, in `metrics_tokens.price_daily`.
Column Type Description
`timestamp`TIMESTAMPThe moment the price was taken: midnight UTC in the daily table, the top of the hour in the hourly one.
`token_id`STRINGToken the price belongs to: `{token_address}-{chain_id}`.
`chain_id`STRINGChain the token is deployed on.
`price`FLOAT64The price in US dollars at that moment.
**Token, hourly** One row per token per hour, in `metrics_tokens.price_hourly`. It keys the same way as the daily table, so moving a query between them means swapping the table name and the time bounds.
Column Type Description
`timestamp`TIMESTAMPThe moment the price was taken: midnight UTC in the daily table, the top of the hour in the hourly one.
`token_id`STRINGToken the price belongs to: `{token_address}-{chain_id}`.
`chain_id`STRINGChain the token is deployed on.
`price`FLOAT64The price in US dollars at that moment.
**Asset, daily** One row per asset per day, in `metrics_assets.price_daily`. An asset price belongs to the asset itself, so it holds across every chain the asset is deployed on.
Column Type Description
`timestamp`TIMESTAMPMidnight UTC of the day the price was taken.
`asset_id`STRINGIdentifier of the asset, for example `usdc`.
`price_source`STRINGWhich source the figure came from. It labels the price and measures nothing.
`price`FLOAT64The asset's price in USD. Where more than one source has a price, we take them in a fixed order of preference.
## Sample queries > [!WARNING] > > `metrics_tokens.price_hourly` is large and split by month. Bound `timestamp` and filter `chain_id` on every query against it, or you read the whole table and the whole table is billed to you. **One asset, every chain** `dimensions.asset_tokens` maps one asset onto its deployments, and `token_id` is the key it shares with the price table, which holds one price per deployment. ```sql theme={null} select prices.timestamp, deployments.chain_id, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.asset_tokens` as deployments using (token_id) where deployments.asset_id = 'usdc' and prices.timestamp >= timestamp('2026-07-01') order by prices.timestamp, deployments.chain_id ``` **Asset against deployment** The two figures are measured separately, so they can differ on the same day. Both tables have `timestamp` at midnight UTC, and the join matches on it. ```sql theme={null} select assets.timestamp, assets.price as asset_price, tokens.price as token_price from `metrics_assets.price_daily` as assets join `metrics_tokens.price_daily` as tokens on tokens.timestamp = assets.timestamp and tokens.token_id = '0xdac17f958d2ee523a2206206994597c13d831ec7-ethereum' and tokens.timestamp >= timestamp('2026-07-01') where assets.asset_id = 'usdt' and assets.timestamp >= timestamp('2026-07-01') order by assets.timestamp ``` **Pricing an event** The hourly table is keyed on the top of the hour, so `timestamp_trunc` matches an event to it. Bound `block_timestamp` and filter `chain_id` on the transfer side too: that table is billed on what the query reads. ```sql theme={null} select transfers.block_timestamp, transfers.transaction_hash, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) * prices.price as amount_usd from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) join `metrics_tokens.price_hourly` as prices on prices.token_id = transfers.token_id and prices.timestamp = timestamp_trunc(transfers.block_timestamp, hour) where transfers.token_address = '0xdac17f958d2ee523a2206206994597c13d831ec7' and transfers.chain_id = 'ethereum' and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') order by amount_usd desc limit 20 ``` # Token transfers Source: https://tokenterminal.com/docs/catalog/popular-datasets/token-transfers Every fungible token transfer, joined to the entity that issued it. One row per fungible token movement in `facts_tokens.transfers`: a transfer, a mint or a burn, on every chain we decode. `amount_raw` is the amount in the token's smallest unit, so divide by `10^decimals` from [`dimensions.tokens`](/docs/catalog/tokens/registry) to read whole tokens. ## Coverage Every chain we cover token transfers on. `acala` `alephzeroevm` `algorand` `aptos` `arbitrum` `astar` `avalanche` `base` `berachain` `blast` `bob` `bobanetwork` `bsc` `cardano` `celestia` `celo` `centrifuge` `chainflip` `cosmoshub` `dydx` `ethereum` `fantom` `flow` `flowevm` `fraxtal` `gnosis` `gravityalpha` `hedera` `hydradx` `hydradxevm` `hyperevm` `immutablezkevm` `injective` `injectiveevm` `ink` `interlay` `iotex` `katananetwork` `linea` `manta` `mantaatlantic` `mantra` `mantrachain` `mantraevm` `megaeth` `monad` `moonbeam` `movement` `near` `neuroweb` `noble` `opbnb` `optimism` `osmosis` `peaq` `phala` `plasma` `polimec` `polkadex` `polkadotassethub` `polygon` `ripple` `robinhoodchain` `ronin` `rootstock` `scroll` `sei` `seievm` `solana` `sonic` `stacks` `starknet` `stellar` `sui` `tempo` `ton` `tron` `unichain` `viction` `worldchain` `xai` `xdc` `xlayer` `zksyncera` ## Columns
Column Type Description
`partition_key`TIMESTAMPThe month the row belongs to. The table is partitioned on it, so a date filter is cheapest when it names this alongside `block_timestamp`.
`block_timestamp`TIMESTAMPWhen the block was produced.
`block_number`INT64Block height, or the slot on Solana.
`transaction_hash`STRINGTransaction the movement belongs to. Null on `hydradx`, where a transfer can be emitted by a block hook instead of by a transaction.
`transaction_index`INT64Position of the transaction in its block. Solana only.
`outer_event_index`INT64Enclosing instruction position on Solana. Null on the log-shaped chains, which have one nesting level, and null on Solana wherever the instruction is top level and has nothing enclosing it.
`event_index`INT64Position within the transaction: the log index, or the instruction index on Solana.
`chain_id`STRINGChain the movement happened on.
`token_type`STRINGToken standard: `erc20`, `spl` or `trc20`.
`token_id`STRINGJoin key to [`dimensions.tokens`](/docs/catalog/tokens/registry).
`token_address`STRINGThe token. Filter on this. Null on the Solana transfers whose token account the upstream decode could not resolve, which leaves `token_id` null on the same rows.
`event_type`STRING`transfer`, `mint` or `burn`.
`from_address`STRINGAccount debited. Null on a mint.
`to_address`STRINGAccount credited. Null on a burn.
`to_owner`STRINGHolder behind `to_address`. Solana transfers only: null on exactly the rows where `token_address` is, and always null on mints and burns.
`authority_address`STRINGAccount that authorised the instruction. Solana only.
`transaction_signer`STRINGSigner of the enclosing transaction. Solana only.
`executing_account`STRINGProgram that executed the instruction. Solana only.
`amount_raw`STRINGAmount in the token's smallest unit, as a decimal string, because a uint256 exceeds every BigQuery numeric type. Divide by `10^decimals`.
`surrogate_key`BYTESRow identity, a 128-bit hash of the columns that define the grain. Stable across rebuilds; compare it with `from_hex`.
## Sample queries > [!WARNING] > > This table is large and split by month on `partition_key`. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One asset, every deployment** `dimensions.asset_tokens` turns one asset into its deployments, and `dimensions.tokens` has the decimals that turn `amount_raw` into whole tokens. ```sql theme={null} select transfers.block_timestamp, deployments.chain_id, transfers.from_address, transfers.to_address, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.asset_tokens` as deployments using (token_id) join `dimensions.tokens` as tokens on tokens.token_id = transfers.token_id where deployments.asset_id = 'usdc' and transfers.block_timestamp >= timestamp('2026-08-20') and transfers.block_timestamp < timestamp('2026-08-21') limit 100 ``` **Daily volume in USD** The fact has token amounts, so USD comes from a join to `metrics_tokens.price_daily` on `token_id` and the day the transfer falls in. ```sql theme={null} select timestamp_trunc(transfers.block_timestamp, day) as day, round(sum(cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) * prices.price)) as volume_usd from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) join `dimensions.asset_tokens` as deployments on deployments.token_id = transfers.token_id join `metrics_tokens.price_daily` as prices on prices.token_id = transfers.token_id and prices.timestamp = timestamp_trunc(transfers.block_timestamp, day) where deployments.asset_id = 'usdc' and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') group by day order by day ``` **Counterparties of an account** `from_address` and `chain_id` together identify the sender, because the same address on two chains is two accounts. ```sql theme={null} select transfers.to_address, tokens.symbol, count(*) as transfer_count from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.from_address = '0x28c6c06298d514db089934071355e5743bf21d60' and transfers.chain_id = 'ethereum' and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') group by transfers.to_address, tokens.symbol order by transfer_count desc limit 25 ``` # User retention Source: https://tokenterminal.com/docs/catalog/popular-datasets/user-retention A protocol's monthly user cohorts, and the share of each still active in the months after signup. One row per project per signup month in `reports_projects.user_retention_monthly`: the users first active in the project that month, and the share of them active in each of the twelve months from signup. A user is an address active in the project in a month, and the counts are HyperLogLog estimates at precision 15. ## Columns
Column Type Description
`project_id` STRING Project the cohort belongs to, such as `aave`; joins `dimensions.projects`.
`period_start` TIMESTAMP First moment of the signup month. A project's rows run every month from its first cohort to its latest month, and for an archived project they end at the month it was archived.
`period_end` TIMESTAMP Last moment of the signup month.
`period_is_complete` BOOL False while the signup month is still running. The table is rebuilt weekly, and a cohort's later cells keep moving until their own month ends.
`cohort_users` INT64 Distinct users first active in the project that month. 0 for a month with no new users.
`retention_month_0` FLOAT64 Share of the cohort active in its signup month: 1 for a cohort with users, 0 for an empty one.
`retention_month_1` FLOAT64 Share of the cohort active in the month after signup, as a fraction to three decimal places. Null until that month is reached, 0 when it is reached with no activity.
`retention_month_2` FLOAT64 The same share, 2 months after signup.
`retention_month_3` FLOAT64 The same share, 3 months after signup.
`retention_month_4` FLOAT64 The same share, 4 months after signup.
`retention_month_5` FLOAT64 The same share, 5 months after signup.
`retention_month_6` FLOAT64 The same share, 6 months after signup.
`retention_month_7` FLOAT64 The same share, 7 months after signup.
`retention_month_8` FLOAT64 The same share, 8 months after signup.
`retention_month_9` FLOAT64 The same share, 9 months after signup.
`retention_month_10` FLOAT64 The same share, 10 months after signup.
`retention_month_11` FLOAT64 The same share, 11 months after signup.
## Sample queries **One project's cohort triangle** Each row is a signup month and each `retention_month_k` column a month since signup. Cells for months not reached yet are null, which gives the triangle its shape. ```sql theme={null} select period_start, cohort_users, retention_month_0, retention_month_1, retention_month_2, retention_month_3, retention_month_6, retention_month_11 from `reports_projects.user_retention_monthly` where project_id = 'uniswap' and period_start >= timestamp('2025-01-01') order by period_start ``` **Month-3 retention across projects** The window holds the twelve latest signup months whose third month after signup has ended. Weighting by `cohort_users` keeps a month with few new users from moving the average, and the floor keeps small projects out of the ranking. ```sql theme={null} with cohorts as ( select project_id, cohort_users, retention_month_3 from `reports_projects.user_retention_monthly` where period_start >= timestamp(date_sub(date_trunc(current_date(), month), interval 15 month)) and period_start < timestamp(date_sub(date_trunc(current_date(), month), interval 3 month)) and cohort_users > 0 ) select projects.name, sum(cohorts.cohort_users) as cohort_users, safe_divide( sum(cohorts.cohort_users * cohorts.retention_month_3), sum(cohorts.cohort_users) ) as retention_month_3 from cohorts join `dimensions.projects` as projects using (project_id) group by projects.name having sum(cohorts.cohort_users) >= 10000 order by retention_month_3 desc limit 25 ``` **Average retention curve** `unpivot` turns the twelve retention columns into one row per month since signup. Null cells drop out, so each point averages only the cohorts that have reached it. ```sql theme={null} select months_since_signup, safe_divide(sum(cohort_users * retention), sum(cohort_users)) as retention from ( select cohort_users, retention_month_0 as m0, retention_month_1 as m1, retention_month_2 as m2, retention_month_3 as m3, retention_month_4 as m4, retention_month_5 as m5, retention_month_6 as m6, retention_month_7 as m7, retention_month_8 as m8, retention_month_9 as m9, retention_month_10 as m10, retention_month_11 as m11 from `reports_projects.user_retention_monthly` where project_id = 'aave' and period_start >= timestamp('2025-01-01') and cohort_users > 0 ) unpivot ( retention for months_since_signup in ( m0 as 0, m1 as 1, m2 as 2, m3 as 3, m4 as 4, m5 as 5, m6 as 6, m7 as 7, m8 as 8, m9 as 9, m10 as 10, m11 as 11 ) ) group by months_since_signup order by months_since_signup ``` # Yields Source: https://tokenterminal.com/docs/catalog/popular-datasets/yields The yield an asset pays, per asset and per deployment. A yield is a rate written as a fraction: `0.05` is five percent. `apy` is the yield over the past year, measured once per asset per day and never added up across assets, deployments or days. ## Coverage Every issuer that reports a yield, and the chains it pays on. One row per issuer.
Issuer Chains
`3jane``ethereum`
`aave``arbitrum`, `avalanche`, `base`, `bsc`, `ethereum`, `gnosis`, `linea`, `optimism`, `plasma`, `polygon`, `scroll`, `sonic`, `zksyncera`
`accountable``monad`
`angle``arbitrum`, `ethereum`, `gnosis`
`anzen``arbitrum`, `base`, `blast`, `ethereum`
`apyx``base`, `ethereum`
`capapp``ethereum`, `katananetwork`, `megaeth`, `tempo`
`centrifuge``arbitrum`, `avalanche`, `base`, `bsc`, `celo`, `ethereum`, `monad`, `optimism`, `plumenetwork`, `solana`, `stellar`
`circle``bsc`, `ethereum`, `near`, `solana`
`coinshift``ethereum`
`curve``ethereum`, `xdc`
`dtrinity``sonic`
`ethena``aptos`, `arbitrum`, `avalanche`, `base`, `berachain`, `blast`, `bsc`, `ethereum`, `hyperevm`, `linea`, `manta`, `megaeth`, `monad`, `optimism`, `plasma`, `robinhoodchain`, `solana`, `tempo`, `zksyncera`
`etherfi``ethereum`
`falconfinance``ethereum`
`fraxstablecoin``arbitrum`, `ethereum`, `fraxtal`, `katananetwork`, `seievm`, `sonic`
`fxprotocol``ethereum`
`gauntlet``ethereum`
`gyroscope``arbitrum`, `avalanche`, `ethereum`, `optimism`, `polygon`
`hastra``ethereum`, `solana`
`inversefinance``ethereum`
`k3capital``ethereum`
`kelpdao``ethereum`, `megaeth`
`lido``ethereum`, `megaeth`, `robinhoodchain`
`makerdao``arbitrum`, `base`, `ethereum`, `optimism`, `unichain`
`mantle``ethereum`
`maple``arbitrum`, `base`, `ethereum`, `plasma`, `robinhoodchain`, `solana`
`midas``base`, `ethereum`, `monad`, `plasma`, `rootstock`, `starknet`
`morpho``arbitrum`, `base`, `ethereum`, `hyperevm`, `monad`, `optimism`, `polygon`, `robinhoodchain`, `unichain`, `worldchain`
`mountainprotocol``arbitrum`, `avalanche`, `base`, `celo`, `ethereum`, `optimism`, `polygon`, `zksyncera`
`nest``arbitrum`, `ethereum`, `plasma`, `plumenetwork`, `solana`
`neutrl``ethereum`
`noon``ethereum`, `starknet`, `zksyncera`
`ondo``aptos`, `arbitrum`, `ethereum`, `mantle`, `polygon`, `ripple`, `seievm`, `solana`, `stellar`, `sui`
`openedendigital``arbitrum`, `bsc`, `ethereum`, `ripple`, `solana`
`opentrade``avalanche`
`pareto``ethereum`
`re``avalanche`, `base`, `ethereum`, `tempo`
`resupply``ethereum`
`rocketpool``ethereum`
`saturn``ethereum`
`securitize``aptos`, `arbitrum`, `avalanche`, `bsc`, `ethereum`, `optimism`, `polygon`, `solana`
`sivo``ethereum`
`spark``robinhoodchain`
`spiko``arbitrum`, `base`, `ethereum`, `polygon`, `solana`, `starknet`, `stellar`
`st0x``base`
`stakewise``ethereum`
`strata``ethereum`
`superstate``ethereum`, `solana`
`swell``ethereum`
`tenbinlabs``ethereum`
`textilecredit``base`, `ethereum`
`theo``arbitrum`, `base`, `ethereum`, `hyperevm`
`tronusdd``bsc`, `ethereum`
`upshiftfinance``ethereum`
`usdai``arbitrum`, `ethereum`, `plasma`
`usual``ethereum`
`xsy``base`
`yieldfi``arbitrum`, `base`, `ethereum`, `katananetwork`, `optimism`, `plumenetwork`, `sonic`
`yieldnest``ethereum`
`yieldoptimizer``base`
`yuzu``plasma`
## Tables **Asset** One row per asset per day, in `metrics_assets.apy_daily`.
Column Type Description
`timestamp`TIMESTAMPMidnight UTC of the day measured.
`asset_id`STRINGIdentifier of the asset, for example `usdc`. Joins `dimensions.assets`.
`apy`FLOAT64The asset's yield over the past year, written as a fraction: `0.05` means five percent. Measured once per asset per day, and never added up.
**Deployment** One row per deployment per day, in `metrics_asset_tokens.apy_daily`. A deployment is one token contract on one chain.
Column Type Description
`timestamp`TIMESTAMPMidnight UTC of the day measured.
`asset_token_id`STRINGIdentifier of the deployment, formatted `{asset_id}-{token_address}-{chain_id}`. Joins `dimensions.asset_tokens`.
`apy`FLOAT64Yield over the past year, written as a fraction and kept within `(0, 0.50]`. Measured once per asset, on the deployment with the largest circulating market cap, then copied onto the asset's other deployments. Never added up.
## Sample queries **Highest asset yields** Yield and supply are two tables, joined on `asset_id` at one `timestamp`. `market_cap_circulating_native` is the weight to read a rate against. ```sql theme={null} with yields as ( select asset_id, apy from `metrics_assets.apy_daily` where timestamp = timestamp('2026-08-20') ), supply as ( select asset_id, market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` where timestamp = timestamp('2026-08-20') ) select assets.name, assets.asset_type, yields.apy, supply.market_cap_circulating_native from yields left join supply using (asset_id) join `dimensions.assets` as assets using (asset_id) order by yields.apy desc limit 25 ``` **One asset over time** A `full join` on `timestamp` keeps a day with a yield but no supply figure, and the reverse. Bound `timestamp` on both sides: an unbounded side reads its whole table. ```sql theme={null} with yields as ( select timestamp, apy from `metrics_assets.apy_daily` where asset_id = 'buidl' and timestamp >= timestamp('2026-06-01') ), supply as ( select timestamp, market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` where asset_id = 'buidl' and timestamp >= timestamp('2026-06-01') ) select timestamp, yields.apy, supply.market_cap_circulating_native from yields full join supply using (timestamp) order by timestamp ``` **Supply-weighted average** Each day's rates are weighted by circulating market cap, so a large asset moves the average more than a small one. `asset_type` on `dimensions.assets` is what narrows the average to one class of asset. ```sql theme={null} with yields as ( select asset_id, timestamp, apy from `metrics_assets.apy_daily` where timestamp >= timestamp('2026-07-01') ), supply as ( select asset_id, timestamp, market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` where timestamp >= timestamp('2026-07-01') and market_cap_circulating_native > 0 ) select yields.timestamp, sum(yields.apy * supply.market_cap_circulating_native) / sum(supply.market_cap_circulating_native) as weighted_apy from yields join supply using (asset_id, timestamp) join `dimensions.assets` as assets using (asset_id) where assets.asset_type = 'rwa' group by yields.timestamp order by yields.timestamp ``` **Yield by chain** The deployment table has `asset_token_id` alone, so the chain comes from `dimensions.asset_tokens`. ```sql theme={null} select daily.timestamp, deployments.chain_id, daily.apy from `metrics_asset_tokens.apy_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) where deployments.asset_id = 'buidl' and daily.timestamp >= timestamp('2026-08-01') order by daily.timestamp, deployments.chain_id ``` # Prediction markets Source: https://tokenterminal.com/docs/catalog/prediction-markets Every outcome market: trades, volume and positions, across every venue. > [!NOTE] > > **In progress.** This vertical is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! A prediction market lets users trade on the outcome of an event, one market per question. The vertical lands with a market registry, the trades, and daily volumes per market. # Projects Source: https://tokenterminal.com/docs/catalog/projects/index Protocols, the apps they run, and financial metrics at every level. A project is the protocol or company behind what we track, such as Uniswap, Aave or Hyperliquid. It runs one or more [apps](/docs/catalog/apps/index), and where it operates a blockchain, that [chain](/docs/catalog/chains/index) belongs to it too. A project's figures add up everything it runs, and the project-and-chain tables split the same figures by chain. ## Coverage A tab per grain. Each tab says what one row is, and a tick marks every project that reports the measure at that grain. **Project** A project is the protocol or company behind what we track, such as `uniswap`. One row per project per day, every app and chain together.
Project Price Fully diluted market cap Circulating market cap Token trading volume Token holders Circulating token supply Fees Revenue Daily active users Weekly active users Monthly active users Active addresses daily Active addresses weekly Active addresses monthly Active developers Code commits Gas used Transaction count contracts
`0glabs`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`0x`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`10kswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`14numbers`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`1inch`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`22xfund`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`24karat`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`3adao`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`3jane`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`48club`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`4everland`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`6degrees`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`8finity`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`a7a5`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`aarkdigital`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`aarna`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`aave`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`abel`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`abracadabra`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`abstract`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`abt`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`acala`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`accountable`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`across`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`acurast`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`adappt`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`aegis`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`aerodrome`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`aethir`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✗✗✓✓
`aevo`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`aftermath`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`agant`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`agora`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`airswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`aitech`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`ajuna`✓✓✗✓✓✗✓✓✓✓✓✓✓✓✓✓✗✗
`akash`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`aktionariat`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`alaya`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`alchemix`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`aleo`✓✗✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`alephium`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`alephzero`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`algorai`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`algorand`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`aliagents`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`alienbase`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`alienx`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`alkimi`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`alkimiya`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`allbridge`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`allstake`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`allunity`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`alongside`✗✗✗✗✗✗✓✓✗✗✗✓✓✓✗✗✓✓
`alpha`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`alphaarcade`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`alphafi`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`alphapartners`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`alphaq`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✓✓
`ambient`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`amnisfinance`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`ampedfinance`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`anchoragedigital`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`anchored`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`anchoredcoins`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ancient8`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`angle`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`anime`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✗✗✗✗
`ankr`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓
`anome`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`anzen`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`anzens`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`apacx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`apechain`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✗✗✗✗
`apeiron`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`apepro`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`apertum`✓✓✓✓✗✓✗✗✓✗✗✓✗✗✗✗✗✗
`aperture`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`apeswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`apex`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`api3`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`apollo`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`apollox`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`aptinfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`aptos`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`aptoswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`apyx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`aquarius`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`aragon`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`arbitrum`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`arbitrumnova`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`arcadegalaxy`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`archax`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`archblock`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`archerhunter`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`arcus`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`argent`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`ariesmarkets`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`arkenfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`arkham`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`arrakis`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`arrowmarkets`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`artery`✗✗✗✗✗✗✗✗✓✗✗✓✗✗✗✗✗✗
`arweave`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`aryze`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`asagold`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`aspect`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`asseto`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`astar`✗✗✗✗✓✗✓✓✓✓✓✓✓✓✓✓✗✗
`astarzkevm`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`aster`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`astera`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`astrokarts`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`astroport`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`atrium`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`audx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`aurafinance`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`aurora`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`aurus`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`australiandigitaldollar`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`auxite`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`avalanche`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`avalonfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`avantis`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`avantprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`aventus`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`avnu`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`axelar`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`axie`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`axiom`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`axiomtrade`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`azeroid`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`azuro`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓
`b3`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`babylon`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`babysharkuniverse`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`backed`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`backpack`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`badgerdao`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`baki`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`balancer`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`bananagun`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`bancor`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`bandprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bankr`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✗✗✓✓
`barnbridge`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`baryon`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bas`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`base`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✗✗
`baseline`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`basepaint`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`baseswap`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`bbbfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bedrock`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`beefy`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`beethoven`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`beezie`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`benddao`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`benqi`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`benqilsd`✗✗✗✗✗✗✓✗✓✓✓✗✗✗✗✗✗✗
`beraborrow`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`berachain`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`betswirl`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`bex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`biconomy`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`bifrostio`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`bikemaster`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bilira`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`binance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bisonfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`biswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`bitbank`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bitbat`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`bitbond`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bitcoin`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`bitcoincash`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`bitdao`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`bitfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bitfinex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bitflow`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bitgo`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bitmex`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`bitso`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bitte`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`bittensor`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`bittopia`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bitwise`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`blackbird`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`blackhole`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`blackmirror`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`blackpanther`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`blackrock`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bladeswap`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`blast`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`blendfinance`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`blitz`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`blobarena`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`blockchaincapital`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`blocto`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bloomtradingbot`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`blox`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bloxroute`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`bluefin`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`blur`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`bmx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`bnsol`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`bob`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✗✗
`bobanetwork`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`bodegacardano`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`bombpixel`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bonkbot`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`bonzofinance`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`boomland`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`boredtopia`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`botto`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`bouncebit`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`bouncefinance`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`boundless`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`bprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`bralexyz`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`brave`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`braza`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`brickken`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`bridge`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bridgers`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bridgetower`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`briq`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`brladigital`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bsc`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`bsxexchange`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`bucket`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`bufferfinance`✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓
`buildonbeam`✓✓✓✓✓✓✗✗✓✗✗✓✗✗✓✓✗✗
`bullbit`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bullshot`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`bullx`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`burrow`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`buzzkill`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`byreal`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✓✓
`calyx`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✓✓
`camelot`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`candydreams`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`canonic`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`canopy`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cantonnetwork`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`cap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`capapp`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`capyvsmonsters`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`carbon`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cardano`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`cartridge`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`carv`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`catalyst`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`cattown`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`cbeth`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`celernetwork`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`celestia`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`celestialflutters`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cellana`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`celo`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`celodollar`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`centrifuge`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`cerra`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cetus`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`cfxlabs`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`chainflip`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`chaingpt`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`chainlink`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`charli3`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`chateau`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cherrylend`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`chiliz`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`chingari`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`choicexchange`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`chronicle`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`circle`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✗✗
`circleofgames`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`citycoins`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`claritycardano`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`clave`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`clipper`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`clique`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`clober`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`cod3x`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`coin98`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`coinally`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`coinbase`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`coincheck`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`coinshift`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`colbfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`colony`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`common`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`compound`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`comtech`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`conflux`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`connext`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`convexfinance`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`coredao`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`coreum`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`cosimo`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cosmos`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`coti`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`cowswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`credible`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`creditagricole`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`credix`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`cronos`✓✓✓✓✗✓✓✓✓✗✗✓✗✗✓✓✗✗
`cronoszkevm`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`cropto`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`crown`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`crustnetwork`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`cryptex`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`cryptocom`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cryptokitties`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`csigma`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cswap`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`current`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`curvance`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`curve`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`cuteisland`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`cygnusfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`czodiac`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`daemons`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dagora`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`danofinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`darkshuffle`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`darwinia`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`davincigraph`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`davosprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dawnshard`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`debridge`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓
`decentralgames`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`decibel`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dedust`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`deepbook`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`defi`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`deficarrot`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`defifranc`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`defimoney`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`definitive`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`defisaver`✗✗✗✗✗✗✓✓✗✗✗✓✓✓✓✓✓✓
`defusion`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`degate`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`degen`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`deltadefi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`deltatrade`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`demether`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`deriprotocol`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`derivio`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`deso`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`deuro`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`dexalot`✓✓✓✓✓✓✗✗✓✗✗✓✗✗✓✓✗✗
`dexhunter`✓✗✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dexscreener`✗✗✗✗✗✗✓✓✗✗✗✗✗✗✗✗✗✗
`dfk`✓✓✓✓✓✓✗✗✓✗✗✓✗✗✗✗✗✗
`dflow`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`dforce`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`dfx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`dgld`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dhedge`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`dia`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`diamondstandard`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`digift`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`digishare`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dimo`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`dinari`✗✗✗✗✗✗✓✓✓✗✗✓✓✓✓✓✓✓
`dinero`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`divediary`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dmail`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`dodo`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`dogecoin`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`dojoswap`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`dolomite`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`donkeyhunt`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dopewars`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dopex`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`doublezero`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`dovu`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dragoninja`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dragonland`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dragonslither`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dragonswap`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`dreamcash`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`driftprotocol`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✓✓✓✓
`driptrade`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dtrinity`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`dydx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`dymension`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`dyorswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`dypius`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`ebisu`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`echelon`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`echelonmarket`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`echoprotocol`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`eclipse`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`econia`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`ecoportal`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ecosmoarena`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`edelfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`edelweis`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`edgex`✓✓✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗
`edubuk`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`efihub`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`eggsfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`eigenlayer`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`eigenpie`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`ekubo`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`eldrem`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`element`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`elixir`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`ellipsis`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`elrond`✓✓✓✓✗✓✓✓✓✗✗✓✗✗✓✓✗✗
`ember`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`emojicoin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`empireofsei`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`encoins`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`endurfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`energyweb`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`ens`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓
`entropyio`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`enzyme`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`eos`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`equalizer`✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓
`eragon`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`eternals`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`ethena`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`ethereum`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`ethereumattestationservice`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`etherex`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`etherfi`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`etherfuse`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`etherlink`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`ethervista`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`ethgas`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`euler`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`europefantasyleague`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`everyworld`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`evmos`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`exactly`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`extended`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`extra`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`eywa`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`fableborne`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`falconfinance`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`fancraze`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`fantasy`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`fantom`✓✓✓✓✗✓✓✓✗✗✗✗✗✗✓✓✗✗
`fashionimpress`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`fathom`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`fd121limited`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`felix`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`fenix`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`fibrous`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`fidelity`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`filamentfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`filda`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`filecoin`✓✓✓✓✗✓✓✓✗✗✗✗✗✗✓✓✗✗
`findxyz`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`fireblocks`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`fishwar`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`fixesworld`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`flare`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`flashbots`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✓✓✗✗
`floatprotocol`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`flock`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`floki`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`flow`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`flowswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`flowty`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`flowxfinance`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`fluidtokens`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`flunks`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`flux`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`fluxbeam`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`fluxtra`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`flyingtulip`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`fmsbytrivolve`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`folksfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`fomo`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`forgottenruniverse`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`forta`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`fortetechsolutions`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`foundation`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`fourmeme`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`foxy`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`fragmetric`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`frankencoin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`franklintempleton`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`frax`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`fraxlend`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✓✓
`fraxstablecoin`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`fraxtal`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✗✗
`frenpet`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`frequency`✗✗✗✗✓✗✗✗✓✓✓✓✓✓✓✓✗✗
`friendtech`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`fuelnetwork`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`fuseon`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`fuul`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`fxdao`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`fxprotocol`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`gaib`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`galactica`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✗✗
`galaxydigital`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`galxe`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gamefantasy`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`gamic`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`gammastrategies`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`ganapayment`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gard`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gardenfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`gasyard`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gata`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`gateio`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`gauntlet`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gearbox`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`gelatonetwork`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gemini`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`geniusyield`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`geodnet`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`getgems`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`ggcwestlandarena`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gitcoin`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`globaldollarnetwork`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`globiance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`glodollar`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`glue`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`gluex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`gmgn`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`gmotrust`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gmx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`gnosis`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`goatprotocol`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`goblin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`goldfinch`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`goldfishgold`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gooddollar`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`goonfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`goplausible`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`gram`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`granite`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`grass`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`gravita`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`gravityalpha`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`groma`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`grove`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✗✗✓✓
`growth`✗✗✗✗✗✗✗✗✓✗✗✓✗✗✗✗✗✗
`grvt`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`guildofguardians`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`gunstar`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`gunz`✓✓✓✓✓✓✗✗✓✗✗✓✗✗✗✗✗✗
`gyroscope`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`hamiltonlane`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hapiid`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`harmony`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`hashflow`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`hashport`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hashstack`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hastra`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hedera`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`hedgeyfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`hegic`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`heliopay`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`helium`✓✓✓✓✗✓✓✓✗✗✗✓✓✓✓✓✓✓
`heliumwars`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`helix`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`hemilabs`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`hercules`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`hermetica`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hinkalprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`hippolabs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`hivello`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`hivemapper`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`hliquity`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hmx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`holdstation`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`homecoin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`honeypop`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`hook`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`hookedprotocol`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`hop`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`hotgame`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hotspring`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`houdiniswap`✓✓✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗
`htxdao`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✗✗
`humafinance`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`humanity`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✗✗
`humbledefi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`humidifi`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`hunnyfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`huobi`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`hybrafinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hychain`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`hydradx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`hydroprotocol`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`hyena`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`hylo`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`hyperbeat`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hyperbloom`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hyperbrick`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hyperbridge`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`hyperflow`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hyperion`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`hyperlane`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`hyperlend`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`hyperliquid`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`hyperpie`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`hyperstable`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`hyperswap`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`hyperwave`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`hypr`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`hypurrfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`icecreamswap`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ichi`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`idex`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✗✗✓✓
`idle`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`idleglory`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`iexecrlc`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`illuvium`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`immortalx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`immutable`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`impermax`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`impossible`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`impossibledash`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`incrementfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`indexcoop`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`indigo`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`infinex`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`infinifi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`infinityheroes`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`influence`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`influx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`infrared`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`initia`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`injective`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`injera`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ink`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✗✗
`inkyswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`instadapp`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`integral`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`intercroneswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✗
`interestlabs`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`interestprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`interlay`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✓✓✗✗
`internetcomputer`✓✓✓✓✗✓✓✓✗✗✗✗✗✗✓✓✗✗
`invarch`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✗✗
`inversefinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`ionet`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`ionex`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`ionic`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`ionprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`iota`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`iotex`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`iotube`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`ipmb`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`ipor`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`ironbank`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`izumi`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`jediswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`jito`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓
`jojo`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`jokersofneon`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`joulefinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`jpgstore`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`jpmorgan`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`jpycoin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`juicefinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`jumboexchange`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`jupiter`✓✓✓✓✗✓✓✓✗✗✗✓✓✓✓✓✓✓
`justlend`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✗✗
`justoken`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`juststable`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✗
`k3capital`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`kadena`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`kagefinance`✓✗✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`kaia`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`kaiching`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`kaio`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`kaito`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`kalshi`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`kamino`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`kanalabs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`kapitaldao`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`karak`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`karpatkey`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`karura`✓✓✓✓✗✓✓✓✗✗✗✗✗✗✓✓✗✗
`kaspa`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`katana`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`katananetwork`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`kawaiipuzzle`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`kazargames`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`kelpdao`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`kerneldao`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`kgen`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`kiln`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`kiloex`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`kilt`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`kindred`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`kine`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`kinesis`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`kinetic`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`kinetiq`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓
`kinka`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`kinto`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`kismet`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`kite`✓✓✓✓✓✓✗✗✓✗✗✓✗✗✗✗✗✗
`kittypunch`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✗✓
`kkr`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`kleros`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`klimadao`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`kodiak`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`koifinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`kpk`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`kraken`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`kroma`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`kusama`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`kwenta`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`kyber`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`kyros`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`lagoon`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`lagrange`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`lamina1`✓✓✓✓✓✓✗✗✓✗✗✓✗✗✗✗✗✗
`laqiraprotocol`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`lavanetwork`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`layer3`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`layerswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`layerzero`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`learnnearclub`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`lendingpond`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`lenfi`✓✓✗✓✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`lens`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`levana`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`levelfinance`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`levelprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`libeara`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`librecapital`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`lido`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`lifi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`lifinity`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`lighter`✓✓✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗
`likwid`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✗✓
`limitless`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`linea`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`linearprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`liqi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`liquidcollective`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓
`liquidswap`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`liquity`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`liqwid`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`lisk`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`listadao`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`litecoin`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`litentry`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`lithos`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`liveart`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`livenation`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`livepeer`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`logx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`lombard`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`looksrare`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`loopfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`loopring`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`lootsurvivor`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`lotusdex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`loxodrome`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`lucid`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`luckysea`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`lukso`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`lumia`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`lybra`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✓✓✓✓
`lynex`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`lynx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`maestro`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`magiceden`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`magmafinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`magnifycash`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`magpiexyz`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`mai`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`maiar`✓✓✓✓✗✓✓✓✗✗✗✗✗✗✗✗✗✗
`maigaai`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`mainstreet`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`makerdao`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`mamo`✓✓✓✓✓✓✗✓✓✓✓✓✓✓✗✗✓✓
`manifoldxyz`✗✗✗✗✗✗✓✓✗✗✗✓✓✓✓✓✓✓
`mansafinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`manta`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`mantle`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`mantra`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`mantrausd`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`maple`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`marginfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`marinade`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓
`mars`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`masumi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`matchfighters`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`matrixdock`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mattel`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`maverick`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`mayan`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`meanfinance`✗✗✗✗✗✗✓✓✗✗✗✓✓✓✓✓✓✓
`megaeth`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`meld`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`mellowprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`membranefinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`mendi`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`mento`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`mentolabs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mercadobitcoin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mereo`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`meridian`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`meridianmoney`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`merkletrade`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓
`merkly`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`merlinchain`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`mesh`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`mesofinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`messina`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`metaarena`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`metadao`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`metal`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`metamask`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓
`metaplex`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`metapool`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`metavault`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`metawealth`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`meteora`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✗✗✓✓
`meteorwallet`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`meteraprotocol`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`metis`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✓✓✗✗
`metric`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`metronome`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`metropolisexchange`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`mezo`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`mfl`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`micro3`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`midas`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`midnight`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`mimic`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mimo`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`mimocapital`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mina`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`minswap`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`mintblockchain`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`mintclub`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mitofi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mnee`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mode`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✓✓✗✗
`moet`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mokokogame`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mole`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`monad`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✗✗✗✗
`monerium`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`monero`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`moneta`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`moneyonchain`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`monolithmarket`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mooar`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`moola`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`moonbeam`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`moonshot`✗✗✗✗✗✗✓✓✗✗✗✗✗✗✗✗✗✗
`moonwell`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`more`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`morpho`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`mosaic`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`mountainprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`movement`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`movemovefish`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`movenow`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`moveposition`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`movequest`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`mtgox`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`mudigital`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`muesliswap`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`multipli`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mummy`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`mux`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`myshell`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`myswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mythfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`mythos`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`myxfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`mzero`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`nado`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`nanidao`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`naorisprotocol`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`native`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`nativemarkets`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`navi`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`navigator`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`nbatopshot`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`near`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`nearlend`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`neptunefinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`nereusfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`nest`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`nestexchange`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`nethermind`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`netnet`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`neuroweb`✓✓✗✓✓✗✓✓✓✓✓✓✓✓✗✗✗✗
`neutrl`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`neverland`✗✗✗✗✓✗✗✗✗✗✗✗✗✗✓✓✗✗
`newfestivaltown`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`newrails`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`newtonprotocol`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`nexpace`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`nexusmutual`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`nexusportal`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`nftperp`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`nftx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`nibiru`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`nileexchange`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`nillion`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`ninjablaze`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ninjavault`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`nitromachines`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`noble`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`nodle`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✗✗
`noon`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`nostra`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`notional`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`nounsdao`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`noxa`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`nucleus`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`numeraire`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`nums`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`nuri`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`nyala`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`o1exchange`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`ocean`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`octopusnetwork`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`odos`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`odyssey`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`officialtrump`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`okutrade`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`okx`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`omnibtc`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`ondo`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`oneid`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`onre`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`onyx`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`oogabooga`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`oomer`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`openbook`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`openchat`✓✗✓✓✗✓✓✓✓✓✓✗✗✗✓✓✗✗
`openedendigital`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`openleverage`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`openocean`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`openpad`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`opensea`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`openstock`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`opentrade`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`operationsafeplacedefense`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`opinion`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`optfun`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`optimfi`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`optimism`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`optopia`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`opus`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`opyn`✗✗✗✗✓✗✓✓✓✓✓✓✓✓✓✓✓✓
`orbiter`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`orbs`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`orca`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓
`orcfax`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`orderlynetwork`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`oreprotocol`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`origamifinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`origin`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`osl`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`osmosis`✓✓✓✓✗✓✓✓✓✗✗✓✗✗✓✓✗✗
`ostiumlabs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`out`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`overnight`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`overtake`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`pacfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pactfoundation`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`paintswap`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`palmusd`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pancakeswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`pangolin`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`panora`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`paradex`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`paradisetycoon`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`paragonperps`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✓✓✗✗
`paragonsdao`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`parallelfinance`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`paraswap`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`pareto`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`particle`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`particlenetwork`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`paxos`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`paypal`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`paytrie`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pbg`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`peaq`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`pendle`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`pendulum`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`penpie`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`pepe`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`perena`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`perpetualprotocol`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`phala`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`phantom`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`pharaoh`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`phoenix`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`phoenixbonds`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`phoenixhub`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`photon`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`pichifinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`pikaprotocol`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`piku`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pinto`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`piratopia`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pistolsatdawn`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pixels`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`pixudi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`planetix`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`plasma`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`playember`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pleasinggold`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`plugin`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`plumenetwork`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`pocketnetwork`✓✓✓✓✗✓✓✓✗✗✗✗✗✗✓✓✗✗
`podsmedia`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`polimec`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`polkadex`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`polkadot`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`polter`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`polygon`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`polygonzkevm`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`polymarket`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`polynomial`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`pooltogether`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`poppie`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`portal`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`potatoswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pragma`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`prdt`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`predictex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`predictfun`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`predpred`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`premia`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`primenumbers`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`primexfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`prismafinance`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓
`privy`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`projectx`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✓✓
`proofofplay`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`protos`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`provablegames`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`provenanceblockchain`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`pufferfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`pumex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`pumpbtc`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`pumpflow`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`pumpfun`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✗✗✓✓
`pyth`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`qchain`✓✗✓✓✗✓✗✗✓✗✗✓✗✗✗✗✗✗
`quainetwork`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`quantoz`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`qubic`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`questn`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`quickswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`quillfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`quizmatch`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`raac`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`rabbithole`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`rabbitswap`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`rabbitx`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`rabby`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`radiant`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`raft`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`ragafinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`raiinmaker`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`railgun`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`rainbow`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`rainfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`ramses`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`rarible`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`rarichain`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`ratex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`raybot`✗✗✗✗✗✗✓✓✗✗✗✗✗✗✗✗✗✗
`raydium`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✓✓
`razor`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`re`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`reactorfusion`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`readygamesnetwork`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`real`✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`reality`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`realms`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`realt`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`realtyx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`rebalance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`redbellynetwork`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`redstone`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`redstonechain`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`redswan`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`reental`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`reffinance`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`reflector`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`reflexer`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`relayprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ren`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`rendernetwork`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`renzo`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`republicnote`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`researchhub`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`reserve`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`reservoir`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`reservoirxyz`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`resolv`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`resupply`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`retipooling`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`revert`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`revolut`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`revox`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`reya`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`rezerve`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`rgbclash`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`rheafinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`rhinofi`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`rhoprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ribbon`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`ribdigital`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`rif`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ringprotocol`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`ringsprotocol`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`ripio`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ripple`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`ripplelabs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`riselabs`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`river`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`robinhood`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✗✗
`robonomics`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`robotsfarm`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`rocketpool`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓
`ronin`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`rootstock`✗✗✗✗✓✗✓✓✓✓✓✓✓✓✓✓✗✗
`router`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`routex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`rubic`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`runehero`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sacra`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`sacredtails`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`safe`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`sailor`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sakaivault`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`sakuranexus`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sanctum`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`sandclock`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`sanko`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`saros`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`satlayer`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`satori`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`saturn`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`saturnswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`saucerswap`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`savagesummit`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sbishinseitrust`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`scallop`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`schumanfinancial`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`scienceblockchain`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`scroll`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`seamlessprotocol`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`secret`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`securitize`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`seiballer`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`seibound`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`seinetwork`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`seiyara`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sellix`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✗
`send`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`sendingme`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`sentora`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sequence`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`seraph`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`settlus`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗
`shadowexchange`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`shadowmysteries`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`shape`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✗✗✗✗
`shapeshift`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`shoebill`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`shrapnel`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`shuffle`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`sideshift`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`sigmabot`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`silo`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`silverswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`singsing`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`siriofinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sivo`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`skalenetwork`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`skipprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`slimerevolution`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`slingshot`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`smardex`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`snowcrash`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`societegenerale`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`socket`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sofamon`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sofi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`solana`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`solayer`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`solend`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`solidlizard`✓✓✗✓✓✗✓✓✓✓✓✓✓✓✗✗✓✓
`sologenic`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`solomonlabs`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`solosurvivor`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`solstice`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`soltradingbot`✓✓✗✓✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`solv`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`somnia`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`soneium`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✗✗
`sonic`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`sonicmarket`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`sonicxfun`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sonicxswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sophon`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`sorare`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`soroswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`soulpeg`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sound`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`spaace`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`spaceandtime`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`spacebar`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`spaceid`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`spark`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`sparkle`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`spectra`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`sperax`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`spicevc`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`spiko`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`spin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`spincity`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`splash`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`spookyswap`✓✓✓✓✓✓✓✓✗✓✓✓✓✓✓✓✓✓
`spotprotocol`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`squid`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`ssvnetwork`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`st0x`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`stabble`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`stability`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`stable`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`stablecoin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`stableslabs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`stablestock`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`stablr`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`stackingdao`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`stacks`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`stader`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`stafi`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✓✓✓✓
`stake`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`stakedao`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`stakestone`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓
`stakewise`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`standx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`staratlas`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`starbase`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`stargate`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`starknet`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`starly`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`starrynift`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`starsarena`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`starship`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`starsymphony`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`stasis`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`steakhousefinancial`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`stellar`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`stepn`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`stonfi`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`storj`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`storx`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`story`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✗✗
`straitsx`✗✗✗✗✗✗✗✗✓✗✗✓✓✓✗✗✓✓
`strata`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`stream`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`streamex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`streamr`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`stride`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`strikecardano`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`strkfarm`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`stronghold`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`stryke`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`stusdt`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`subsocial`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✓✓✗✗
`succinctlabs`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`sudoswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`sugarsenpai`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sui`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`suilend`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`suimine`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`suimint`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`summerfi`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`sun`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✗✗
`sundaeswap`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`sunpump`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✗
`sunswap`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗
`superchamps`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`superformlabs`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`supernova`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`superposition`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`superprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`superseed`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✗✗✗✗
`superstate`✗✗✗✗✗✗✓✓✗✗✗✓✓✓✓✓✓✓
`superswapink`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`surfcardano`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`sushiswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`swapx`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`swapxsonic`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`swarm`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`swarmmarkets`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`sweatcoin`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`swell`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✓✓
`switchboard`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`sx`✗✗✗✗✓✗✓✓✓✗✗✗✗✗✓✓✗✗
`sygnum`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`symbiosis`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`symbiotic`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`synapse`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`syncswap`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`syndicate`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`synfutures`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`synonymfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`synthetix`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`synthswap`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`taiko`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✓✓✗✗
`takaralend`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`talentprotocol`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`talisprotocol`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`tangent`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tangible`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`tapiocadao`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`tapos`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`taraxa`✗✗✗✗✓✗✗✗✗✗✗✗✗✗✗✗✗✗
`taulabs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`teafi`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`teahouse`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`teddyswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`telcoin`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`tellor`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`templarprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`temple`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`tempo`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✗✗
`tenbinlabs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tensor`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`termfinance`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`termmax`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`termstructure`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`terra`✓✓✓✓✓✓✓✓✗✗✗✗✗✗✓✓✗✗
`tesserav`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tether`✗✗✗✗✗✗✓✓✗✗✗✓✓✓✗✗✓✓
`tevi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`textilecredit`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tezos`✓✓✓✓✗✓✓✓✗✗✗✗✗✗✓✓✗✗
`thalalabs`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`thales`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`thegraph`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`thelostglitches`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`thena`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`theo`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`thesandbox`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`thestandardprotocol`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`thetanrivals`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`thetanuts`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`thetismarket`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`thorchain`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`threshold`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`thruster`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`tibles`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ticketmaster`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`timefun`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tinyman`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`titanl1`✗✗✗✗✗✗✗✗✓✗✗✓✗✗✗✗✗✗
`tixchain`✗✗✗✗✗✗✗✗✓✗✗✓✗✗✗✗✗✗
`tokemak`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✓✓✓✓
`token`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tokengate`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tokenisedgbp`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tokenlon`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`tokentails`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tokeny`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`tomatochain`✗✗✗✗✗✗✗✗✓✗✗✓✗✗✗✗✗✗
`ton`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`torifinance`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`tornadocash`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`torodex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`toucan`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`tradable`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`tradeport`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`traderjoe`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`tradexyz`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✗✗✗✗
`transfero`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`treehousefinance`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`triad`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`trize`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`trojan`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`tron`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`tronusdd`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`truefi`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`truemarkets`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`trufin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`trustaai`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`trustwallet`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`turbosfinance`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`turingchain`✗✗✗✗✗✗✗✗✓✗✗✓✗✗✗✗✗✗
`turtleclub`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`tydro`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`typusfnance`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`ubeswap`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`ubs`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ufc`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`uiic`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`uma`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`unidex`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`unipilot`✗✗✗✗✓✗✓✓✓✓✓✓✓✓✓✓✓✓
`uniquenetwork`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`uniswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`uniswaplabs`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`unitas`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`unitedstables`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`unityusd`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`universalprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`unsheth`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`upheaval`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`uprock`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`upshiftfinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`uptn`✗✗✗✗✗✗✗✗✓✗✗✓✗✗✗✗✗✗
`usdai`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`usdkg`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`usdm1`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`usdufinance`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`usual`✓✓✓✓✓✓✓✓✗✗✗✓✓✓✗✗✓✓
`uwon`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`uxlink`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`uxuy`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`valeriagames`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`valuex`✗✗✗✗✗✗✗✗✓✗✗✓✗✗✗✗✗✗
`vana`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`vaneck`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`variational`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`vaultka`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`vaultopolis`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`veax`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✓✓✗✗
`vechain`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`veda`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`veilcraft`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`velar`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`velodrome`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`venice`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`ventuals`✗✗✗✗✗✗✓✓✓✓✓✗✗✗✓✓✗✗
`venus`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`versedex`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`vertex`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`vesta`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`vesuxyz`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`vfat`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`vibrantx`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`viction`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✗✗✗✗
`virtualsprotocol`✓✓✓✓✗✓✓✓✗✗✗✓✓✓✗✗✓✓
`vitalveda`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`vnx`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`volmex`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`volo`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`voltprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`voltz`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`vvs`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`vyfi`✓✓✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`wagmi`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`walletconnect`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`walrus`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`wapal`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`wasabi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`wayup`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`wcoin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✓
`wcoingame`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`web3go`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`webkeydao`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`well3`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`wheeester`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`whiffin`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`whiteswap`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✗✗
`whitewhale`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`wigoswap`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`wildforest`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`wildwestshooting`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`wingriders`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`winr`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`wisdomtree`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`witnet`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`wombat`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`woo`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`worldchain`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✗✗
`worldcoin`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✗✗
`worldlibertyfinancial`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`worldmarkets`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`worldmobilechain`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✗✗
`worldofdypians`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`wormhole`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✓✓✓✓
`wspn`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`wyoming`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`x2y2`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`xai`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`xcad`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`xdc`✓✓✓✓✗✓✓✓✓✓✓✓✓✓✓✓✗✗
`xdcdomains`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`xgamble`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`xninjatech`✓✗✗✓✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`xoxno`✓✓✓✓✗✓✓✓✓✗✗✗✗✗✓✓✗✗
`xpin`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`xpla`✓✓✓✓✗✓✗✗✓✗✗✓✗✗✓✓✗✗
`xpress`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`xstocks`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`xswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`xsy`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`xy`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`yakafinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`yala`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`yamatoprotocol`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`yamfore`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`yearnfinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`yeet`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`yeifinance`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`yeti`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`ygg`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✗✗✓✓
`yieldfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`yieldnest`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`yieldoptimizer`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`yologames`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`yuzu`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`yuzumoney`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`zama`✗✗✗✗✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`zcash`✓✓✓✓✗✓✓✓✗✗✗✗✗✗✓✓✗✗
`zeedz`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`zeitgeist`✓✓✓✓✓✓✗✗✓✓✓✓✓✓✓✓✗✗
`zerion`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✓✓✓✓
`zerobase`✓✓✓✓✗✓✗✗✗✗✗✓✓✓✗✗✓✓
`zerofi`✗✗✗✗✗✗✗✗✓✓✓✓✓✓✗✗✓✓
`zerolend`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓
`zest`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`zeta`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✗✗✗✗
`zetachain`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`zircuit`✓✓✓✓✓✓✗✗✗✗✗✗✗✗✗✗✗✗
`zkcandy`✗✗✗✗✓✗✗✗✗✗✗✗✗✗✓✓✗✗
`zkdx`✓✗✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`zkex`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`zkfair`✓✓✓✓✗✓✗✗✗✗✗✗✗✗✓✓✗✗
`zklend`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`zkme`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✓✓✓✓
`zkswap`✓✓✓✓✗✓✗✗✓✓✓✓✓✓✓✓✓✓
`zksyncera`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`zksyncerabridge`✗✗✗✗✗✗✓✓✓✓✓✓✓✓✗✗✓✓
`zksynclite`✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗✗
`zkube`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`zkx`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✓✓✓✓
`zns`✓✓✗✓✓✗✗✗✗✗✗✓✓✓✗✗✓✓
`znsconnectnameservice`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`zombiesofarcadia`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`zoomswap`✓✓✓✓✓✓✗✗✗✗✗✓✓✓✓✓✓✓
`zora`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗
`zunami`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
`zyberswap`✓✓✓✓✓✓✓✓✓✓✓✓✓✓✗✗✓✓
`zyfi`✗✗✗✗✗✗✗✗✗✗✗✓✓✓✗✗✓✓
**Project × chain** A project's figures split by the chain they were earned on, such as `uniswap` on `base`. One row per project and chain per day.
Project TVL Outstanding supply Fees Supply-side fees Revenue Token incentives Daily active users Weekly active users Monthly active users
`0x`✗✗✓✓✓✓✓✓✓
`1inch`✗✗✓✓✓✓✓✓✓
`3adao`✗✓✗✗✗✗✗✗✗
`aave`✓✓✓✓✓✓✓✓✓
`abracadabra`✓✗✓✗✓✓✓✓✓
`abstract`✗✗✗✗✗✗✗✗✗
`acala`✓✗✓✓✓✗✓✓✓
`across`✓✗✓✓✓✓✓✓✓
`aerodrome`✓✗✓✓✓✓✓✓✓
`aethir`✗✗✓✓✓✓✗✗✗
`aevo`✗✗✗✗✗✗✗✗✗
`agant`✗✓✗✗✗✗✗✗✗
`agora`✓✓✗✗✗✗✗✗✗
`airswap`✗✗✓✓✓✓✓✓✓
`ajuna`✗✗✓✓✓✗✓✓✓
`alchemix`✗✓✗✗✗✗✗✗✗
`alephzero`✗✗✓✓✓✗✗✓✓
`algorand`✗✗✓✓✓✓✓✓✓
`alienx`✗✗✗✗✗✗✗✗✗
`allbridge`✗✗✓✓✓✓✓✓✓
`allunity`✗✓✗✗✗✗✗✗✗
`alongside`✓✗✓✗✓✓✗✗✗
`alphapartners`✗✓✗✗✗✗✗✗✗
`alphaq`✗✗✗✗✗✗✓✓✓
`anchoragedigital`✗✓✗✗✗✗✗✗✗
`anchoredcoins`✗✓✗✗✗✗✗✗✗
`ancient8`✗✗✗✗✗✗✗✗✗
`angle`✓✓✓✗✓✓✗✗✗
`anime`✗✗✗✗✗✗✓✓✓
`ankr`✓✗✗✗✗✗✓✓✓
`anzen`✓✓✗✗✗✗✗✗✗
`anzens`✗✓✗✗✗✗✗✗✗
`apacx`✗✓✗✗✗✗✗✗✗
`apechain`✗✗✗✗✗✗✓✓✓
`apertum`✗✗✗✗✗✗✓✗✗
`aperture`✓✗✓✓✓✓✓✓✓
`apeswap`✓✗✓✓✓✓✓✓✓
`apex`✗✗✗✗✗✗✗✗✗
`apollo`✓✗✗✗✗✗✗✗✗
`apollox`✓✗✓✓✓✓✓✓✓
`aptos`✗✗✓✓✓✓✓✓✓
`apyx`✗✓✗✗✗✗✗✗✗
`aragon`✗✗✓✗✓✓✗✗✗
`arbitrum`✗✗✓✓✓✓✓✓✓
`arbitrumnova`✗✗✗✗✗✗✗✗✗
`archblock`✓✓✗✗✗✗✗✗✗
`arcus`✓✓✗✗✗✗✗✗✗
`artery`✗✗✗✗✗✗✓✗✗
`aryze`✗✓✗✗✗✗✗✗✗
`astar`✓✗✓✓✓✓✓✓✓
`aster`✗✓✗✗✗✗✗✗✗
`astera`✗✓✗✗✗✗✗✗✗
`audx`✗✓✗✗✗✗✗✗✗
`aurafinance`✗✗✓✓✓✓✓✓✓
`australiandigitaldollar`✗✓✗✗✗✗✗✗✗
`avalanche`✗✗✓✓✓✗✓✓✓
`avantprotocol`✓✓✗✗✗✗✗✗✗
`aventus`✗✗✓✗✓✓✓✓✓
`axelar`✓✗✓✓✓✗✓✓✓
`axie`✗✗✓✓✓✗✗✗✗
`axiomtrade`✗✗✓✓✓✗✓✓✓
`azuro`✗✗✗✗✗✗✓✓✓
`b3`✗✗✗✗✗✗✗✗✗
`balancer`✓✗✓✓✓✓✓✓✓
`bancor`✓✗✓✓✓✓✓✓✓
`bankr`✗✗✓✓✓✗✓✓✓
`base`✗✗✓✓✓✓✓✓✓
`beethoven`✓✗✓✓✓✓✓✓✓
`benddao`✗✗✓✓✓✓✓✓✓
`benqi`✗✗✓✓✓✓✓✓✓
`benqilsd`✓✗✓✗✗✗✓✓✓
`berachain`✗✓✓✓✓✗✓✓✓
`betswirl`✗✗✓✓✓✓✓✓✓
`bifrostio`✓✗✓✓✓✓✓✓✓
`bilira`✗✓✗✗✗✗✗✗✗
`binance`✗✓✗✗✗✗✗✗✗
`bisonfi`✗✗✗✗✗✗✗✗✗
`biswap`✗✗✓✓✓✗✓✓✓
`bitcoin`✗✗✓✓✓✓✓✓✓
`bitgo`✓✗✗✗✗✗✗✗✗
`bitso`✗✓✗✗✗✗✗✗✗
`bitwise`✗✗✗✗✗✗✗✗✗
`blackhole`✓✗✗✗✗✗✗✗✗
`blackrock`✓✗✗✗✗✗✗✗✗
`blast`✗✗✓✓✓✓✓✓✓
`blockchaincapital`✓✗✗✗✗✗✗✗✗
`bloomtradingbot`✗✗✓✓✓✗✓✓✓
`blox`✗✓✗✗✗✗✗✗✗
`bloxroute`✗✗✓✓✓✗✓✓✓
`blur`✗✗✓✓✓✓✓✓✓
`bmx`✓✗✓✓✓✓✓✓✓
`bnsol`✓✗✗✗✗✗✗✗✗
`bob`✗✗✗✗✗✗✓✓✓
`bobanetwork`✗✗✓✓✓✓✓✓✓
`bonkbot`✗✗✓✓✓✗✓✓✓
`botto`✓✗✗✗✗✗✗✗✗
`bouncefinance`✗✗✓✗✓✗✓✓✓
`braza`✗✓✗✗✗✗✗✗✗
`bridge`✗✓✗✗✗✗✗✗✗
`bsc`✗✗✓✓✓✓✓✓✓
`bucket`✗✓✗✗✗✗✗✗✗
`bufferfinance`✓✗✓✗✗✓✓✓✓
`buildonbeam`✗✗✗✗✗✗✓✗✗
`bullx`✗✗✓✓✓✗✓✓✓
`byreal`✗✗✗✗✗✗✓✓✓
`calyx`✗✗✗✗✗✗✓✓✓
`camelot`✓✗✓✓✓✓✓✓✓
`cap`✗✗✓✓✓✓✓✓✓
`capapp`✓✓✗✗✗✗✗✗✗
`cardano`✗✗✓✓✓✓✓✓✓
`cbeth`✓✗✗✗✗✗✗✗✗
`celestia`✗✗✓✓✓✓✓✓✓
`celo`✗✗✓✓✓✓✓✓✓
`centrifuge`✓✗✗✗✗✗✗✗✗
`cfxlabs`✗✓✗✗✗✗✗✗✗
`chainflip`✓✗✓✓✓✓✓✓✓
`chainlink`✗✗✓✗✓✗✓✓✓
`circle`✓✓✓✓✓✓✓✓✓
`clipper`✗✗✓✓✓✓✓✓✓
`cod3x`✗✓✗✗✗✗✗✗✗
`coinshift`✓✗✓✓✓✓✓✓✓
`compound`✓✗✓✓✓✓✓✓✓
`comtech`✓✗✗✗✗✗✗✗✗
`conflux`✗✗✓✓✓✗✓✓✓
`connext`✗✗✓✓✓✓✓✓✓
`convexfinance`✗✗✓✓✓✓✓✓✓
`cosmos`✗✗✓✓✓✓✓✓✓
`cowswap`✗✗✓✓✓✓✓✓✓
`creditagricole`✗✓✗✗✗✗✗✗✗
`cronos`✗✗✓✓✓✓✓✗✗
`crown`✗✓✗✗✗✗✗✗✗
`cryptex`✗✗✓✓✓✓✓✓✓
`curve`✓✓✓✓✓✓✓✓✓
`cygnusfinance`✗✓✗✗✗✗✗✗✗
`darwinia`✗✗✓✓✓✓✓✓✓
`debridge`✗✗✓✓✓✓✓✓✓
`decentralgames`✗✗✗✗✗✓✗✗✗
`defifranc`✗✓✗✗✗✗✗✗✗
`defisaver`✗✗✓✗✓✓✗✗✗
`degate`✗✗✗✗✗✗✗✗✗
`degen`✗✗✗✗✗✗✗✗✗
`deriprotocol`✗✗✓✓✓✓✓✓✓
`deuro`✗✓✗✗✗✗✗✗✗
`dexalot`✗✗✗✗✗✗✓✗✗
`dexscreener`✗✗✓✓✓✗✗✗✗
`dfk`✗✗✗✗✗✗✓✗✗
`dfx`✗✗✓✓✓✓✓✓✓
`dinari`✗✗✓✓✓✗✓✗✗
`dodo`✗✗✓✓✓✓✓✓✓
`dogecoin`✗✗✓✓✓✓✓✓✓
`dolomite`✓✗✓✓✓✓✓✓✓
`dopex`✓✗✓✓✓✗✓✓✓
`dreamcash`✗✗✓✓✓✗✓✓✓
`driftprotocol`✓✗✗✗✗✗✓✓✓
`dtrinity`✗✓✗✗✗✗✗✗✗
`dydx`✓✗✓✓✓✓✓✓✓
`ebisu`✗✓✗✗✗✗✗✗✗
`eclipse`✗✗✗✗✗✗✗✗✗
`edgex`✗✗✓✓✓✗✗✗✗
`eigenlayer`✓✗✓✓✓✗✓✓✓
`elixir`✓✗✗✗✗✗✗✗✗
`elrond`✗✗✓✓✓✓✓✗✗
`energyweb`✗✗✓✓✓✓✓✓✓
`ens`✗✗✗✗✗✗✓✓✓
`entropyio`✗✗✗✗✗✗✗✗✗
`equalizer`✓✗✓✓✓✗✗✓✓
`ethena`✓✓✓✓✓✗✓✓✓
`ethereum`✗✗✓✓✓✓✓✓✓
`etherex`✓✗✓✓✓✓✓✓✓
`etherfi`✓✗✓✓✓✓✓✓✓
`euler`✓✗✓✓✓✗✓✓✓
`falconfinance`✓✓✓✓✓✗✓✓✓
`fantom`✗✗✓✓✓✓✗✗✗
`fathom`✓✓✓✓✓✗✓✓✓
`fd121limited`✓✓✗✗✗✗✗✗✗
`felix`✗✓✓✓✓✗✓✓✓
`fidelity`✓✓✗✗✗✗✗✗✗
`filecoin`✗✗✓✓✓✓✗✗✗
`fireblocks`✗✓✗✗✗✗✗✗✗
`flashbots`✗✗✓✗✓✓✓✓✓
`floatprotocol`✗✓✗✗✗✗✗✗✗
`flow`✗✓✓✓✓✓✓✓✓
`flux`✓✗✗✗✗✗✗✗✗
`flyingtulip`✓✓✓✓✓✗✓✓✓
`fomo`✗✗✓✓✓✗✓✓✓
`foundation`✗✗✓✓✓✓✓✓✓
`frankencoin`✗✓✗✗✗✗✗✗✗
`franklintempleton`✓✗✗✗✗✗✗✗✗
`frax`✓✗✓✓✓✗✓✓✓
`fraxlend`✓✗✗✗✗✗✓✓✓
`fraxstablecoin`✓✓✗✗✗✗✗✗✗
`fraxtal`✗✗✓✓✓✓✓✓✓
`frequency`✗✗✗✗✗✗✓✓✓
`friendtech`✓✗✓✓✓✓✓✓✓
`fuelnetwork`✗✗✗✗✗✗✗✗✗
`fxprotocol`✗✓✗✗✗✗✗✗✗
`galactica`✗✗✗✗✗✗✓✓✓
`gammastrategies`✗✗✓✓✓✓✓✓✓
`gearbox`✗✗✓✓✓✗✓✓✓
`gemini`✓✓✗✗✗✗✗✗✗
`globaldollarnetwork`✓✗✗✗✗✗✗✗✗
`glodollar`✗✓✗✗✗✗✗✗✗
`gmgn`✗✗✓✓✓✗✓✓✓
`gmotrust`✗✓✗✗✗✗✗✗✗
`gmx`✓✗✓✓✓✓✓✓✓
`gnosis`✗✗✓✓✓✗✓✓✓
`goldfinch`✗✗✓✓✓✓✓✓✓
`goonfi`✗✗✗✗✗✗✗✗✗
`gravita`✗✓✗✗✗✗✗✗✗
`gravityalpha`✗✗✓✓✓✗✓✓✓
`grove`✓✗✓✓✓✓✗✗✗
`growth`✗✗✗✗✗✗✓✗✗
`grvt`✓✗✗✗✗✗✗✗✗
`gunz`✗✗✗✗✗✗✓✗✗
`hamiltonlane`✓✗✗✗✗✗✗✗✗
`hedera`✗✗✓✓✓✓✓✓✓
`hegic`✓✗✓✓✓✓✓✓✓
`heliopay`✗✗✓✓✓✗✓✓✓
`helium`✗✗✓✗✓✗✗✗✗
`hmx`✗✗✓✓✓✓✓✓✓
`holdstation`✓✗✓✓✓✓✓✓✓
`honeypop`✓✗✓✓✓✗✓✓✓
`hook`✗✗✗✗✗✗✗✗✗
`hop`✗✗✓✓✓✓✓✓✓
`houdiniswap`✗✗✓✗✓✓✗✗✗
`humanity`✗✗✗✗✗✗✓✓✓
`hychain`✗✗✗✗✗✗✗✗✗
`hydradx`✓✓✓✓✓✗✓✓✓
`hyena`✗✗✓✓✓✗✓✓✓
`hylo`✗✓✗✗✗✗✗✗✗
`hyperbridge`✗✗✓✓✓✓✓✓✓
`hyperlend`✓✗✓✓✓✗✓✓✓
`hyperliquid`✗✗✓✓✓✗✓✓✓
`hyperstable`✗✓✗✗✗✗✗✗✗
`hypr`✗✗✗✗✗✗✗✗✗
`idex`✗✗✓✓✓✗✗✗✗
`idle`✗✗✗✗✗✓✗✗✗
`immutable`✗✗✓✓✓✗✓✓✓
`impossible`✓✗✗✗✗✗✗✗✗
`indexcoop`✓✗✓✓✓✓✓✓✓
`indigo`✗✓✗✗✗✗✗✗✗
`infinifi`✗✓✗✗✗✗✗✗✗
`injective`✗✗✓✓✓✓✓✓✓
`ink`✗✗✓✓✓✓✓✓✓
`instadapp`✓✗✓✓✓✓✓✓✓
`integral`✗✗✓✓✓✓✗✗✗
`interlay`✗✗✗✗✗✗✓✓✓
`internetcomputer`✗✗✓✓✓✓✗✗✗
`invarch`✗✗✗✗✗✗✗✓✓
`inversefinance`✓✓✗✗✗✗✗✗✗
`iotex`✗✗✓✓✓✓✓✓✓
`ipor`✓✗✓✓✓✓✓✓✓
`ironbank`✗✓✗✗✗✗✗✗✗
`jito`✓✗✓✓✓✗✓✓✓
`jpycoin`✓✓✗✗✗✗✗✗✗
`jupiter`✓✓✓✓✓✗✗✗✗
`kalshi`✗✗✗✗✗✗✗✗✗
`kamino`✓✗✗✗✗✗✗✗✗
`kapitaldao`✗✗✓✓✓✓✗✗✗
`karak`✗✗✗✗✗✗✗✗✗
`karura`✗✗✓✓✓✗✗✗✗
`katana`✓✗✓✓✓✓✓✓✓
`katananetwork`✓✗✓✓✓✓✓✓✓
`kelpdao`✓✗✓✓✓✗✓✓✓
`kilt`✗✗✓✓✓✓✓✓✓
`kinetiq`✗✗✗✗✗✗✓✓✓
`kinto`✗✗✗✗✗✗✗✗✗
`kite`✗✗✗✗✗✗✓✗✗
`kleros`✗✗✓✓✓✓✗✗✗
`kroma`✗✗✗✗✗✗✗✗✗
`kusama`✗✗✓✓✓✓✓✓✓
`kwenta`✗✗✓✓✓✓✓✓✓
`kyber`✓✗✓✓✓✓✓✓✓
`lamina1`✗✗✗✗✗✗✓✗✗
`layer3`✗✗✓✗✓✗✓✓✓
`layerzero`✗✗✓✓✓✗✓✓✓
`lens`✗✗✓✓✓✓✓✓✓
`levelfinance`✓✗✓✓✓✓✓✓✓
`levelprotocol`✗✓✗✗✗✗✗✗✗
`lido`✓✗✓✓✓✓✓✓✓
`lighter`✓✗✓✓✓✗✗✗✗
`linea`✗✗✓✓✓✓✓✓✓
`liquidcollective`✓✗✗✗✗✗✓✓✓
`liquity`✓✓✓✓✓✓✓✓✓
`lisk`✗✗✗✗✗✗✗✗✗
`listadao`✓✓✗✗✗✗✗✗✗
`litecoin`✗✗✓✓✓✓✓✓✓
`litentry`✗✗✓✓✓✓✓✓✓
`livepeer`✗✗✓✓✓✓✗✗✗
`looksrare`✗✗✓✓✓✓✓✓✓
`loopring`✓✗✗✗✗✗✗✗✗
`lybra`✓✗✗✗✗✗✓✓✓
`maestro`✗✗✓✓✓✗✓✓✓
`maiar`✗✗✓✓✓✗✗✗✗
`mainstreet`✗✓✗✗✗✗✗✗✗
`makerdao`✓✓✓✓✓✓✓✓✓
`mamo`✓✗✗✗✓✗✓✓✓
`manifoldxyz`✗✗✓✓✓✓✗✗✗
`manta`✗✗✓✓✓✓✓✓✓
`mantle`✗✗✗✗✗✗✗✗✗
`mantra`✓✗✓✓✓✓✓✓✓
`maple`✓✗✓✓✓✓✓✓✓
`marinade`✓✗✓✓✓✗✓✓✓
`matrixdock`✓✗✗✗✗✗✗✗✗
`maverick`✓✗✓✓✓✗✓✓✓
`meanfinance`✗✗✓✓✓✓✗✗✗
`megaeth`✗✗✓✓✓✓✓✓✓
`membranefinance`✗✓✗✗✗✗✗✗✗
`mento`✗✓✗✗✗✗✗✗✗
`mentolabs`✗✓✗✗✗✗✗✗✗
`merkletrade`✓✗✓✓✓✓✓✓✓
`mesh`✗✓✗✗✗✗✗✗✗
`metal`✗✗✗✗✗✗✗✗✗
`metamask`✓✓✗✗✗✗✓✓✓
`metavault`✓✗✓✓✓✓✓✓✓
`meteora`✓✗✓✓✓✗✓✓✓
`metis`✗✗✗✗✗✗✓✓✓
`metric`✗✗✗✗✗✗✗✗✗
`metronome`✗✓✗✗✗✗✗✗✗
`midas`✓✗✗✗✗✗✗✗✗
`mimocapital`✗✓✗✗✗✗✗✗✗
`mina`✗✗✓✓✓✓✓✓✓
`mintblockchain`✗✗✗✗✗✗✗✗✗
`mnee`✗✓✗✗✗✗✗✗✗
`mode`✗✗✗✗✗✗✓✓✓
`moet`✗✓✗✗✗✗✗✗✗
`monad`✗✗✓✓✓✗✓✓✓
`monerium`✓✓✗✗✗✗✗✗✗
`moneta`✗✓✗✗✗✗✗✗✗
`moneyonchain`✗✓✗✗✗✗✗✗✗
`moonbeam`✗✗✓✓✓✓✓✓✓
`moonshot`✗✗✓✓✓✗✗✗✗
`moonwell`✓✗✓✓✓✓✓✓✓
`morpho`✓✗✓✓✓✓✓✓✓
`movement`✗✗✓✓✓✓✓✓✓
`multipli`✗✓✗✗✗✗✗✗✗
`mummy`✓✗✓✓✓✓✓✓✓
`mux`✓✗✓✓✓✓✓✓✓
`mythos`✗✗✓✓✓✓✓✓✓
`mzero`✗✓✗✗✗✗✗✗✗
`native`✓✗✓✓✓✗✓✓✓
`nativemarkets`✗✓✗✗✗✗✗✗✗
`near`✗✗✓✓✓✓✓✓✓
`neuroweb`✗✗✓✓✓✓✓✓✓
`neutrl`✗✓✗✗✗✗✗✗✗
`newrails`✗✓✗✗✗✗✗✗✗
`nexusmutual`✗✗✓✓✓✗✓✓✓
`nftx`✗✗✓✓✓✓✓✓✓
`nodle`✗✗✗✗✗✗✓✓✓
`noon`✗✓✗✗✗✗✗✗✗
`notional`✓✗✓✓✓✓✓✓✓
`noxa`✓✗✗✗✗✗✗✗✗
`o1exchange`✓✗✓✓✓✗✓✓✓
`okutrade`✓✗✓✓✓✗✓✓✓
`okx`✗✗✓✓✓✓✓✓✓
`ondo`✓✓✗✗✗✗✗✗✗
`openchat`✗✗✓✓✓✗✓✓✓
`openedendigital`✓✗✗✗✗✗✗✗✗
`opensea`✗✗✓✓✓✓✓✓✓
`optimism`✗✗✓✓✓✓✓✓✓
`optopia`✗✗✗✗✗✗✗✗✗
`opyn`✓✗✓✗✓✓✓✓✓
`orca`✓✗✓✓✓✓✓✓✓
`orderlynetwork`✗✗✗✗✗✗✗✗✗
`origin`✓✗✓✓✓✓✓✓✓
`osmosis`✗✗✓✓✓✗✓✗✗
`palmusd`✗✓✗✗✗✗✗✗✗
`pancakeswap`✓✗✓✓✓✓✓✓✓
`pangolin`✓✗✓✓✓✗✓✓✓
`paradex`✗✗✗✗✗✗✗✗✗
`paragonperps`✗✗✓✓✓✗✓✓✓
`parallelfinance`✗✗✗✗✗✗✗✗✗
`pareto`✗✓✗✗✗✗✗✗✗
`paxos`✓✓✗✗✗✗✗✗✗
`paypal`✓✗✗✗✗✗✗✗✗
`paytrie`✗✓✗✗✗✗✗✗✗
`peaq`✗✗✓✓✓✓✓✓✓
`pendle`✓✗✓✓✓✓✓✓✓
`pendulum`✗✗✓✓✓✗✓✓✓
`perena`✗✓✗✗✗✗✗✗✗
`perpetualprotocol`✓✗✓✓✓✓✓✓✓
`phala`✗✗✓✓✓✓✓✓✓
`phantom`✗✓✓✓✓✗✓✓✓
`pharaoh`✓✗✓✓✓✓✓✓✓
`photon`✗✗✓✓✓✗✓✓✓
`pikaprotocol`✓✗✓✓✓✓✓✓✓
`plasma`✗✗✓✓✓✓✓✓✓
`pocketnetwork`✗✗✓✓✓✓✗✗✗
`polkadot`✗✗✓✓✓✓✓✓✓
`polygon`✗✗✓✓✓✓✓✓✓
`polygonzkevm`✗✗✗✗✗✗✗✗✗
`polymarket`✓✓✓✓✓✓✓✓✓
`polynomial`✗✗✓✓✓✓✓✓✓
`pooltogether`✗✗✓✓✓✓✓✓✓
`premia`✓✗✓✓✓✓✓✓✓
`primenumbers`✓✗✓✓✓✓✓✓✓
`prismafinance`✓✓✗✗✗✗✓✓✓
`projectx`✗✗✗✗✗✗✓✓✓
`proofofplay`✗✗✗✗✗✗✗✗✗
`pumpfun`✗✗✓✓✓✗✓✓✓
`qchain`✗✗✗✗✗✗✓✗✗
`quantoz`✗✓✗✗✗✗✗✗✗
`quickswap`✓✗✓✓✓✗✓✓✓
`raac`✗✓✗✗✗✗✗✗✗
`radiant`✓✗✓✓✓✓✓✓✓
`raft`✓✗✗✗✗✗✗✗✗
`ramses`✓✗✓✓✓✓✓✓✓
`rarible`✗✗✓✓✓✓✓✓✓
`rarichain`✗✗✗✗✗✗✗✗✗
`raybot`✗✗✓✓✓✗✗✗✗
`raydium`✓✗✓✓✓✗✓✓✓
`real`✗✗✗✗✗✗✗✗✗
`redstonechain`✗✗✗✗✗✗✗✗✗
`reflexer`✓✓✓✗✓✓✗✗✗
`ren`✗✗✓✓✓✓✓✓✓
`republicnote`✓✗✗✗✗✗✗✗✗
`reserve`✓✓✓✓✓✓✓✓✓
`reservoirxyz`✗✓✗✗✗✗✗✗✗
`resolv`✗✓✗✗✗✗✗✗✗
`resupply`✗✓✗✗✗✗✗✗✗
`reya`✗✗✗✗✗✗✗✗✗
`rhinofi`✗✗✗✗✗✗✗✗✗
`ribbon`✓✗✓✓✓✓✓✓✓
`ribdigital`✗✓✗✗✗✗✗✗✗
`rif`✗✓✗✗✗✗✗✗✗
`ringsprotocol`✓✗✓✓✓✓✓✓✓
`ripio`✗✓✗✗✗✗✗✗✗
`ripple`✓✗✓✓✓✓✓✓✓
`ripplelabs`✓✓✗✗✗✗✗✗✗
`river`✗✓✗✗✗✗✗✗✗
`robinhood`✗✗✓✓✓✓✓✓✓
`robonomics`✗✗✓✓✓✓✓✓✓
`rocketpool`✓✗✗✗✗✗✓✓✓
`ronin`✗✗✓✓✓✓✓✓✓
`rootstock`✗✗✓✓✓✓✓✓✓
`sanctum`✓✗✗✗✗✗✗✗✗
`sanko`✗✗✗✗✗✗✗✗✗
`saturn`✗✓✗✗✗✗✗✗✗
`sbishinseitrust`✗✓✗✗✗✗✗✗✗
`schumanfinancial`✗✓✗✗✗✗✗✗✗
`scroll`✗✓✓✓✓✓✓✓✓
`seamlessprotocol`✓✗✓✓✓✓✓✓✓
`securitize`✓✗✗✗✗✗✗✗✗
`seinetwork`✗✗✓✓✓✗✓✓✓
`settlus`✗✗✗✗✗✗✓✓✓
`shadowexchange`✓✗✓✓✓✓✓✓✓
`shape`✗✗✗✗✗✗✓✓✓
`shoebill`✓✗✓✓✓✓✓✓✓
`silo`✓✗✓✓✓✓✓✓✓
`societegenerale`✓✓✗✗✗✗✗✗✗
`sofi`✗✓✗✗✗✗✗✗✗
`solana`✗✗✓✓✓✓✓✓✓
`solidlizard`✓✗✓✓✓✓✓✓✓
`solomonlabs`✗✓✗✗✗✗✗✗✗
`solstice`✗✓✗✗✗✗✗✗✗
`soltradingbot`✗✗✓✓✓✗✓✓✓
`solv`✓✗✓✓✓✗✓✓✓
`soneium`✗✗✗✗✗✗✓✓✓
`sonic`✗✗✓✓✓✓✓✓✓
`sophon`✗✗✗✗✗✗✗✗✗
`sorare`✗✗✗✗✗✗✗✗✗
`soulpeg`✗✓✗✗✗✗✗✗✗
`sound`✗✗✓✓✓✓✓✓✓
`spark`✓✗✓✓✓✓✓✓✓
`sperax`✗✓✗✗✗✗✗✗✗
`spiko`✓✗✗✗✗✗✗✗✗
`spookyswap`✓✗✓✓✓✓✗✓✓
`stablecoin`✗✓✗✗✗✗✗✗✗
`stablr`✗✓✗✗✗✗✗✗✗
`stacks`✗✗✓✓✓✓✓✓✓
`stader`✓✗✓✓✓✗✓✓✓
`stafi`✓✗✗✗✗✗✓✓✓
`stakestone`✓✗✗✗✗✗✓✓✓
`stakewise`✓✗✓✓✓✓✓✓✓
`standx`✗✓✗✗✗✗✗✗✗
`starknet`✗✗✓✓✓✓✓✓✓
`stasis`✗✓✗✗✗✗✗✗✗
`steakhousefinancial`✓✗✓✓✓✓✓✓✓
`stellar`✗✗✓✓✓✓✓✓✓
`story`✗✗✗✗✗✗✓✓✓
`straitsx`✗✓✗✗✗✗✓✗✗
`subsocial`✗✗✗✗✗✗✗✓✓
`sudoswap`✗✗✓✓✓✓✓✓✓
`sui`✗✓✓✓✓✓✓✓✓
`sunswap`✗✗✗✗✗✗✓✓✓
`superseed`✗✗✗✗✗✗✓✓✓
`superstate`✓✗✓✓✓✗✗✗✗
`sushiswap`✓✗✓✓✓✓✓✓✓
`swarm`✗✗✓✓✓✓✓✓✓
`swell`✓✗✗✗✗✗✓✓✓
`sx`✗✗✓✗✓✓✓✗✗
`symbiotic`✓✗✗✗✗✗✗✗✗
`synapse`✓✗✓✓✓✓✓✓✓
`syncswap`✓✗✓✓✓✓✓✓✓
`synfutures`✓✗✓✓✓✓✓✓✓
`synthetix`✗✓✓✓✓✓✓✓✓
`taiko`✗✗✗✗✗✗✗✗✗
`tangent`✗✓✗✗✗✗✗✗✗
`temple`✗✗✗✗✗✗✗✗✗
`tempo`✗✓✓✓✓✓✓✓✓
`tenbinlabs`✗✓✗✗✗✗✗✗✗
`termstructure`✗✗✗✗✗✗✗✗✗
`terra`✗✗✓✓✓✓✗✗✗
`tesserav`✗✗✗✗✗✗✗✗✗
`tether`✓✓✓✗✓✗✗✗✗
`tezos`✗✗✓✓✓✓✗✗✗
`thales`✗✗✓✓✓✓✓✓✓
`thegraph`✗✗✓✗✓✓✓✓✓
`thena`✓✗✓✓✓✓✓✓✓
`theo`✓✗✗✗✗✗✗✗✗
`thetanuts`✓✗✓✓✓✓✓✓✓
`thruster`✓✗✓✓✓✓✓✓✓
`titanl1`✗✗✗✗✗✗✓✗✗
`tixchain`✗✗✗✗✗✗✓✗✗
`tokemak`✓✗✓✓✓✓✗✗✗
`token`✗✓✗✗✗✗✗✗✗
`tokenisedgbp`✗✓✗✗✗✗✗✗✗
`tokenlon`✓✗✓✓✓✓✓✓✓
`tomatochain`✗✗✗✗✗✗✓✗✗
`ton`✗✗✓✓✓✓✓✓✓
`torifinance`✗✓✗✗✗✗✗✗✗
`tornadocash`✓✗✓✗✓✗✓✓✓
`toucan`✓✗✓✓✓✓✓✓✓
`tradable`✓✗✗✗✗✗✗✗✗
`traderjoe`✓✗✓✓✓✓✓✓✓
`tradexyz`✗✗✓✓✓✗✓✓✓
`transfero`✗✓✗✗✗✗✗✗✗
`trojan`✗✗✓✓✓✗✓✓✓
`tron`✗✗✓✓✓✓✓✓✓
`tronusdd`✗✓✗✗✗✗✗✗✗
`truefi`✗✗✓✓✓✓✓✓✓
`turingchain`✗✗✗✗✗✗✓✗✗
`unipilot`✗✗✓✓✓✓✓✓✓
`uniquenetwork`✗✗✓✓✓✗✓✓✓
`uniswap`✓✗✓✓✓✓✓✓✓
`uniswaplabs`✗✗✓✓✓✓✓✓✓
`unitas`✗✓✗✗✗✗✗✗✗
`unitedstables`✗✓✗✗✗✗✗✗✗
`unityusd`✗✓✗✗✗✗✗✗✗
`uptn`✗✗✗✗✗✗✓✗✗
`usdai`✓✓✗✗✗✗✗✗✗
`usdm1`✗✓✗✗✗✗✗✗✗
`usdufinance`✗✓✗✗✗✗✗✗✗
`usual`✓✓✓✗✓✗✗✗✗
`valuex`✗✗✗✗✗✗✓✗✗
`vaneck`✓✗✗✗✗✗✗✗✗
`variational`✓✗✓✓✓✗✓✓✓
`velodrome`✓✗✓✓✓✓✓✓✓
`ventuals`✗✗✓✓✓✗✓✓✓
`venus`✓✓✓✓✓✓✓✓✓
`versedex`✓✗✓✓✓✓✓✓✓
`vertex`✓✗✓✓✓✓✓✓✓
`vesta`✓✗✓✗✓✓✓✓✓
`viction`✗✗✓✓✓✗✓✓✓
`virtualsprotocol`✗✗✓✓✓✗✗✗✗
`vnx`✓✓✗✗✗✗✗✗✗
`volmex`✗✗✓✓✓✓✓✓✓
`voltz`✗✗✓✓✓✓✓✓✓
`winr`✗✗✗✗✗✗✗✗✗
`wisdomtree`✓✗✗✗✗✗✗✗✗
`wombat`✗✗✓✓✓✓✓✓✓
`worldchain`✗✗✗✗✗✗✓✓✓
`worldcoin`✗✗✗✗✗✗✓✓✓
`worldlibertyfinancial`✓✓✗✗✗✗✗✗✗
`worldmobilechain`✗✗✓✓✓✓✓✓✓
`wyoming`✗✓✗✗✗✗✗✗✗
`x2y2`✗✗✓✓✓✓✓✓✓
`xai`✗✗✓✓✓✓✗✓✓
`xdc`✗✗✓✓✓✓✓✓✓
`xoxno`✗✗✓✓✓✓✓✗✗
`xpla`✗✗✗✗✗✗✓✗✗
`xswap`✓✗✓✓✓✗✓✓✓
`xsy`✗✓✗✗✗✗✗✗✗
`yamatoprotocol`✗✓✗✗✗✗✗✗✗
`yeti`✗✓✗✗✗✗✗✗✗
`yuzumoney`✗✓✗✗✗✗✗✗✗
`zcash`✗✗✓✓✓✓✗✗✗
`zeitgeist`✗✗✗✗✗✗✓✓✓
`zerion`✗✗✓✗✓✓✓✓✓
`zerofi`✗✗✗✗✗✗✓✓✓
`zerolend`✓✗✓✓✓✗✓✓✓
`zircuit`✗✗✗✗✗✗✗✗✗
`zkfair`✗✗✗✗✗✗✗✗✗
`zkswap`✓✗✗✗✗✓✓✓✓
`zksyncera`✗✗✓✓✓✓✓✓✓
`zksyncerabridge`✓✗✓✗✓✗✓✓✓
`zksynclite`✗✗✗✗✗✗✗✗✗
`zora`✗✗✓✓✓✓✓✓✓
`zyberswap`✓✗✓✓✓✓✓✓✓
## Tables [Metrics](/docs/catalog/projects/metrics) holds the daily table schemas at project and project-and-chain grain, and example queries. [Registry](/docs/catalog/projects/registry) holds the identity table. [Screener](/docs/catalog/projects/screener) holds one row per project as of the last complete day, for ranking projects against each other. # Metrics Source: https://tokenterminal.com/docs/catalog/projects/metrics TVL, Fees, Revenue, Token incentives, Active users and sector-specific volume per project and per project on one chain. TVL, fees, revenue, expenses, earnings and active users. One row per thing per day, at two grains: project, and project and chain. ## Tables > [!NOTE] > > Daily DEX pool trading volume, Hyperliquid trading contributions and bridge transfer volumes cover closed UTC days and follow the availability cutoff of each contributing chain. **Project** One row per project per day. Everything the project runs, combined: gas from its chains and trading fees from its apps arrive added into one fee figure.
Table Value column What it holds
`metrics_projects.tvl_daily` `tvl` Value locked in the project's contracts at day end, in USD.
`metrics_projects.trading_volume_daily` `trading_volume` Cash value of the trades that took place, in USD.
`metrics_projects.active_loans_daily` `active_loans` Value of loans outstanding at day end, in USD.
`metrics_projects.assets_staked_daily` `assets_staked` Value staked at day end, in USD.
`metrics_projects.fees_daily` `fees` Total fees users paid, in USD. Chain gas plus app trading fees.
`metrics_projects.fees_supply_side_daily` `fees_supply_side` The part of those fees the project passed on to the supply side, in USD.
`metrics_projects.revenue_daily` `revenue` Fees the project kept, in USD.
`metrics_projects.token_incentives_daily` `token_incentives` Value of the project's own token paid out as rewards, in USD.
`metrics_projects.expenses_daily` `expenses` What the project spent, in USD: cost of revenue, token incentives and operating expenses, wherever each is reported onchain.
`metrics_projects.earnings_daily` `earnings` What the project kept after costs, in USD. Goes negative when a project pays out more than it retains.
`metrics_projects.treasury_daily` `treasury` Value the project held at day end, in USD, its own token included.
`metrics_projects.treasury_net_daily` `treasury_net` Value the project held at day end excluding its own token, in USD.
`metrics_projects.outstanding_supply_daily` `outstanding_supply` Stablecoin supply issued by the project and outstanding today, in USD. Stablecoin issuers only.
`metrics_projects.bridged_supply_daily` `bridged_supply` USD value of the project's stablecoins held outside the chain they were issued on.
`metrics_projects.buybacks_daily` `buybacks` USD value of the project's own tokens repurchased from the market.
`metrics_projects.bridge_deposits_daily` `bridge_deposits` USD value of assets held in the project's bridge contracts on the main chain.
`metrics_projects.transaction_volume_daily` `transaction_volume` USD value of transactions processed by the project.
`metrics_projects.open_interest_daily` `open_interest` USD notional value of all open positions on the project's derivatives markets.
`metrics_projects.trade_count_daily` `trade_count` Number of trades executed.
`metrics_projects.cost_of_revenue_daily` `cost_of_revenue` Direct supply-side cost of revenue.
`metrics_projects.capital_deployed_daily` `capital_deployed` USD value of user deposits an asset manager has allocated into investments.
`metrics_projects.flash_loan_volume_daily` `flash_loan_volume` Total flash loan volume.
`metrics_projects.operating_expenses_daily` `operating_expenses` Onchain operating expenses, excluding token incentives.
`metrics_projects.liquidation_volume_daily` `liquidation_volume` USD value of debt covered in liquidations.
`metrics_projects.tradeable_pair_count_daily` `tradeable_pair_count` Number of token pairs available for trading on the exchange.
`metrics_projects.tradeable_asset_count_daily` `tradeable_asset_count` Number of tokens tradeable on the exchange.
`metrics_projects.monthly_active_developers_daily` `monthly_active_developers` Number of active developers.
`metrics_projects.code_commit_count_daily` `code_commit_count` Commits to public repositories.
`metrics_projects.price_daily` `price` Project token price in USD.
`metrics_projects.market_cap_circulating_daily` `market_cap_circulating` Market cap on circulating supply.
`metrics_projects.market_cap_fully_diluted_daily` `market_cap_fully_diluted` Market cap on maximum supply.
`metrics_projects.staking_market_cap_daily` `staking_market_cap` USD value of the native token staked to secure the chains the project operates, summed across them.
`metrics_projects.token_supply_circulating_daily` `token_supply_circulating` Circulating token supply.
`metrics_projects.token_supply_maximum_daily` `token_supply_maximum` Maximum token supply.
`metrics_projects.token_trading_volume_daily` `token_trading_volume` Trading volume of the project's own token.
`metrics_projects.token_holders_daily` `token_holders` Addresses holding the project's token.
`metrics_projects.daily_active_addresses_daily` `daily_active_addresses` Distinct addresses transacting with the project's contracts per day.
`metrics_projects.weekly_active_addresses_daily` `weekly_active_addresses` Distinct addresses transacting with the project's contracts over a rolling 7 days.
`metrics_projects.monthly_active_addresses_daily` `monthly_active_addresses` Distinct addresses transacting with the project's contracts over a rolling 30 days.
`metrics_projects.transaction_count_contracts_daily` `transaction_count_contracts` Transactions calling the project's contracts.
`metrics_projects.gas_used_daily` `gas_used` Gas consumed by transactions calling the project's contracts.
`metrics_projects.fees_per_daily_active_user_daily` `fees_per_daily_active_user` Average fees per user.
`metrics_projects.revenue_per_daily_active_user_daily` `revenue_per_daily_active_user` Average revenue per user.
`metrics_projects.gross_profit_daily` `gross_profit` Revenue minus cost of revenue.
`metrics_projects.liquidity_turnover_daily` `liquidity_turnover` Trading volume relative to liquidity.
`metrics_projects.trade_size_average_daily` `trade_size_average` Average trading volume per trade.
`metrics_projects.trading_volume_per_daily_active_user_daily` `trading_volume_per_daily_active_user` Average trading volume per user.
`metrics_projects.price_to_fees_fully_diluted_daily` `price_to_fees_fully_diluted` Fully diluted market cap over annualized fees (trailing 30d run-rate).
`metrics_projects.price_to_fees_circulating_daily` `price_to_fees_circulating` Circulating market cap over annualized fees (trailing 30d run-rate).
`metrics_projects.price_to_revenue_fully_diluted_daily` `price_to_revenue_fully_diluted` Fully diluted market cap over annualized revenue (trailing 30d run-rate).
`metrics_projects.price_to_revenue_circulating_daily` `price_to_revenue_circulating` Circulating market cap over annualized revenue (trailing 30d run-rate).
`metrics_projects.take_rate_daily` `take_rate` Share of fees the project retains as revenue.
`metrics_projects.token_turnover_fully_diluted_daily` `token_turnover_fully_diluted` Token trading volume over fully diluted market cap.
`metrics_projects.token_turnover_circulating_daily` `token_turnover_circulating` Token trading volume over circulating market cap.
`metrics_projects.daily_active_users_daily` `daily_active_users` Distinct addresses that used the project that day. A HyperLogLog estimate, not a sum of the daily series.
`metrics_projects.weekly_active_users_daily` `weekly_active_users` Distinct addresses that used the project in the trailing 7 days. A HyperLogLog estimate.
`metrics_projects.monthly_active_users_daily` `monthly_active_users` Distinct addresses that used the project in the trailing 30 days. A HyperLogLog estimate.
**Project × chain** One row per project and chain per day. A chain's own numbers meet the project that runs it there.
Table Value column What it holds
`metrics_projects_by_chain.tvl_daily` `tvl` Value locked in the project's contracts on the chain at day end, in USD.
`metrics_projects_by_chain.trading_volume_daily` `trading_volume` Cash value of the trades that took place on the chain, in USD.
`metrics_projects_by_chain.active_loans_daily` `active_loans` Value of loans outstanding on the chain at day end, in USD.
`metrics_projects_by_chain.assets_staked_daily` `assets_staked` Value staked on the chain at day end, in USD.
`metrics_projects_by_chain.fees_daily` `fees` Total fees users paid on the chain, in USD.
`metrics_projects_by_chain.fees_supply_side_daily` `fees_supply_side` The part of those fees the project passed on to the supply side on the chain, in USD.
`metrics_projects_by_chain.revenue_daily` `revenue` Fees the project kept on the chain, in USD.
`metrics_projects_by_chain.token_incentives_daily` `token_incentives` Value of the project's own token paid out as rewards on the chain, in USD.
`metrics_projects_by_chain.outstanding_supply_daily` `outstanding_supply` Stablecoin supply issued by the project and outstanding on the chain today, in USD. Stablecoin issuers only.
`metrics_projects_by_chain.bridged_supply_daily` `bridged_supply` USD value of the project's stablecoins held outside the chain they were issued on.
`metrics_projects_by_chain.buybacks_daily` `buybacks` USD value of the project's own tokens repurchased from the market.
`metrics_projects_by_chain.bridge_deposits_daily` `bridge_deposits` USD value of assets held in the project's bridge contracts on the main chain.
`metrics_projects_by_chain.transaction_volume_daily` `transaction_volume` USD value of transactions processed by the project.
`metrics_projects_by_chain.open_interest_daily` `open_interest` USD notional value of all open positions on the project's derivatives markets.
`metrics_projects_by_chain.trade_count_daily` `trade_count` Number of trades executed.
`metrics_projects_by_chain.cost_of_revenue_daily` `cost_of_revenue` Direct supply-side cost of revenue.
`metrics_projects_by_chain.capital_deployed_daily` `capital_deployed` USD value of user deposits an asset manager has allocated into investments.
`metrics_projects_by_chain.flash_loan_volume_daily` `flash_loan_volume` Total flash loan volume.
`metrics_projects_by_chain.expenses_daily` `expenses` What the project spent on the chain, in USD: cost of revenue, token incentives and operating expenses.
`metrics_projects_by_chain.operating_expenses_daily` `operating_expenses` Onchain operating expenses, excluding token incentives.
`metrics_projects_by_chain.liquidation_volume_daily` `liquidation_volume` USD value of debt covered in liquidations.
`metrics_projects_by_chain.tradeable_pair_count_daily` `tradeable_pair_count` Number of token pairs available for trading on the exchange.
`metrics_projects_by_chain.tradeable_asset_count_daily` `tradeable_asset_count` Number of tokens tradeable on the exchange.
`metrics_projects_by_chain.daily_active_users_daily` `daily_active_users` Distinct addresses that used the project on the chain that day. A HyperLogLog estimate.
`metrics_projects_by_chain.weekly_active_users_daily` `weekly_active_users` Distinct addresses that used the project on the chain in the trailing 7 days. A HyperLogLog estimate.
`metrics_projects_by_chain.monthly_active_users_daily` `monthly_active_users` Distinct addresses that used the project on the chain in the trailing 30 days. A HyperLogLog estimate.
`metrics_projects_by_chain.daily_active_addresses_daily` `daily_active_addresses` Distinct addresses transacting with the project's contracts per day, on one chain.
`metrics_projects_by_chain.weekly_active_addresses_daily` `weekly_active_addresses` Distinct addresses transacting with the project's contracts over a rolling 7 days, on one chain.
`metrics_projects_by_chain.monthly_active_addresses_daily` `monthly_active_addresses` Distinct addresses transacting with the project's contracts over a rolling 30 days, on one chain.
`metrics_projects_by_chain.transaction_count_contracts_daily` `transaction_count_contracts` Transactions calling the project's contracts, on one chain.
`metrics_projects_by_chain.gas_used_daily` `gas_used` Gas consumed by transactions calling the project's contracts, on one chain.
`metrics_projects_by_chain.token_holders_daily` `token_holders` Addresses holding the project's token, on one chain.
`metrics_projects_by_chain.treasury_daily` `treasury` Value the project held at day end, in USD, its own token included, on one chain.
`metrics_projects_by_chain.treasury_net_daily` `treasury_net` Value the project held at day end excluding its own token, in USD, on one chain.
## Sample queries **Project** Each measure is its own table, so a row with all three is a join on `project_id` and `timestamp`. Bound the day range on every side, or the unbounded side reads its whole table. ```sql theme={null} with fees as ( select timestamp, fees from `metrics_projects.fees_daily` where project_id = 'hyperliquid' and timestamp >= timestamp('2026-06-01') ), revenue as ( select timestamp, revenue from `metrics_projects.revenue_daily` where project_id = 'hyperliquid' and timestamp >= timestamp('2026-06-01') ), tvl as ( select timestamp, tvl from `metrics_projects.tvl_daily` where project_id = 'hyperliquid' and timestamp >= timestamp('2026-06-01') ) select timestamp, fees.fees, revenue.revenue, tvl.tvl from fees full join revenue using (timestamp) full join tvl using (timestamp) order by timestamp ``` **Project × chain** A project's chain rows add back to its project row for the same day, where the measure adds up at all. ```sql theme={null} select chain_id, fees from `metrics_projects_by_chain.fees_daily` where project_id = 'hyperliquid' and timestamp = timestamp('2026-08-01') order by fees desc ``` **Balance rollup** `tvl` is a value standing at day end, and its rule in `dimensions.metrics` reads `over_time = 'last_value'`: the week's figure is the last day's value. The second column adds seven day-end balances and counts the same locked value seven times, so only one of these is a TVL. ```sql theme={null} select array_agg(tvl order by timestamp desc limit 1)[offset(0)] as tvl, sum(tvl) as tvl_summed from `metrics_projects.tvl_daily` where project_id = 'aave' and timestamp >= timestamp('2026-08-01') and timestamp < timestamp('2026-08-08') ``` **Sector total** Group on `primary_market_sector`, where every project appears exactly once. `market_sectors` holds every market sector of a project, so unnesting it in the from clause counts a project once per sector. ```sql theme={null} select projects.primary_market_sector, sum(daily.fees) as fees from `metrics_projects.fees_daily` as daily join `dimensions.projects` as projects using (project_id) where daily.timestamp = timestamp('2026-08-01') group by projects.primary_market_sector order by fees desc ``` # Registry Source: https://tokenterminal.com/docs/catalog/projects/registry Project names, market sectors, and who runs what. The identity table behind every project figure. Every fact and metric joins to it, and [Coverage](/docs/catalog/projects) introduces the grain. ## Columns
Column Type Description
`project_id` `STRING` Identifier of the project. Every table that mentions a project joins on this.
`slug` `STRING` The project's key in Token Terminal page URLs. It differs from `project_id` where the page URL is hyphenated (`redstone-chain` for `redstonechain`).
`url` `STRING` The project's page on the Token Terminal Explorer.
`name` `STRING` Display name.
`symbol` `STRING` Ticker of the project's token, where one exists.
`logo` `STRING` Public URL of the project logo, a PNG. Its `?logo_hash=` suffix changes whenever the image does. Null for a project whose image was never uploaded.
`description` `STRUCT` The project copy: `what` the project is, `who` it serves and `how` it works.
`links` `ARRAY` The project's links as `type` and `url` pairs (website, x, docs, github). `type` is the label as written, so `twitter` and `x` both occur.
`market_sectors` `ARRAY` Every market sector the project belongs to, as tag ids, primary first. Unnesting it yields one row per sector.
`primary_market_sector` `STRING` The market sector the project is listed under: the first element of `market_sectors`. One value per row.
`listing_date` `TIMESTAMP` When the project was listed on Token Terminal.
`archived_at` `TIMESTAMP` When Token Terminal stopped updating the project's metrics. Null while they are live.
`archived_reason` `STRING` The notice shown with `archived_at`. Null while the project's metrics are live.
`coingecko_id` `STRING` The project token's CoinGecko id.
`coinmarketcap_id` `STRING` The project token's CoinMarketCap id.
## Sample queries **Project identity** `project_id` is the key every project table joins on, and `primary_market_sector` is the sector the project is listed under. ```sql theme={null} select project_id, name, symbol, url, logo, primary_market_sector, listing_date from `dimensions.projects` where project_id = 'uniswap' ``` **Projects by sector** `primary_market_sector` holds one value per project, and every project appears in exactly one group. ```sql theme={null} select primary_market_sector, count(*) as projects from `dimensions.projects` group by primary_market_sector order by projects desc ``` **Projects in a sector** `market_sectors` answers membership, including projects listed under another sector. Aave is listed under `lending` and appears here as a stablecoin issuer. ```sql theme={null} select project_id, name, primary_market_sector, market_sectors from `dimensions.projects` where 'stablecoin-issuers' in unnest(market_sectors) order by project_id ``` **Projects with several apps** A project with several apps has one row here and several in `dimensions.apps`, so the count comes from a join. ```sql theme={null} select projects.project_id, projects.name, count(*) as apps from `dimensions.projects` as projects join `dimensions.apps` as apps using (project_id) group by projects.project_id, projects.name having count(*) > 1 order by apps desc, projects.project_id ``` # Screener Source: https://tokenterminal.com/docs/catalog/projects/screener Every project's latest figures, with averages, totals and changes over six windows, in one row. One row per project in `screeners.projects`, every figure as of `as_of`, the last complete day. Each measure has a column per window and aggregation, named `__`: `fees_30d_sum` is the fees of the 30 days ending on `as_of`, and `tvl_7d_change` is TVL on `as_of` against TVL seven days earlier. ## Columns **Keys** The two key columns, then one FLOAT64 column per measure, window and aggregation. Every row is a project in `dimensions.projects`, so the join on `project_id` always matches.
Column Type Description
`as_of`TIMESTAMPThe last complete day, the same on every row. Every window ends on it.
`project_id`STRINGProject the row belongs to, such as `aave`; joins `dimensions.projects`.
**Aggregations** A window is `1d`, `7d`, `30d`, `90d`, `180d` or `365d`, and spans that many days ending on `as_of`, while the `max_` columns read the whole history. Which aggregations a measure has follows its `over_time` in [Metric definitions](/docs/catalog/metric-definitions): only a measure whose `over_time` is `sum` has `sum`.
Column What it holds
`__avg`Mean of the daily values over the window.
`__sum`Total of the daily values over the window. Flows only: the measures ticked under Sum.
`__change`A comparison of two aggregations: the value on `as_of` against the value one window earlier, as `(now - then) / abs(then)`. Null when either value is missing or the earlier one is 0.
`__trend`A comparison of two aggregations: the window's average against the average of the window before it, as `(avg - prior) / abs(prior)`. Null unless the window before has a value on every one of its days, and null when its average is 0.
`_max_latest`The value on `as_of`. Null when there is none.
`_max_ath`The highest daily value over the project's whole history.
`_max_atl`The lowest daily value over the project's whole history.
**Measures** Every measure has the `avg`, `change`, `trend` and `max_` columns, and the flows also have `sum`. A distinct count such as `daily_active_users` or `token_holders` takes `avg`, never `sum`.
Measure Sum What it holds
`daily_active_addresses`✗Distinct addresses transacting with the project's contracts per day.
`monthly_active_addresses`✗Distinct addresses transacting with the project's contracts over a rolling 30 days.
`weekly_active_addresses`✗Distinct addresses transacting with the project's contracts over a rolling 7 days.
`monthly_active_developers`✗Number of active developers.
`active_loans`✗Value of loans outstanding at day end, in USD.
`fees_per_daily_active_user`✗Average fees per user.
`revenue_per_daily_active_user`✗Average revenue per user.
`assets_staked`✗Value staked at day end, in USD.
`bridge_deposits`✗USD value of assets held in the project's bridge contracts on the main chain.
`bridged_supply`✗USD value of the project's stablecoins held outside the chain they were issued on.
`buybacks`✓USD value of the project's own tokens repurchased from the market.
`capital_deployed`✗USD value of user deposits an asset manager has allocated into investments.
`code_commit_count`✓Commits to public repositories.
`cost_of_revenue`✓Direct supply-side cost of revenue.
`earnings`✓What the project kept after costs, in USD. Goes negative when a project pays out more than it retains.
`notional_trading_volume_exchange`✓Notional value of perpetual futures traded, attributed to the project whose matching engine settled the trade.
`expenses`✓What the project spent, in USD: cost of revenue, token incentives and operating expenses, wherever each is reported onchain.
`fees`✓Total fees users paid, in USD. Chain gas plus app trading fees.
`fees_supply_side`✓The part of those fees the project passed on to the supply side, in USD.
`flash_loan_volume`✓Total flash loan volume.
`gas_used`✓Gas consumed by transactions calling the project's contracts.
`gross_profit`✓Revenue minus cost of revenue.
`notional_trading_volume_interface`✓Notional value of perpetual futures traded, attributed to the project whose interface the trade was placed through.
`liquidation_volume`✓USD value of debt covered in liquidations.
`liquidity_turnover`✗Trading volume relative to liquidity.
`market_cap_circulating`✗Market cap on circulating supply.
`market_cap_fully_diluted`✗Market cap on maximum supply.
`open_interest`✗USD notional value of all open positions on the project's derivatives markets.
`operating_expenses`✓Onchain operating expenses, excluding token incentives.
`outstanding_supply`✗Stablecoin supply issued by the project and outstanding today, in USD. Stablecoin issuers only.
`price_to_fees_circulating`✗Circulating market cap over annualized fees (trailing 30d run-rate).
`price_to_fees_fully_diluted`✗Fully diluted market cap over annualized fees (trailing 30d run-rate).
`price`✗Project token price in USD.
`price_to_revenue_circulating`✗Circulating market cap over annualized revenue (trailing 30d run-rate).
`price_to_revenue_fully_diluted`✗Fully diluted market cap over annualized revenue (trailing 30d run-rate).
`revenue`✓Fees the project kept, in USD.
`staking_market_cap`✗USD value of the native token staked to secure the chains the project operates, summed across them.
`take_rate`✗Share of fees the project retains as revenue.
`token_incentives`✓Value of the project's own token paid out as rewards, in USD.
`token_supply_circulating`✗Circulating token supply.
`token_supply_maximum`✗Maximum token supply.
`token_trading_volume`✓Trading volume of the project's own token.
`token_turnover_circulating`✗Token trading volume over circulating market cap.
`token_turnover_fully_diluted`✗Token trading volume over fully diluted market cap.
`token_holders`✗Addresses holding the project's token.
`trade_count`✓Number of trades executed.
`tradeable_asset_count`✗Number of tokens tradeable on the exchange.
`tradeable_pair_count`✗Number of token pairs available for trading on the exchange.
`trading_volume`✓Cash value of the trades that took place, in USD.
`trade_size_average`✗Average trading volume per trade.
`trading_volume_per_daily_active_user`✗Average trading volume per user.
`transaction_count_contracts`✓Transactions calling the project's contracts.
`transaction_volume`✓USD value of transactions processed by the project.
`transfer_volume`✓USD value of assets moved through the project's bridge transfers, counted once per transfer.
`treasury`✗Value the project held at day end, in USD, its own token included.
`treasury_net`✗Value the project held at day end excluding its own token, in USD.
`tvl`✗Value locked in the project's contracts at day end, in USD.
`daily_active_users`✗Distinct addresses that used the project that day. A HyperLogLog estimate, not a sum of the daily series.
`monthly_active_users`✗Distinct addresses that used the project in the trailing 30 days. A HyperLogLog estimate.
`weekly_active_users`✗Distinct addresses that used the project in the trailing 7 days. A HyperLogLog estimate.
## Sample queries **One project** Every column of one row shares the same `as_of`, so the figures read together. ```sql theme={null} select as_of, tvl_max_latest, tvl_7d_change, fees_30d_sum, fees_30d_trend from `screeners.projects` where project_id = 'aave' ``` **Top 25 by 30-day fees** `fees_30d_sum` is the total of the 30 days ending on `as_of`. The join to `dimensions.projects` on `project_id` adds the name. ```sql theme={null} select projects.name, screener.fees_30d_sum, screener.revenue_30d_sum, screener.fees_30d_trend from `screeners.projects` as screener join `dimensions.projects` as projects using (project_id) where screener.fees_30d_sum is not null order by screener.fees_30d_sum desc limit 25 ``` **Biggest 7-day TVL moves** `tvl_7d_change` compares TVL on `as_of` with TVL seven days earlier, as a fraction. The TVL floor keeps a small base from dominating the ranking. ```sql theme={null} select projects.name, screener.tvl_max_latest, screener.tvl_7d_change from `screeners.projects` as screener join `dimensions.projects` as projects using (project_id) where screener.tvl_max_latest > 10000000 and screener.tvl_7d_change is not null order by abs(screener.tvl_7d_change) desc limit 25 ``` **Market cap against yearly revenue** `revenue_365d_sum` is the revenue of the 365 days ending on `as_of`, and `market_cap_circulating_max_latest` the latest circulating market cap. Their ratio is a price-to-sales multiple. ```sql theme={null} select projects.name, screener.market_cap_circulating_max_latest, screener.revenue_365d_sum, safe_divide( screener.market_cap_circulating_max_latest, screener.revenue_365d_sum ) as price_to_sales from `screeners.projects` as screener join `dimensions.projects` as projects using (project_id) where screener.revenue_365d_sum > 1000000 and screener.market_cap_circulating_max_latest > 0 order by price_to_sales limit 25 ``` # Disclosures Source: https://tokenterminal.com/docs/catalog/real-world-assets/disclosures Issuer-disclosed legal, regulatory and market terms of every real-world asset, each value with its evidence. `dimensions.asset_disclosures` is what an issuer discloses about a tokenized asset in its own documents: the legal entity that issues it, its domicile, the law and the regulator it answers to, its custodian, auditor and transfer agent, how a holder subscribes and redeems, the fees and minimums, and its identifiers (ISIN, CUSIP, FIGI, LEI). One row per asset, one typed column per term, and for every researched or looked-up term a companion `_evidence` column with the confidence, reasoning and citations (url, title, verbatim excerpts) behind the value, plus a companion `_status` column on every term saying why it holds the value it does. The heading, label and definition shown for each of these columns, and the definition of each closed-set value, are rows of `dimensions.asset_disclosure_fields`, documented on the [Registry page](/docs/catalog/real-world-assets/registry). A term whose value depends on the issuing entity or the holder market is an `ARRAY>`: the issuing entity (`issuer_legal_entity`, `domicile`), a group affiliate that a market's own holder document names without it issuing the token (`affiliate_entity`), the registers keyed to the issuer (`issuer_lei`, `issuer_cik`), the holder's legal terms (`governing_law`, `governing_law_subdivision`, `dispute_resolution_country`) and the supervision of that entity's offering (`regulatory_framework`, `regulator`). The key names the jurisdiction the issuing entity issues under: an ISO 3166-1 alpha-2 country code, or `EEA` for an entity issuing to the European Economic Area under an EU document. An affiliate is keyed by the market whose document names it, `SG` for the Singapore affiliate behind a Singapore addendum, and the regimes, authorities and terms attached to it sit under that key rather than an issuer's. The list never bundles entities: one element per entity, sorted alphabetically by jurisdiction. For `regulatory_framework` and `regulator` the element's `value` is an `ARRAY` holding every regime or authority attached to that entity. A keyed column's evidence is an `ARRAY>` with one element per populated jurisdiction, plus, when the term applies and was checked, one element whose `jurisdiction` is NULL holds the field-level reason for a term with an empty value array. The jurisdiction key is NULLABLE for that reason, and no country is invented. Every other evidence column is a single `STRUCT`, including the token-wide list columns, whose one evidence struct holds the citations behind the whole list, and `citations` is an `ARRAY>`. Beside `_evidence`, every disclosure term has a companion `_status` column of type `STRING`, and unlike evidence the status is present for every term, including the registry and warehouse facts (`asset_class`, `underlying_ticker`, `reference_asset`, `issuer_project`, `inception_date`) that have no evidence column. It takes one of three values. `disclosed` means the term has a value. `not_available` means the term applies to the asset's sector and has no value, whatever the reason: most often the issuer's documents were read and state nothing, which is itself a disclosure finding, the issuer is silent, and where a register lookup (GLEIF, EDGAR, OpenFIGI) produced nothing, `_evidence.reasoning` says so in words. `not_applicable` means the term is out of scope for the asset's sector; which terms apply is decided by the field catalogue rather than per asset, so the status is the same for every asset of a sector, `sector` and `region` are tokenized-funds and tokenized-stocks terms and every stablecoin reads `not_applicable`, while `reserve_composition` is a stablecoin term and every fund does, which is what makes `count(*) - countif(status = 'not_applicable')` the applicable disclosure surface. A value is non-null exactly when the status is `disclosed`; a null value never stands alone. For a jurisdiction-keyed term the status describes the whole term: an empty array reads `not_available`, and so does an array whose elements all have a null `value`. `inception_date_status` is only ever `disclosed` or `not_available`, because a null `inception_date` means no deployment has an observed first mint yet, a gap in Token Terminal's own chain coverage rather than a statement about the issuer. ## Columns
ColumnTypeDescription
`asset_id``STRING`The asset, such as `usdc`; joins [`dimensions.assets`](/docs/catalog/assets/registry).
`retrieved_at``TIMESTAMP`When the issuer's documents were read for this row.
`_status``STRING`The status of every term, one companion per term column, including the registry and warehouse facts with no evidence column: `disclosed` when the term has a value, `not_available` when the term applies to the asset's sector and its value is null, and `not_applicable` when the term is out of scope for the asset's sector.
`website``STRING`The issuer page that names this token; naming the instrument is enough, the page need not link its terms.
`claim_type``STRING`What a holder holds. `issuer_sponsored`: a direct claim on or ownership of the issuer's instrument. `synthetic_collateralized`: a contractual exposure backed by dedicated collateral. `synthetic_uncollateralized`: a contractual exposure without it.
`issuance_status``STRING`Whether the issuer still creates the token. `active`, `paused` (issuance suspended, redemption open), `legacy_redemption_only` or `sunset`.
`sector``ARRAY`Sectors of the underlying exposure (`information_technology`, `financials`, `government_debt`, `commodities`), not of the tokenization provider. Tokenized funds and tokenized stocks only; null elsewhere.
`region``ARRAY`Regions of the underlying economic exposure (`north_america`, `europe`, `greater_china`, `global`), not the issuer domicile. Tokenized funds and tokenized stocks only; null elsewhere.
`reference_ratio``FLOAT64`Units of the reference asset one token represents by design (1 for a dollar stablecoin, 1 troy ounce for a gold token). Null when the token tracks a floating NAV.
`reserve_composition``ARRAY`Asset categories in the reserve backing a stablecoin, from the latest attestation (`cash`, `bank_deposits`, `treasury_bills`, `repurchase_agreements`, `money_market_funds`, `commercial_paper`, `corporate_bonds`, `precious_metals`, `crypto_assets`, `secured_loans`, `other`). Stablecoins only; null elsewhere.
`issuer_legal_entity``ARRAY`Legal name of the entity that issues the token to the holders the document governs, distinct from its parent, manager, platform and distributors. One element per issuing entity, keyed by the jurisdiction it issues under, `value` typed `STRING`.
`affiliate_entity``ARRAY`Legal name of a group entity of the issuer that contracts with, or is licensed to serve, holders in one market under that market's own holder document without issuing the token, such as the Singapore affiliate behind a Singapore addendum. Never an issuer: `issuer_legal_entity`, `domicile`, `issuer_lei` and `issuer_cik` hold issuers only. One element per affiliate, keyed by the market whose document names it, `value` typed `STRING`.
`domicile``ARRAY`Incorporation country of the issuing entity, ISO 3166-1 alpha-2. One element per issuing entity, keyed by the jurisdiction it issues under, `value` typed `STRING`.
`governing_law``ARRAY`Country whose law governs the contract between holder and issuer, or the affiliate a market document makes the counterparty, from the governing-law clause of the holder document, ISO 3166-1 alpha-2; the law chosen may differ from the key, terms for US holders governed by Singapore law reading jurisdiction `US` with `value` `SG`. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `STRING`.
`governing_law_subdivision``ARRAY`State, province or canton named in the governing-law clause (Delaware, New York, Zug), ISO 3166-2. Null when the clause names only a country. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `STRING`.
`dispute_resolution_country``ARRAY`Country of the court or arbitration seat named in the dispute-resolution clause of the holder document, ISO 3166-1 alpha-2. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `STRING`.
`regulatory_framework``ARRAY`Regime under which the instrument is issued or offered to the holders the document governs (`us_reg_d`, `us_reg_s`, `us_money_transmitter`, `us_national_trust_bank`, `eu_mica`, `eu_prospectus`, `ch_dlt_act`, `sg_mas`, `unregulated` and the other regimes of the closed list), not the licence of a distributor; every regime attached to that entity's offering keeps the key of the entity it attaches to, so `us_reg_s` on a BVI issuer sits under `VG` and `sg_mas` held by a Singapore affiliate sits under `SG`. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `ARRAY`.
`regulator``ARRAY`Supervisory authority of the issuer, of an affiliate a market's holder document names, or of the instrument, every authority supervising that entity or named by its holder document. One element per entity, keyed by the jurisdiction the issuer issues under or the market of the affiliate, `value` typed `ARRAY`.
`bankruptcy_remote``BOOL`True when a legal document states that the backing assets sit outside the issuer estate on insolvency (trust, bankruptcy-remote vehicle, statutory segregation).
`account_segregation``BOOL`True when a document states that backing or holder assets are held in accounts segregated from the issuer's operating funds.
`mica_marker``STRING`Classification under MiCA by legal nature and peg, independent of authorization: `emt_by_peg`, `art_by_peg`, `other_crypto_asset` or `out_of_scope_financial_instrument`.
`voting_rights``BOOL`True when token holders can vote or direct the votes of the underlying shares. Tokenized stocks only; null elsewhere.
`dividend_eligibility``BOOL`True when token holders are entitled to dividends or distributions declared on the underlying share. Tokenized stocks only; null elsewhere.
`platform``STRING`Tokenization platform, when distinct from the legal issuer.
`manager``STRING`Investment manager of a tokenized fund. Tokenized funds only; null elsewhere.
`sub_advisor``STRING`Delegated investment adviser of a tokenized fund, when disclosed. Tokenized funds only; null elsewhere.
`custodian``STRING`Institution holding the real-world assets that back the token. Several providers are separated by semicolons.
`crypto_custodian``STRING`Third party holding the keys that control the token contract, mint authority or issuer treasury wallets.
`fund_administrator``STRING`Provider that calculates NAV and keeps the fund books. Tokenized funds only; null elsewhere.
`transfer_agent``STRING`Transfer agent of record for the legal holder register of the security or share class. Tokenized funds and tokenized stocks only; null elsewhere.
`digital_transfer_agent``STRING`Entity that keeps the on-chain holder ledger, when distinct from `transfer_agent`. Tokenized funds and tokenized stocks only; null elsewhere.
`broker``ARRAY`Executing brokers named for the token, traditional or crypto, one element per executing broker. Tokenized funds and tokenized stocks only; null elsewhere.
`auditor``STRING`Firm that audits or attests the backing of the token or, for a native share, the issuer's financial statements.
`attestation_frequency``STRING`Cadence of published reserve attestations or audits: `daily`, `weekly`, `monthly`, `quarterly`, `annual`, `irregular` or `none`. Stablecoins only; null elsewhere.
`security_trustee``STRING`Trustee or security agent holding collateral or a security interest for token holders, typical of notes and certificates. Tokenized funds and tokenized stocks only; null elsewhere.
`storage_location``ARRAY`Countries of the vaults holding the physical commodity, ISO 3166-1 alpha-2. Tokenized commodities only; null elsewhere.
`primary_route``STRING`How a holder enters and exits directly on the issuer side, which the other primary-market columns refer to: `issuer_mint_redeem`, `fund_subscription`, `transfer_agent_conversion`, `issuer_operated_venue` or `none`.
`eligible_investors``ARRAY`Investor classes that may use the primary route (`retail`, `professional`, `accredited`, `qualified_investor`, `qualified_purchaser`, `institutional`), one element per investor class.
`eligible_jurisdictions``ARRAY`Investor residences eligible for the primary route: ISO alpha-2 country codes or the region codes `global`, `eea`, `gcc`. Places carved out of them are in `excluded_jurisdictions`.
`excluded_jurisdictions``ARRAY`Investor residences excluded from the primary route although `eligible_jurisdictions` covers them: ISO alpha-2 country codes, the region codes `eea` and `gcc`, and `sanctioned` for jurisdictions under applicable sanctions. `global` in `eligible_jurisdictions` with `US` here reads as open to everyone outside the United States.
`kyc_required``BOOL`True when the primary route requires KYC.
`right_to_redeem``BOOL`True when the instrument terms give holders a right to exit through the primary route.
`physical_redemption``BOOL`True when holders can redeem a commodity token for physical delivery. Tokenized commodities only; null elsewhere.
`base_assets``ARRAY`Currencies or assets accepted on entry and paid on exit through the primary route, one element per accepted currency or asset: ISO currency codes for fiat, tickers for crypto, a short name for a physical asset, or `underlying shares` for the underlying share delivered in kind.
`min_investment``FLOAT64`Minimum entry through the primary route, in the currency or unit the document states.
`min_redemption``FLOAT64`Minimum exit through the primary route, in the currency or unit the document states.
`subscription_time``STRING`How long entry settles, from a valid funded order to tokens credited: `instant`, `daily` (T+0 or T+1 business day), `weekly` (two to five business days), `monthly`, `quarterly` or `other`. For a vehicle that deals periodically, the wait for the next dealing window is part of the band.
`redemption_time``STRING`How long exit settles, from a valid redemption request to proceeds received: `instant`, `daily` (T+0 or T+1 business day), `weekly` (two to five business days), `monthly`, `quarterly` or `other`. For a vehicle that deals periodically, the wait for the next dealing window is part of the band.
`is_open_ended``BOOL`True when the fund issues and redeems on an ongoing basis rather than as a closed-ended vehicle. Tokenized funds only; null elsewhere.
`lockup_period``FLOAT64`Lockup in months. Tokenized funds only; null elsewhere.
`management_fee``FLOAT64`Annual management fee in basis points. Tokenized funds and tokenized stocks only; null elsewhere.
`storage_fee``FLOAT64`Annual custody or storage fee charged to holders, in basis points. Tokenized commodities only; null elsewhere.
`dividend_handling``STRING`How dividends reach token holders: `distributed_in_cash`, `distributed_in_token`, `reinvested`, `retained_by_issuer`, `none`. Tokenized stocks only; null elsewhere.
`isin``STRING`ISIN of the instrument, from the issuer's own pages or the LEI-to-ISIN register. Tokenized funds and tokenized stocks only; null elsewhere.
`cusip``STRING`CUSIP derived from a US or Canadian ISIN. Tokenized funds and tokenized stocks only; null elsewhere.
`figi``STRING`FIGI of the instrument, from OpenFIGI. Tokenized funds and tokenized stocks only; null elsewhere.
`inception_date``STRING`Date of the first on-chain mint across the token's deployments, ISO 8601. No evidence column.
`inception_date_status``STRING`Status of `inception_date`, only ever `disclosed` or `not_available`: a null date means no deployment has an observed first mint yet, a gap in Token Terminal's own chain coverage rather than a statement about the issuer.
`asset_class``STRING`Asset type from the registry: `stablecoin`, `tokenized_funds`, `tokenized_stocks` or `tokenized_commodities`. No evidence column.
`underlying_ticker``STRING`Listed ticker of the equity a tokenized stock tracks, from the registry. Tokenized stocks only; null elsewhere. No evidence column.
`underlying_security_id``STRING`Stable registry ID of the exact underlying security, distinguished by legal issuer and share class; joins [`dimensions.underlying_securities`](/docs/catalog/real-world-assets/registry) on `security_id`.
`underlying_fund_relationship``STRING`Relationship between the token and the referenced fund: `same_fund` (the token directly represents units in the fund), `separate_fund` (the tokenized fund invests in a separate fund) or `certificate` (a certificate or structured note tracking the fund).
`underlying_isin``STRING`ISIN of the exact security the asset references, as its issuer's own documents state it; the evidence is why the asset maps to it. Joins [`dimensions.underlying_securities`](/docs/catalog/real-world-assets/registry) on `isin`.
`underlying_share_class``STRING`The exact class or units of the underlying security. Different classes are distinct securities.
`underlying_website``STRING`Official product or investor-relations page of the underlying security, rather than the tokenization program.
`underlying_fund_brand``STRING`Brand under which the underlying fund is marketed, kept separate from its legal issuer and operational providers.
`underlying_fund_sponsor``STRING`Entity explicitly appointed as sponsor of the underlying fund.
`underlying_fund_manager``STRING`Firm explicitly appointed to make investment decisions for the underlying fund's portfolio, separate from its administrator and from the manager of a separate tokenized fund.
`underlying_fund_administrator``STRING`Firm appointed to calculate the underlying fund's net asset value and keep its accounting records, separate from issuer, sponsor, investment manager, custodian and trustee.
`underlying_fund_trustee``STRING`Entity explicitly appointed as trustee of the underlying fund, separate from holding collateral or security interests for token holders.
`reference_asset``STRING`Identifier of the reference asset the token tracks, from the registry; joins [`dimensions.reference_assets`](/docs/catalog/assets/registry). No evidence column.
`issuer_project``STRING`Project id of the issuer, from the registry; joins [`dimensions.projects`](/docs/catalog/projects/registry). No evidence column.
`issuer_lei``ARRAY`LEI of the issuing entity per jurisdiction, from the GLEIF register. One element per issuing entity, keyed by the jurisdiction it issues under, `value` typed `STRING`.
`issuer_cik``ARRAY`SEC CIK of the issuing entity per jurisdiction, from EDGAR. One element per issuing entity, keyed by the jurisdiction it issues under, `value` typed `STRING`.
`fanned_out_from``STRING`For a token issued in bulk under one wrapper program (a tokenized stock, a commodity ETF wrapper or a tokenized fund), the program whose legal and operational terms are established on a sample of its tokens and apply to the rest; this column names that program. Null when no fan-out provenance is recorded on the row; null is not proof that every value was established on this token itself, since missing provenance cannot establish source ownership. No evidence column.
`fanned_out_from_status``STRING`Status of `fanned_out_from`: `disclosed` when the row came from a program and `not_available` when it did not. A value is non-null exactly when the status is `disclosed`.
## Sample queries **One asset's entity and terms** The entities of one asset, its issuers and any affiliate a market's holder document names, with the domicile of each issuer, the law and forum of the holder terms, and the regimes and authorities attached to each entity, one line per jurisdiction. ```sql theme={null} select entity.jurisdiction, entity.role, entity.value as legal_entity, domicile.value as domicile, law.value as governing_law, forum.value as dispute_resolution_country, regime.value as regulatory_framework, regulator.value as regulator from `dimensions.asset_disclosures` as disclosures cross join unnest(array_concat( array(select as struct jurisdiction, value, 'issuer' as role from unnest(disclosures.issuer_legal_entity)), array(select as struct jurisdiction, value, 'affiliate' as role from unnest(disclosures.affiliate_entity)) )) as entity left join unnest(disclosures.domicile) as domicile on domicile.jurisdiction = entity.jurisdiction left join unnest(disclosures.governing_law) as law on law.jurisdiction = entity.jurisdiction left join unnest(disclosures.dispute_resolution_country) as forum on forum.jurisdiction = entity.jurisdiction left join unnest(disclosures.regulatory_framework) as regime on regime.jurisdiction = entity.jurisdiction left join unnest(disclosures.regulator) as regulator on regulator.jurisdiction = entity.jurisdiction where disclosures.asset_id = 'usdc' order by entity.jurisdiction ``` **Regulators of tokenized stocks** The authorities each tokenized stock's issuing entity answers to, one line per authority, joined to the asset registry for the type filter. ```sql theme={null} select disclosures.asset_id, regulator.jurisdiction, authority from `dimensions.asset_disclosures` as disclosures join `dimensions.assets` as assets using (asset_id) cross join unnest(disclosures.regulator) as regulator cross join unnest(regulator.value) as authority where assets.asset_type = 'tokenized-stocks' order by disclosures.asset_id, regulator.jurisdiction, authority ``` **Identifiers** ISIN, FIGI and the issuer's LEI side by side, one line per asset; the LEI is the first issuing entity's, elements being sorted by jurisdiction. ```sql theme={null} select disclosures.asset_id, disclosures.isin, disclosures.figi, ( select lei.value from unnest(disclosures.issuer_lei) as lei order by lei.jurisdiction limit 1 ) as issuer_lei from `dimensions.asset_disclosures` as disclosures where disclosures.isin is not null or disclosures.figi is not null or array_length(disclosures.issuer_lei) > 0 order by disclosures.asset_id ``` **Evidence behind a value** The pages and passages that back one term, one line per excerpt. ```sql theme={null} select disclosures.claim_type_evidence.confidence, citation.url, excerpt from `dimensions.asset_disclosures` as disclosures cross join unnest(disclosures.claim_type_evidence.citations) as citation cross join unnest(citation.excerpts) as excerpt where disclosures.asset_id = 'usdc' order by citation.url ``` **Redemption terms of stablecoins** Redemption right, settlement time and minimum of every stablecoin. ```sql theme={null} select disclosures.asset_id, disclosures.right_to_redeem, disclosures.redemption_time, disclosures.min_redemption from `dimensions.asset_disclosures` as disclosures where disclosures.asset_class = 'stablecoin' order by disclosures.asset_id ``` **Disclosure coverage** For one sector, how much of the applicable disclosure surface is filled: the count whose value is present and the count where the issuer's documents were read and state nothing. `not_applicable` is absent because `custodian` applies to every stablecoin, so the two counts are the whole population. ```sql theme={null} select countif(disclosures.custodian_status = 'disclosed') as disclosed, countif(disclosures.custodian_status = 'not_available') as issuer_silent from `dimensions.asset_disclosures` as disclosures join `dimensions.assets` as assets using (asset_id) where assets.asset_type = 'stablecoin' ``` # Real-world assets Source: https://tokenterminal.com/docs/catalog/real-world-assets/index Every tokenized stock, fund and commodity: supply, holders and price against the underlying, across every chain. Supply, price, holders and transfer activity for every tokenized stock, fund and commodity Token Terminal tracks, from the asset down to its token contract on each chain. ## Coverage A tab per grain, then the chains. Each tab says what one row is, and a tick marks every issuer that reports it. **Asset** A real-world asset is one instrument brought onchain, such as `buidl`. One row per issuer, ticked for every measure its assets report.
Issuer Price Circulating market cap Transfer volume Daily active users Weekly active users Monthly active users DeFi TVL APY Holders Mints Redemptions Transfer count
`22xfund`✗✗✗✓✓✓✗✗✓✗✗✓
`3jane`✓✓✓✓✓✓✓✓✓✓✓✓
`a7a5`✓✓✓✓✓✓✓✗✓✓✓✓
`aave`✓✓✓✓✓✓✓✓✓✓✓✓
`abt`✓✓✓✓✓✓✓✗✓✓✓✓
`accountable`✓✓✓✓✓✓✓✓✓✓✓✓
`aegis`✗✗✗✓✓✓✓✗✗✗✗✗
`aktionariat`✗✗✗✓✓✓✓✗✓✗✗✓
`alloyx`✗✗✗✓✓✓✗✗✓✗✗✓
`alphaledger`✗✗✗✓✓✓✗✗✓✗✗✓
`anchored`✓✓✓✓✓✓✗✗✓✓✓✓
`angle`✓✓✓✓✓✓✓✓✓✓✓✓
`anzen`✓✓✓✓✓✓✓✓✓✓✓✓
`apyx`✓✓✓✓✓✓✓✓✓✓✓✓
`archax`✗✗✗✓✓✓✗✗✗✗✗✓
`asseto`✓✓✓✓✓✓✓✗✓✓✓✓
`aster`✓✓✓✓✓✓✓✗✓✓✓✓
`aurus`✗✗✗✓✓✓✗✗✓✗✗✓
`auxite`✗✗✗✓✓✓✗✗✓✗✗✓
`avalonfinance`✗✗✗✓✓✓✓✗✗✗✗✗
`avantprotocol`✗✗✗✓✓✓✓✗✗✗✗✗
`backed`✓✓✓✓✓✓✓✗✓✓✓✓
`backpack`✓✓✓✓✓✓✓✗✓✓✓✓
`balancer`✗✗✗✓✓✓✗✗✗✗✗✗
`binance`✓✓✓✓✓✓✓✗✓✓✓✓
`bitbond`✓✓✓✓✓✓✗✗✓✓✗✓
`bitfi`✗✗✗✓✓✓✓✗✗✗✗✗
`bnymellon`✓✓✓✗✗✗✗✗✓✓✗✓
`bridgetower`✓✓✓✓✓✓✗✗✓✓✗✓
`capapp`✓✓✓✓✓✓✓✓✓✓✓✓
`cashlink`✗✗✗✓✓✓✗✗✓✗✗✓
`centrifuge`✓✓✓✓✓✓✓✓✓✓✓✓
`circle`✓✓✓✓✓✓✓✓✓✓✓✓
`coinbase`✓✓✓✓✓✓✓✗✓✓✓✓
`coinshift`✓✓✓✓✓✓✓✓✓✓✓✓
`colbfinance`✗✗✗✓✓✓✗✗✗✗✗✗
`comtech`✓✓✓✓✓✓✓✗✓✓✓✓
`cosimo`✗✗✗✓✓✓✗✗✓✗✗✓
`cropto`✓✓✓✓✓✓✗✗✓✓✗✓
`ctrlalt`✗✗✗✓✓✓✗✗✓✗✗✓
`curve`✓✓✓✓✓✓✓✓✓✓✓✓
`digift`✓✓✓✓✓✓✗✗✓✓✓✓
`digishare`✓✓✓✓✓✓✗✗✓✓✗✓
`dinari`✓✓✓✓✓✓✓✗✓✓✓✓
`dtrinity`✗✗✗✓✓✓✗✓✓✗✗✓
`elixir`✗✗✗✓✓✓✓✗✗✗✗✗
`ethena`✓✓✓✓✓✓✓✓✓✓✓✓
`etherfi`✓✓✓✓✓✓✓✓✓✓✓✓
`etherfuse`✓✓✓✓✓✓✓✗✓✓✓✓
`evident`✓✓✓✓✓✓✗✗✓✓✓✓
`falconfinance`✓✓✓✓✓✓✓✓✓✓✓✓
`fei`✓✓✓✓✓✓✓✗✓✓✓✓
`fidelity`✓✓✓✓✓✓✗✗✓✓✓✓
`figure`✓✓✓✓✓✓✓✗✓✓✓✓
`finest`✗✗✗✓✓✓✗✗✗✗✗✗
`flyingtulip`✓✓✓✓✓✓✓✗✓✓✓✓
`franklintempleton`✓✓✓✓✓✓✗✗✓✓✓✓
`frax`✓✓✓✓✓✓✓✗✓✓✓✓
`fraxstablecoin`✓✓✓✓✓✓✓✓✓✓✓✓
`fxprotocol`✓✓✓✓✓✓✓✓✓✓✓✓
`gaib`✓✓✓✓✓✓✓✗✓✓✓✓
`galaxydigital`✗✗✗✓✓✓✗✗✓✗✗✓
`gauntlet`✓✓✓✓✓✓✓✓✓✓✓✓
`goldfishgold`✓✓✓✓✓✓✓✗✓✓✓✓
`groma`✓✓✓✓✓✓✗✗✓✓✓✓
`gyroscope`✗✗✗✓✓✓✗✓✓✗✗✓
`hastra`✓✓✓✓✓✓✓✓✓✓✓✓
`hyperbeat`✓✓✓✓✓✓✓✗✓✓✓✓
`hyperwave`✓✓✓✓✓✓✓✗✓✓✓✓
`infinifi`✗✗✗✓✓✓✓✗✗✗✗✗
`inversefinance`✓✓✓✓✓✓✓✓✓✓✓✓
`iotube`✓✓✓✓✓✓✗✗✓✓✓✓
`isc`✓✓✓✓✓✓✓✗✓✓✓✓
`jpmorgan`✓✓✓✓✓✓✗✗✓✓✓✓
`justoken`✓✓✓✓✓✓✗✗✓✓✓✓
`k3capital`✗✗✗✓✓✓✗✓✓✗✗✓
`kaio`✗✗✗✓✓✓✗✗✓✗✗✓
`kinesis`✓✓✓✓✓✓✓✗✓✓✗✓
`kinka`✓✓✓✓✓✓✓✗✓✓✓✓
`levelprotocol`✗✗✗✓✓✓✓✗✗✗✗✗
`libeara`✓✓✓✓✓✓✗✗✓✓✓✓
`liquity`✓✓✓✓✓✓✓✗✓✓✓✓
`lybra`✓✓✓✓✓✓✓✗✓✓✓✓
`mainstreet`✗✗✗✓✓✓✓✗✗✗✗✗
`makerdao`✓✓✓✓✓✓✓✓✓✓✓✓
`maple`✓✓✓✓✓✓✓✓✓✓✓✓
`matrixdock`✓✓✓✓✓✓✓✗✓✓✓✓
`mercadobitcoin`✗✗✗✓✓✓✗✗✓✗✗✓
`metawealth`✓✓✓✓✓✓✗✗✓✓✓✓
`midas`✓✓✓✓✓✓✓✓✓✓✓✓
`moola`✓✓✓✓✓✓✓✗✓✓✓✓
`mountainprotocol`✓✓✓✓✓✓✓✓✓✓✓✓
`mstable`✗✗✗✓✓✓✗✗✓✗✗✓
`mudigital`✗✗✗✓✓✓✗✗✗✗✗✗
`nest`✓✓✓✓✓✓✓✓✓✓✓✓
`neutrl`✓✓✓✓✓✓✓✓✓✓✓✓
`noon`✓✓✓✓✓✓✓✓✓✓✓✓
`nyala`✓✓✓✓✓✓✗✗✓✓✗✓
`ondo`✓✓✓✓✓✓✓✓✓✓✓✓
`onre`✓✓✓✓✓✓✓✗✓✓✓✓
`openedendigital`✓✓✓✓✓✓✓✓✓✓✓✓
`openstock`✗✗✗✓✓✓✗✗✓✗✗✓
`opentrade`✓✓✓✓✓✓✗✓✓✓✓✓
`origin`✓✓✓✓✓✓✓✗✓✓✓✓
`oro`✓✓✓✓✓✓✓✗✓✓✓✓
`pareto`✓✓✓✓✓✓✓✓✓✓✓✓
`paxos`✓✓✓✓✓✓✓✗✓✓✓✓
`piku`✓✓✓✓✓✓✓✗✓✓✓✓
`pineapple`✗✓✗✓✓✓✗✗✓✗✗✓
`pleasinggold`✓✓✓✓✓✓✓✗✓✓✓✓
`prestocks`✓✓✓✓✓✓✓✗✓✓✓✓
`protos`✗✗✗✓✓✓✗✗✓✗✗✓
`re`✓✓✓✓✓✓✓✓✓✓✓✓
`realfi`✗✗✗✓✓✓✗✗✗✗✗✗
`reality`✓✓✓✓✓✓✓✗✓✓✓✓
`realtyx`✓✓✓✓✓✓✓✗✓✓✗✓
`redswan`✓✗✗✗✗✗✗✗✗✗✗✗
`reental`✓✓✓✓✓✓✗✗✓✓✓✓
`remora`✓✓✓✓✓✓✓✗✓✓✓✓
`republicnote`✓✓✓✓✓✓✗✗✓✓✗✓
`reserve`✓✓✓✓✓✓✓✗✓✓✓✓
`reservoirxyz`✓✓✓✓✓✓✓✗✓✓✓✓
`resolv`✓✓✓✓✓✓✓✗✓✓✓✓
`resupply`✓✓✓✓✓✓✓✓✓✓✓✓
`ringsprotocol`✓✓✓✓✓✓✓✗✓✓✓✓
`rivool`✓✓✓✓✓✓✗✗✓✗✗✓
`robinhood`✓✓✓✓✓✓✓✗✓✓✓✓
`saturn`✓✓✓✓✓✓✓✓✓✓✓✓
`scienceblockchain`✗✗✗✓✓✓✗✗✓✗✗✓
`securitize`✓✓✓✓✓✓✓✓✓✓✓✓
`shift`✓✓✓✓✓✓✗✗✓✓✓✓
`sivo`✗✗✗✓✓✓✗✓✓✗✗✓
`smardex`✗✗✗✓✓✓✓✗✗✗✗✗
`solayer`✓✓✓✓✓✓✓✗✓✓✓✓
`solstice`✓✓✓✓✓✓✓✗✓✓✓✓
`spark`✓✓✓✓✓✓✓✓✓✓✓✓
`spicevc`✗✗✗✓✓✓✗✗✓✗✗✓
`spiko`✓✓✓✓✓✓✓✓✓✓✓✓
`st0x`✓✓✓✓✓✓✓✓✓✓✓✓
`stableslabs`✗✗✗✓✓✓✓✗✗✗✗✗
`stablestock`✓✓✓✓✓✓✓✗✓✓✓✓
`strata`✓✓✓✓✓✓✓✓✓✓✓✓
`stream`✗✗✗✓✓✓✓✗✗✗✗✗
`streamex`✓✓✓✓✓✓✗✗✓✓✓✓
`stusdt`✓✓✓✓✓✓✗✗✓✓✓✓
`superformlabs`✗✗✗✗✗✗✗✗✓✗✗✓
`superstate`✓✓✓✓✓✓✓✓✓✓✓✓
`swarmmarkets`✓✓✓✓✓✓✓✗✓✓✓✓
`sygnum`✓✓✓✓✓✓✗✗✓✓✓✓
`tangible`✗✗✗✓✓✓✗✗✓✗✗✓
`tenbinlabs`✓✓✓✓✓✓✓✓✓✓✓✓
`tessera`✓✓✓✓✓✓✓✗✓✓✓✓
`tether`✓✓✓✓✓✓✓✗✓✓✓✓
`textilecredit`✓✓✓✓✓✓✗✓✓✓✓✓
`theo`✓✓✓✓✓✓✓✓✓✓✓✓
`tokengate`✗✗✗✓✓✓✓✗✗✗✗✗
`tokeny`✓✓✓✓✓✓✗✗✓✓✓✓
`tradable`✓✓✓✓✓✓✗✗✓✓✓✓
`trize`✓✓✓✗✗✗✗✗✓✓✗✓
`tronusdd`✓✓✓✓✓✓✓✓✓✓✓✓
`trystable`✗✗✗✓✓✓✗✗✗✗✗✗
`ubs`✗✗✗✓✓✓✗✗✗✗✗✗
`upshiftfinance`✓✓✓✓✓✓✓✓✓✓✓✓
`usdai`✓✓✓✓✓✓✓✓✓✓✓✓
`usual`✓✓✓✓✓✓✓✓✓✓✓✓
`vnx`✓✓✓✓✓✓✓✗✓✓✓✓
`wisdomtree`✓✓✓✓✓✓✗✗✓✓✓✓
`xstocks`✓✓✓✓✓✓✓✗✓✓✓✓
`xsy`✓✓✓✓✓✓✗✓✓✓✓✓
`yieldfi`✓✓✓✓✓✓✓✓✓✓✓✓
`yieldnest`✓✓✓✓✓✓✓✓✓✓✓✓
`yieldoptimizer`✓✓✓✓✓✓✓✓✓✓✓✓
`yuzu`✓✓✓✓✓✓✓✓✓✓✓✓
`zeconomy`✓✓✓✗✗✗✗✗✓✓✗✓
**Deployment** A deployment is one real-world asset's token contract on one chain, such as `buidl` on `ethereum`. One row per issuer, ticked for every measure its deployments report.
Issuer Circulating market cap Transfer volume Daily active users Weekly active users Monthly active users APY Holders Mints Redemptions Transfer count
`22xfund`✗✗✓✓✓✗✓✗✗✓
`3jane`✓✓✓✓✓✓✓✓✓✓
`a7a5`✓✓✓✓✓✗✓✓✓✓
`aave`✓✓✓✓✓✓✓✓✓✓
`abt`✓✓✓✓✓✗✓✓✓✓
`accountable`✓✓✓✓✓✓✓✓✓✓
`aegis`✗✗✓✓✓✗✗✗✗✗
`aktionariat`✗✗✓✓✓✗✓✗✗✓
`alloyx`✗✗✓✓✓✗✓✗✗✓
`alphaledger`✗✗✓✓✓✗✓✗✗✓
`anchored`✓✓✓✓✓✗✓✓✓✓
`angle`✓✓✓✓✓✓✓✓✓✓
`anzen`✓✓✓✓✓✓✓✓✓✓
`apyx`✓✓✓✓✓✓✓✓✓✓
`archax`✗✗✓✓✓✗✗✗✗✓
`asseto`✓✓✓✓✓✗✓✓✓✓
`aster`✓✓✓✓✓✗✓✓✓✓
`aurus`✗✗✓✓✓✗✓✗✗✓
`auxite`✗✗✓✓✓✗✓✗✗✓
`avalonfinance`✗✗✓✓✓✗✗✗✗✗
`avantprotocol`✗✗✓✓✓✗✗✗✗✗
`backed`✓✓✓✓✓✗✓✓✓✓
`backpack`✓✓✓✓✓✗✓✓✓✓
`balancer`✗✗✓✓✓✗✗✗✗✗
`binance`✓✓✓✓✓✗✓✓✓✓
`bitbond`✓✓✓✓✓✗✓✓✗✓
`bitfi`✗✗✓✓✓✗✗✗✗✗
`bnymellon`✓✓✗✗✗✗✓✓✗✓
`bridgetower`✓✓✓✓✓✗✓✓✗✓
`capapp`✓✓✓✓✓✓✓✓✓✓
`cashlink`✗✗✓✓✓✗✓✗✗✓
`centrifuge`✓✓✓✓✓✓✓✓✓✓
`circle`✓✓✓✓✓✓✓✓✓✓
`coinbase`✓✓✓✓✓✗✓✓✓✓
`coinshift`✓✓✓✓✓✓✓✓✓✓
`colbfinance`✗✗✓✓✓✗✗✗✗✗
`comtech`✓✓✓✓✓✗✓✓✓✓
`cosimo`✗✗✓✓✓✗✓✗✗✓
`cropto`✓✓✓✓✓✗✓✓✗✓
`ctrlalt`✗✗✓✓✓✗✓✗✗✓
`curve`✓✓✓✓✓✓✓✓✓✓
`digift`✓✓✓✓✓✗✓✓✓✓
`digishare`✓✓✓✓✓✗✓✓✗✓
`dinari`✓✓✓✓✓✗✓✓✓✓
`dtrinity`✗✗✓✓✓✓✓✗✗✓
`elixir`✗✗✓✓✓✗✗✗✗✗
`ethena`✓✓✓✓✓✓✓✓✓✓
`etherfi`✓✓✓✓✓✓✓✓✓✓
`etherfuse`✓✓✓✓✓✗✓✓✓✓
`evident`✓✓✓✓✓✗✓✓✓✓
`falconfinance`✓✓✓✓✓✓✓✓✓✓
`fei`✓✓✓✓✓✗✓✓✓✓
`fidelity`✓✓✓✓✓✗✓✓✓✓
`figure`✓✓✓✓✓✗✓✓✓✓
`finest`✗✗✓✓✓✗✗✗✗✗
`flyingtulip`✓✓✓✓✓✗✓✓✓✓
`franklintempleton`✓✓✓✓✓✗✓✓✓✓
`frax`✓✓✓✓✓✗✓✓✓✓
`fraxstablecoin`✓✓✓✓✓✓✓✓✓✓
`fxprotocol`✓✓✓✓✓✓✓✓✓✓
`gaib`✓✓✓✓✓✗✓✓✓✓
`galaxydigital`✗✗✓✓✓✗✓✗✗✓
`gauntlet`✓✓✓✓✓✓✓✓✓✓
`goldfishgold`✓✓✓✓✓✗✓✓✓✓
`groma`✓✓✓✓✓✗✓✓✓✓
`gyroscope`✗✗✓✓✓✓✓✗✗✓
`hastra`✓✓✓✓✓✓✓✓✓✓
`hyperbeat`✓✓✓✓✓✗✓✓✓✓
`hyperwave`✓✓✓✓✓✗✓✓✓✓
`infinifi`✗✗✓✓✓✗✗✗✗✗
`inversefinance`✓✓✓✓✓✓✓✓✓✓
`iotube`✓✓✓✓✓✗✓✓✓✓
`isc`✓✓✓✓✓✗✓✓✓✓
`jpmorgan`✓✓✓✓✓✗✓✓✓✓
`justoken`✓✓✓✓✓✗✓✓✓✓
`k3capital`✗✗✓✓✓✓✓✗✗✓
`kaio`✗✗✓✓✓✗✓✗✗✓
`kinesis`✓✓✓✓✓✗✓✓✗✓
`kinka`✓✓✓✓✓✗✓✓✓✓
`levelprotocol`✗✗✓✓✓✗✗✗✗✗
`libeara`✓✓✓✓✓✗✓✓✓✓
`liquity`✓✓✓✓✓✗✓✓✓✓
`lybra`✓✓✓✓✓✗✓✓✓✓
`mainstreet`✗✗✓✓✓✗✗✗✗✗
`makerdao`✓✓✓✓✓✓✓✓✓✓
`maple`✓✓✓✓✓✓✓✓✓✓
`matrixdock`✓✓✓✓✓✗✓✓✓✓
`mercadobitcoin`✗✗✓✓✓✗✓✗✗✓
`metawealth`✓✓✓✓✓✗✓✓✓✓
`midas`✓✓✓✓✓✓✓✓✓✓
`moola`✓✓✓✓✓✗✓✓✓✓
`mountainprotocol`✓✓✓✓✓✓✓✓✓✓
`mstable`✗✗✓✓✓✗✓✗✗✓
`mudigital`✗✗✓✓✓✗✗✗✗✗
`nest`✓✓✓✓✓✓✓✓✓✓
`neutrl`✓✓✓✓✓✓✓✓✓✓
`noon`✓✓✓✓✓✓✓✓✓✓
`nyala`✓✓✓✓✓✗✓✓✗✓
`ondo`✓✓✓✓✓✓✓✓✓✓
`onre`✓✓✓✓✓✗✓✓✓✓
`openedendigital`✓✓✓✓✓✓✓✓✓✓
`openstock`✗✗✓✓✓✗✓✗✗✓
`opentrade`✓✓✓✓✓✓✓✓✓✓
`origin`✓✓✓✓✓✗✓✓✓✓
`oro`✓✓✓✓✓✗✓✓✓✓
`pareto`✓✓✓✓✓✓✓✓✓✓
`paxos`✓✓✓✓✓✗✓✓✓✓
`piku`✓✓✓✓✓✗✓✓✓✓
`pineapple`✓✗✓✓✓✗✓✗✗✓
`pleasinggold`✓✓✓✓✓✗✓✓✓✓
`prestocks`✓✓✓✓✓✗✓✓✓✓
`protos`✗✗✓✓✓✗✓✗✗✓
`re`✓✓✓✓✓✓✓✓✓✓
`realfi`✗✗✓✓✓✗✗✗✗✗
`reality`✓✓✓✓✓✗✓✓✓✓
`realtyx`✓✓✓✓✓✗✓✓✗✓
`reental`✓✓✓✓✓✗✓✓✓✓
`remora`✓✓✓✓✓✗✓✓✓✓
`republicnote`✓✓✓✓✓✗✓✓✗✓
`reserve`✓✓✓✓✓✗✓✓✓✓
`reservoirxyz`✓✓✓✓✓✗✓✓✓✓
`resolv`✓✓✓✓✓✗✓✓✓✓
`resupply`✓✓✓✓✓✓✓✓✓✓
`ringsprotocol`✓✓✓✓✓✗✓✓✓✓
`rivool`✓✓✓✓✓✗✓✗✗✓
`robinhood`✓✓✓✓✓✗✓✓✓✓
`saturn`✓✓✓✓✓✓✓✓✓✓
`scienceblockchain`✗✗✓✓✓✗✓✗✗✓
`securitize`✓✓✓✓✓✓✓✓✓✓
`shift`✓✓✓✓✓✗✓✓✓✓
`sivo`✗✗✓✓✓✓✓✗✗✓
`smardex`✗✗✓✓✓✗✗✗✗✗
`solayer`✓✓✓✓✓✗✓✓✓✓
`solstice`✓✓✓✓✓✗✓✓✓✓
`spark`✓✓✓✓✓✓✓✓✓✓
`spicevc`✗✗✓✓✓✗✓✗✗✓
`spiko`✓✓✓✓✓✓✓✓✓✓
`st0x`✓✓✓✓✓✓✓✓✓✓
`stableslabs`✗✗✓✓✓✗✗✗✗✗
`stablestock`✓✓✓✓✓✗✓✓✓✓
`strata`✓✓✓✓✓✓✓✓✓✓
`stream`✗✗✓✓✓✗✗✗✗✗
`streamex`✓✓✓✓✓✗✓✓✓✓
`stusdt`✓✓✓✓✓✗✓✓✓✓
`superformlabs`✗✗✗✗✗✗✓✗✗✓
`superstate`✓✓✓✓✓✓✓✓✓✓
`swarmmarkets`✓✓✓✓✓✗✓✓✓✓
`sygnum`✓✓✓✓✓✗✓✓✓✓
`tangible`✗✗✓✓✓✗✓✗✗✓
`tenbinlabs`✓✓✓✓✓✓✓✓✓✓
`tessera`✓✓✓✓✓✗✓✓✓✓
`tether`✓✓✓✓✓✗✓✓✓✓
`textilecredit`✓✓✓✓✓✓✓✓✓✓
`theo`✓✓✓✓✓✓✓✓✓✓
`tokengate`✗✗✓✓✓✗✗✗✗✗
`tokeny`✓✓✓✓✓✗✓✓✓✓
`tradable`✓✓✓✓✓✗✓✓✓✓
`trize`✓✓✗✗✗✗✓✓✗✓
`tronusdd`✓✓✓✓✓✓✓✓✓✓
`trystable`✗✗✓✓✓✗✗✗✗✗
`ubs`✗✗✓✓✓✗✗✗✗✗
`upshiftfinance`✓✓✓✓✓✓✓✓✓✓
`usdai`✓✓✓✓✓✓✓✓✓✓
`usual`✓✓✓✓✓✓✓✓✓✓
`vnx`✓✓✓✓✓✗✓✓✓✓
`wisdomtree`✓✓✓✓✓✗✓✓✓✓
`xstocks`✓✓✓✓✓✗✓✓✓✓
`xsy`✓✓✓✓✓✓✓✓✓✓
`yieldfi`✓✓✓✓✓✓✓✓✓✓
`yieldnest`✓✓✓✓✓✓✓✓✓✓
`yieldoptimizer`✓✓✓✓✓✓✓✓✓✓
`yuzu`✓✓✓✓✓✓✓✓✓✓
`zeconomy`✓✓✗✗✗✗✓✓✗✓
**Chains** Every chain the section covers.
Chain Issuers
`algorand``securitize`
`aptos``ethena`, `franklintempleton`, `kaio`, `ondo`, `pactfoundation`, `securitize`
`arbitrum``alloyx`, `anchored`, `angle`, `anzen`, `backed`, `centrifuge`, `dinari`, `ethena`, `franklintempleton`, `frax`, `fraxstablecoin`, `gauntlet`, `gyroscope`, `libeara`, `lybra`, `makerdao`, `maple`, `matrixdock`, `mountainprotocol`, `nest`, `ondo`, `openedendigital`, `pleasinggold`, `reality`, `reserve`, `reservoirxyz`, `resolv`, `robinhood`, `securitize`, `spiko`, `stableslabs`, `sygnum`, `tether`, `theo`, `usdai`, `usual`, `wisdomtree`, `xstocks`, `yieldfi`
`avalanche``asseto`, `avantprotocol`, `backed`, `bridgetower`, `centrifuge`, `dinari`, `ethena`, `franklintempleton`, `galaxydigital`, `gyroscope`, `kaio`, `libeara`, `mountainprotocol`, `opentrade`, `re`, `republicnote`, `reservoirxyz`, `securitize`, `stream`, `tether`, `tokeny`, `wisdomtree`
`base``anchored`, `anzen`, `apyx`, `auxite`, `avalonfinance`, `backed`, `centrifuge`, `coinbase`, `dinari`, `ethena`, `etherfuse`, `franklintempleton`, `gauntlet`, `groma`, `hyperwave`, `makerdao`, `maple`, `midas`, `mountainprotocol`, `openedendigital`, `openstock`, `re`, `realfinance`, `realtyx`, `reserve`, `reservoirxyz`, `resolv`, `spiko`, `st0x`, `stableslabs`, `streamex`, `swarmmarkets`, `tangible`, `textilecredit`, `theo`, `tokeny`, `trize`, `vnx`, `wisdomtree`, `xsy`, `yieldfi`, `yieldoptimizer`
`berachain``ethena`, `reservoirxyz`, `resolv`
`blast``anzen`, `dinari`, `ethena`
`bsc``asseto`, `aster`, `avalonfinance`, `binance`, `centrifuge`, `circle`, `colbfinance`, `digift`, `ethena`, `franklintempleton`, `frax`, `matrixdock`, `midas`, `ondo`, `openedendigital`, `reserve`, `reservoirxyz`, `resolv`, `securitize`, `stableslabs`, `stablestock`, `swarmmarkets`, `tether`, `tronusdd`, `xstocks`
`cardano``finest`, `kinka`, `realfi`
`celo``centrifuge`, `moola`, `mountainprotocol`, `tether`, `textilecredit`
`ethereum``22xfund`, `3jane`, `a7a5`, `aave`, `abt`, `aegis`, `aktionariat`, `alloyx`, `anchored`, `angle`, `anzen`, `apyx`, `asseto`, `aurus`, `avalonfinance`, `backed`, `bitfi`, `bnymellon`, `capapp`, `centrifuge`, `circle`, `coinshift`, `cosimo`, `curve`, `diamondstandard`, `digift`, `digishare`, `dinari`, `elixir`, `ethena`, `etherfi`, `falconfinance`, `fei`, `fidelity`, `flyingtulip`, `franklintempleton`, `frax`, `fraxstablecoin`, `fxprotocol`, `gaib`, `gauntlet`, `goldfishgold`, `gyroscope`, `hastra`, `hyperwave`, `infinifi`, `inversefinance`, `jpmorgan`, `k3capital`, `kaio`, `kinesis`, `kinka`, `levelprotocol`, `libeara`, `liquity`, `lybra`, `mainstreet`, `makerdao`, `maple`, `matrixdock`, `mercadobitcoin`, `metawealth`, `midas`, `mountainprotocol`, `mstable`, `nest`, `neutrl`, `noon`, `ondo`, `openedendigital`, `openstock`, `opentrade`, `origin`, `pareto`, `paxos`, `piku`, `protos`, `re`, `reserve`, `reservoirxyz`, `resolv`, `resupply`, `ringsprotocol`, `saturn`, `scienceblockchain`, `securitize`, `sivo`, `smardex`, `spicevc`, `spiko`, `stableslabs`, `strata`, `stream`, `stusdt`, `superformlabs`, `superstate`, `swarmmarkets`, `tangible`, `tenbinlabs`, `tether`, `textilecredit`, `theo`, `tronusdd`, `ubs`, `upshiftfinance`, `usdai`, `usual`, `vnx`, `wisdomtree`, `xstocks`, `yieldfi`, `yieldnest`, `zeconomy`
`fraxtal``frax`, `fraxstablecoin`
`gnosis``angle`, `backed`, `balancer`
`hedera``archax`, `diamondstandard`, `kaio`
`hyperevm``dinari`, `ethena`, `hyperbeat`, `hyperwave`, `reservoirxyz`, `resolv`, `swarmmarkets`, `tether`, `theo`, `xstocks`
`injective``pineapple`
`ink``reserve`, `securitize`, `tether`, `xstocks`
`iotex``iotube`
`katananetwork``capapp`, `fraxstablecoin`, `midas`, `yieldfi`
`linea``ethena`
`manta``ethena`
`mantle``ondo`, `securitize`, `xstocks`
`mantraevm``cropto`
`megaeth``capapp`, `ethena`
`monad``accountable`, `anchored`, `centrifuge`, `ethena`, `etherfuse`, `midas`, `mudigital`, `tether`, `yuzu`
`near``circle`, `kaio`
`optimism``aktionariat`, `centrifuge`, `ethena`, `etherfi`, `gauntlet`, `gyroscope`, `makerdao`, `midas`, `mountainprotocol`, `securitize`, `tangible`, `wisdomtree`, `xstocks`, `yieldfi`
`plasma``ethena`, `maple`, `midas`, `nest`, `resolv`, `stream`, `swarmmarkets`, `tether`, `usdai`, `yuzu`
`plumenetwork``centrifuge`, `nest`, `wisdomtree`, `yieldfi`
`polygon``aktionariat`, `alloyx`, `backed`, `cashlink`, `cropto`, `etherfuse`, `evident`, `franklintempleton`, `gyroscope`, `justoken`, `kaio`, `matrixdock`, `mercadobitcoin`, `mountainprotocol`, `nyala`, `ondo`, `reental`, `securitize`, `spiko`, `swarmmarkets`, `tokengate`, `vnx`
`ripple``ctrlalt`, `justoken`, `ondo`, `openedendigital`, `vertcapital`, `zeconomy`
`robinhoodchain``ethena`, `maple`, `robinhood`, `spark`
`rootstock``mercadobitcoin`, `midas`
`seievm``fraxstablecoin`, `kaio`, `ondo`, `reservoirxyz`, `securitize`
`solana``alphaledger`, `backpack`, `centrifuge`, `circle`, `ctrlalt`, `digift`, `ethena`, `etherfuse`, `figure`, `franklintempleton`, `galaxydigital`, `hastra`, `isc`, `kaio`, `libeara`, `maple`, `matrixdock`, `metawealth`, `nest`, `ondo`, `onre`, `openedendigital`, `openstock`, `oro`, `prestocks`, `remora`, `republicnote`, `reservoirxyz`, `securitize`, `shift`, `solayer`, `solstice`, `spiko`, `superstate`, `tessera`, `tether`, `trystable`, `usual`, `vnx`, `wisdomtree`, `xstocks`
`sonic``backed`, `dtrinity`, `flyingtulip`, `fraxstablecoin`, `mainstreet`, `reservoirxyz`, `ringsprotocol`, `yieldfi`
`starknet``midas`, `noon`, `spiko`
`stellar``bitbond`, `centrifuge`, `etherfuse`, `figure`, `franklintempleton`, `nyala`, `ondo`, `redswan`, `rivool`, `spiko`, `wisdomtree`
`sui``matrixdock`, `ondo`, `securitize`
`tempo``capapp`, `ethena`, `infinifi`, `re`, `reservoirxyz`, `securitize`
`ton``xstocks`
`tron``matrixdock`, `securitize`, `stusdt`
`unichain``makerdao`, `reservoirxyz`
`worldchain``reservoirxyz`
`xdc``archax`, `comtech`, `curve`, `kaio`, `securitize`
`xlayer``xstocks`
`zksyncera``ethena`, `mountainprotocol`, `noon`, `securitize`, `sygnum`, `tradable`
## Tables [Metrics](/docs/catalog/real-world-assets/metrics) holds the daily table schemas at each grain and example queries. [Registry](/docs/catalog/real-world-assets/registry) holds the identity tables: the assets, the chains each is issued on, and the reference assets they stand for. [Disclosures](/docs/catalog/real-world-assets/disclosures) holds the issuer-disclosed legal, regulatory and market terms of each asset, one row per asset with the evidence behind every value. # Metrics Source: https://tokenterminal.com/docs/catalog/real-world-assets/metrics Daily real-world asset supply, holders, transfer activity, price and yield. Circulating market cap, price, yield, holders, mints, redemptions and transfer activity. One row per thing per day, at three grains: asset, asset and chain, and deployment. ## Tables A tab per grain. [Coverage](/docs/catalog/real-world-assets) shows which issuers report which measure. **Asset** One row per asset per day. Price and yield belong to the asset itself; every other measure is the asset's deployments added together.
Table Value column What it holds
`metrics_assets.price_daily``price`Asset price in USD (canonical across sources).
`metrics_assets.app_tvl_daily``app_tvl`Value of the asset deposited into onchain apps -- lending markets, DEX pools and vaults
`metrics_assets.app_trading_volume_daily``app_trading_volume`Value of spot trades involving the asset on onchain venues -- DEX pools and onchain order books -- USD
`metrics_assets.apy_daily``apy`Annualized yield, native-market-cap-weighted across deployments.
`metrics_assets.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of natively-issued deployments only.
`metrics_assets.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of bridged deployments only, wrapped representations of supply issued elsewhere.
`metrics_assets.market_cap_circulating_daily``market_cap_circulating`Circulating market cap across every representation of the asset, native issuance plus bridged wrappers plus any off-chain component.
`metrics_assets.market_cap_circulating_offchain_daily``market_cap_circulating_offchain`Circulating market cap the issuer reports off-chain, the portion of a fund's NAV no token contract represents.
`metrics_assets.holders_daily``holders`Distinct holders summed across every deployment of the asset; an address on two chains counts twice.
`metrics_assets.holders_native_daily``holders_native`Distinct holders across the asset's natively-issued deployments only.
`metrics_assets.holders_bridged_daily``holders_bridged`Distinct holders across the asset's bridged deployments only.
`metrics_assets.mints_native_daily``mints_native`Value minted (issued) on natively-issued deployments only.
`metrics_assets.mints_bridged_daily``mints_bridged`Value minted (issued) on bridged deployments only.
`metrics_assets.mints_daily``mints`Value minted (issued) across every deployment; a bridged mint is a distinct event, so this is a real total.
`metrics_assets.redemptions_native_daily``redemptions_native`Value redeemed (burned) on natively-issued deployments only.
`metrics_assets.redemptions_bridged_daily``redemptions_bridged`Value redeemed (burned) on bridged deployments only.
`metrics_assets.redemptions_daily``redemptions`Value redeemed (burned) across every deployment; a bridged burn is a distinct event, so this is a real total.
`metrics_assets.transfer_count_native_daily``transfer_count_native`Number of transfers on natively-issued deployments only.
`metrics_assets.transfer_count_bridged_daily``transfer_count_bridged`Number of transfers on bridged deployments only.
`metrics_assets.transfer_count_daily``transfer_count`Number of transfers across every deployment; a bridged transfer is a distinct event, so this is a real total.
`metrics_assets.transfer_volume_native_daily``transfer_volume_native`Value transferred on natively-issued deployments only.
`metrics_assets.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on bridged deployments only.
`metrics_assets.transfer_volume_daily``transfer_volume`Value transferred across every deployment; a bridged transfer is a distinct event, so this is a real total.
`metrics_assets.daily_active_users_daily``daily_active_users`Distinct addresses sending the asset on the day, across every deployment.
`metrics_assets.weekly_active_users_daily``weekly_active_users`Distinct addresses sending the asset in the trailing 7 days, across every deployment.
`metrics_assets.monthly_active_users_daily``monthly_active_users`Distinct addresses sending the asset in the trailing 30 days, across every deployment.
**Asset and chain** One row per asset per chain per day. Keyed on `asset_chain_id` and `timestamp`, which is written `{asset_id}-{chain_id}` and joins `dimensions.assets_by_chain`. Every measure rolls up the asset's deployments on that chain.
Table Value column What it holds
`metrics_assets_by_chain.apy_daily``apy`Annualized yield, native-market-cap-weighted across deployments
`metrics_assets_by_chain.app_tvl_daily``app_tvl`Value of the asset deposited into onchain apps -- lending markets, DEX pools and vaults
`metrics_assets_by_chain.app_trading_volume_daily``app_trading_volume`Value of spot trades involving the asset on onchain venues -- DEX pools and onchain order books -- USD
`metrics_assets_by_chain.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of natively-issued deployments only
`metrics_assets_by_chain.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of bridged deployments only, wrapped representations of supply issued elsewhere
`metrics_assets_by_chain.market_cap_circulating_daily``market_cap_circulating`Circulating market cap of the asset on the chain, USD, summed across every deployment there, native and bridged.
`metrics_assets_by_chain.holders_daily``holders`Distinct holders summed across every deployment of the asset, native and bridged
`metrics_assets_by_chain.holders_native_daily``holders_native`Distinct holders across the asset's natively-issued deployments only
`metrics_assets_by_chain.holders_bridged_daily``holders_bridged`Distinct holders across the asset's bridged deployments only
`metrics_assets_by_chain.mints_native_daily``mints_native`Value minted (issued) on natively-issued deployments only
`metrics_assets_by_chain.mints_bridged_daily``mints_bridged`Value minted (issued) on bridged deployments only
`metrics_assets_by_chain.mints_daily``mints`Value minted (issued) across every deployment; a bridged mint is a distinct event, so this is a real total
`metrics_assets_by_chain.redemptions_native_daily``redemptions_native`Value redeemed (burned) on natively-issued deployments only
`metrics_assets_by_chain.redemptions_bridged_daily``redemptions_bridged`Value redeemed (burned) on bridged deployments only
`metrics_assets_by_chain.redemptions_daily``redemptions`Value redeemed (burned) across every deployment; a bridged burn is a distinct event, so this is a real total
`metrics_assets_by_chain.transfer_count_native_daily``transfer_count_native`Number of transfers on natively-issued deployments only
`metrics_assets_by_chain.transfer_count_bridged_daily``transfer_count_bridged`Number of transfers on bridged deployments only
`metrics_assets_by_chain.transfer_count_daily``transfer_count`Number of transfers across every deployment; a bridged transfer is a distinct event, so this is a real total
`metrics_assets_by_chain.transfer_volume_native_daily``transfer_volume_native`Value transferred on natively-issued deployments only
`metrics_assets_by_chain.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on bridged deployments only
`metrics_assets_by_chain.transfer_volume_daily``transfer_volume`Value transferred across every deployment; a bridged transfer is a distinct event, so this is a real total
`metrics_assets_by_chain.daily_active_users_daily``daily_active_users`Distinct addresses sending the asset on the day, across every deployment
`metrics_assets_by_chain.weekly_active_users_daily``weekly_active_users`Distinct addresses sending the asset in the trailing 7 days, across every deployment
`metrics_assets_by_chain.monthly_active_users_daily``monthly_active_users`Distinct addresses sending the asset in the trailing 30 days, across every deployment
**Deployment** One row per deployment per day. Each deployment is either natively issued or bridged in, and its rows sit in the matching `_native` or `_bridged` tables.
Table Value column What it holds
`metrics_asset_tokens.apy_daily``apy`Annualized yield of the deployment.
`metrics_asset_tokens.app_tvl_daily``app_tvl`Value of the deployment deposited into onchain apps -- lending markets, DEX pools and vaults
`metrics_asset_tokens.app_trading_volume_daily``app_trading_volume`Value of spot trades involving the deployment on onchain venues -- DEX pools and onchain order books -- USD, all venues together
`metrics_asset_tokens.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of the deployment; natively-issued deployments only.
`metrics_asset_tokens.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of the deployment; bridged deployments only, wrapped representations of supply issued elsewhere.
`metrics_asset_tokens.market_cap_circulating_daily``market_cap_circulating`Circulating market cap of the deployment, native or bridged.
`metrics_asset_tokens.holders_daily``holders`Addresses holding a non-zero balance of the deployment, native or bridged.
`metrics_asset_tokens.holders_native_daily``holders_native`Addresses holding a non-zero balance of the deployment; natively-issued deployments only.
`metrics_asset_tokens.holders_bridged_daily``holders_bridged`Addresses holding a non-zero balance of the deployment; bridged deployments only.
`metrics_asset_tokens.mints_native_daily``mints_native`Value minted (issued) on the deployment; natively-issued deployments only.
`metrics_asset_tokens.mints_bridged_daily``mints_bridged`Value minted (issued) on the deployment; bridged deployments only.
`metrics_asset_tokens.mints_daily``mints`Value minted (issued) on the deployment, native or bridged.
`metrics_asset_tokens.redemptions_native_daily``redemptions_native`Value redeemed (burned) on the deployment; natively-issued deployments only.
`metrics_asset_tokens.redemptions_bridged_daily``redemptions_bridged`Value redeemed (burned) on the deployment; bridged deployments only.
`metrics_asset_tokens.redemptions_daily``redemptions`Value redeemed (burned) on the deployment, native or bridged.
`metrics_asset_tokens.transfer_count_native_daily``transfer_count_native`Transfers on the deployment; natively-issued deployments only.
`metrics_asset_tokens.transfer_count_bridged_daily``transfer_count_bridged`Transfers on the deployment; bridged deployments only.
`metrics_asset_tokens.transfer_count_daily``transfer_count`Transfers on the deployment, native or bridged.
`metrics_asset_tokens.transfer_volume_native_daily``transfer_volume_native`Value transferred on the deployment; natively-issued deployments only.
`metrics_asset_tokens.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on the deployment; bridged deployments only.
`metrics_asset_tokens.transfer_volume_daily``transfer_volume`Value transferred on the deployment, native or bridged.
`metrics_asset_tokens.daily_active_users_native_daily``daily_active_users_native`Distinct addresses sending the deployment's token on the day; natively-issued deployments only.
`metrics_asset_tokens.daily_active_users_bridged_daily``daily_active_users_bridged`Distinct addresses sending the deployment's token on the day; bridged deployments only.
`metrics_asset_tokens.weekly_active_users_native_daily``weekly_active_users_native`Distinct addresses sending the deployment's token in the trailing 7 days; natively-issued deployments only.
`metrics_asset_tokens.weekly_active_users_bridged_daily``weekly_active_users_bridged`Distinct addresses sending the deployment's token in the trailing 7 days; bridged deployments only.
`metrics_asset_tokens.monthly_active_users_native_daily``monthly_active_users_native`Distinct addresses sending the deployment's token in the trailing 30 days; natively-issued deployments only.
`metrics_asset_tokens.monthly_active_users_bridged_daily``monthly_active_users_bridged`Distinct addresses sending the deployment's token in the trailing 30 days; bridged deployments only.
## Sample queries **One fund's daily read** Each measure is its own table, so a row with all three is a join on `asset_id` and `timestamp`, bounded on each side. Join with `full join`: a fund can publish a price on a day no supply figure landed. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` where asset_id = 'buidl' and timestamp >= timestamp('2026-06-01') ), price as ( select timestamp, price from `metrics_assets.price_daily` where asset_id = 'buidl' and timestamp >= timestamp('2026-06-01') ), yield as ( select timestamp, apy from `metrics_assets.apy_daily` where asset_id = 'buidl' and timestamp >= timestamp('2026-06-01') ) select timestamp, supply.market_cap_circulating_native, price.price, yield.apy from supply full join price using (timestamp) full join yield using (timestamp) order by timestamp ``` **Tokenized stocks by supply** The metric tables hold every asset type, so the type filter comes from `dimensions.assets` on the join. `market_cap_circulating_native` counts the supply the issuer minted, the figure for how much of the instrument exists. ```sql theme={null} select assets.asset_id, assets.symbol, daily.market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` as daily join `dimensions.assets` as assets using (asset_id) where daily.timestamp = timestamp('2026-08-01') and assets.asset_type = 'tokenized-stocks' order by daily.market_cap_circulating_native desc limit 25 ``` **One issuer's book** `issuer_project_id` is the project holding the `issuer` relation, and it is the column the coverage matrix groups on. The supply side is a `left join`: an asset enters the registry on the day it is listed, ahead of its first daily figure. ```sql theme={null} select assets.asset_id, assets.symbol, assets.asset_type, daily.market_cap_circulating from `dimensions.assets` as assets left join `metrics_assets.market_cap_circulating_daily` as daily on daily.asset_id = assets.asset_id and daily.timestamp = timestamp('2026-08-01') where assets.issuer_project_id = 'securitize' and assets.asset_type in ( 'tokenized-stocks', 'tokenized-funds', 'tokenized-commodities' ) order by daily.market_cap_circulating desc ``` **One asset across chains** `asset_token_id` is the deployment key, and `dimensions.asset_tokens` has the chain and the `bridged_status` behind it. The deployment rows of an additive measure add back up to the asset row. ```sql theme={null} select deployments.chain_id, deployments.bridged_status, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) where daily.timestamp = timestamp('2026-08-01') and deployments.asset_id = 'buidl' order by daily.market_cap_circulating desc ``` **Chains by real-world asset supply** Summing the native table across deployments counts each unit of supply once, because a bridged wrapper stands for supply already minted somewhere else. The type filter needs both dimension tables: the chain sits on the deployment, the type on the asset. ```sql theme={null} select deployments.chain_id, count(distinct deployments.asset_id) as instruments, sum(daily.market_cap_circulating_native) as native_supply from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) join `dimensions.assets` as assets using (asset_id) where daily.timestamp = timestamp('2026-08-01') and assets.asset_type in ( 'tokenized-stocks', 'tokenized-funds', 'tokenized-commodities' ) group by deployments.chain_id order by native_supply desc ``` **Yield across a type** A rate needs a weight before it reads across assets. Native circulating supply is that weight, the one `apy` is weighted by across the asset's deployments. ```sql theme={null} select daily.timestamp, sum(daily.apy * supply.market_cap_circulating_native) / sum(supply.market_cap_circulating_native) as weighted_apy from `metrics_assets.apy_daily` as daily join `metrics_assets.market_cap_circulating_native_daily` as supply using (asset_id, timestamp) join `dimensions.assets` as assets on assets.asset_id = daily.asset_id where assets.asset_type = 'tokenized-funds' and daily.timestamp >= timestamp('2026-08-01') group by daily.timestamp order by daily.timestamp ``` # Registry Source: https://tokenterminal.com/docs/catalog/real-world-assets/registry Real-world asset identity and the reference assets the tokens stand for. The identity tables behind every real-world asset figure. Every metric joins to one of them, and [Coverage](/docs/catalog/real-world-assets) introduces each grain. ## Tables **Assets** One row per real-world asset: `dimensions.assets` filtered on the three `tokenized-*` `asset_type` values: stocks, funds and commodities.
Column Type Description
`asset_id` `STRING` Identifier of the asset, for example `usdc`.
`reference_asset_id` `STRING` What the asset tracks or wraps. Joins `dimensions.reference_assets`.
`name` `STRING` Display name of the asset.
`symbol` `STRING` Ticker symbol of the asset.
`asset_type` `STRING` What kind of instrument it is: `stablecoin`, `tokenized-stocks`, `tokenized-funds`, `lending-token`, `tokenized-commodities`, `liquid-staking-token`, `tokenized-cryptoasset` or `wrapped_native`.
`description` `STRING` Short description of the asset.
`custom_price_fx_peg` `STRUCT` A fixed rate the asset is priced at rather than a market quote, in `currency`, `multiplier` and `priority`. Set only where the asset declares one, and `priority` says whether the rate overrides the market price or only fills in where there is none.
`created_at` `TIMESTAMP` When the asset entered the registry.
`metrics_verified_at` `TIMESTAMP` When the asset's published metrics were last verified. Null while unverified.
`mica_marker` `STRING` Which MiCA category the peg implies: `emt_by_peg` for single-currency stablecoins, `art_by_peg` for other stablecoins, `other_crypto_asset` or `out_of_scope_financial_instrument` for everything else. A marker, not a regulatory ruling.
`mica_authorization_status` `STRING` Whether the token is authorized under MiCA according to the official register: `emt_authorized`, `art_authorized`, `not_authorized`, `application_withdrawn`, `out_of_scope_mifid`, `other_crypto_asset` or `not_checked`. A sourced regulatory fact, unlike `mica_marker`, which is read off the peg.
`regulatory_supervised` `STRING` What the issuer discloses about its own supervision: `true`, `false` or `unknown`. A disclosure, never an inference.
`regulator` `STRING` The authority the issuer names as its supervisor, such as `NYDFS/FinCEN`. Empty where the issuer names none.
`reserves_source` `STRING` Where the reserve figure comes from: `attestation` for an issuer-published report, `onchain` where the backing addresses are identified and the balance computed here, `none` where the issuer publishes nothing.
`reserves_attestor` `STRING` The firm signing the attestation, filled in where `reserves_source` is `attestation`.
`return_treatment` `STRING` How the token treats the income the underlying pays: `total_return`, `price_return`, `price_return_with_distribution` or `not_applicable`. Keyed on the token rather than on what it tracks, so two tokenizations of one share can differ.
`issuer_legal_name` `STRING` The issuing entity as a government register spells it, which is routinely not the brand.
`issuer_domicile` `STRING` ISO 3166-1 alpha-2 country code of where the issuing entity is registered, such as `US`. Resolved from the issuing project, so it is null when that project has no domicile on file.
`issuer_lei` `STRING` Legal Entity Identifier of the issuing entity.
`issuer_cik` `STRING` SEC Central Index Key of the issuing entity.
`issuer_regulatory_framework` `ARRAY` Regimes the issuing entity operates under. An array because an entity can sit under several at once.
`issuer_legal_source_url` `STRING` The filing or register the legal fields above were read from, with `issuer_legal_retrieved_at` recording when.
`issuer_legal_retrieved_at` `STRING` When `issuer_legal_source_url` was last read.
`use_of_income` `STRING` What the issuer says it does with the income the underlying pays, in its own words. `return_treatment` is the coded answer to the same question.
`isin` `STRING` International Securities Identification Number of the instrument, where it has one.
`cusip` `STRING` CUSIP of the instrument, where it has one.
`peg_currency` `STRING` ISO currency code of the peg, set when the asset tracks a national currency. Empty otherwise: a fund strategy, a share or a commodity is not a peg.
`project_relations` `ARRAY` Every project linked to the asset, one element per `(project_id, relation)`. `relation` is `issuer`, `asset_manager`, `risk_curator` or `manager`. Most assets link to one project; a few link to several, such as an issuer alongside a separate manager.
`issuer_project_id` `STRING` The project whose relation is `issuer`, when exactly one project holds that relation. Empty when none do, and empty when more than one does; read `project_relations` for the full set.
`coingecko_id` `STRING` Identifier of the same asset in the CoinGecko catalogue, for joining our record to a public one.
`coinmarketcap_id` `STRING` Identifier of the same asset in the CoinMarketCap catalogue, for the same purpose.
`yahoo_ticker` `STRING` Ticker the underlying trades under on Yahoo Finance, where it is listed.
**Asset tokens** One row per chain an asset is issued on, in `dimensions.asset_tokens`. `bridged_status` says whether the supply was minted there or bridged in.
Column Type Description
`asset_token_id` `STRING` Identifier of the deployment, formatted `{asset_id}-{token_address}-{chain_id}`.
`asset_id` `STRING` Asset the deployment belongs to. Joins `dimensions.assets`.
`token_id` `STRING` Key of the deployment in `dimensions.tokens`, formatted `{token_address}-{chain_id}`.
`chain_id` `STRING` Chain the contract is deployed on.
`token_address` `STRING` Address of the token contract.
`is_bridged` `BOOL` Raw registry flag: bridged in rather than issued natively. Always present, so `false` means native or unstated. Filter on `bridged_status` instead.
`bridged_status` `STRING` The classification supply measures split on: `native`, `bridged` or `unclassified`.
`token_standard` `STRING` Token standard of the contract, such as `erc20`, `erc3643` or `spl`. Null where not yet read.
`token_extensions` `ARRAY` Traits riding on top of `token_standard`, such as `fiat_token_blacklist` or `transfer_hook`. Empty, not null, when none are detected.
`token_extensions_coverage` `STRING` Whether an extension detector ran for this deployment: `probed`, so an empty `token_extensions` means none were found; `not_probed`, a detector exists but could not reach the chain; or `no_detector`, none exists for the standard. In the last two the extensions are unknown rather than absent.
`token_permissions` `ARRAY` Normalized capability ids the standard or its extensions imply, such as `freeze_addresses` or `seize_funds`. Can hold several. Empty, not null, when none apply. The label and definition of each id, and of every other column here, are rows of `dimensions.asset_token_fields`.
`decimals` `INT64` Token precision. Null where not yet read.
`first_issued_onchain` `DATE` Date of the first mint of this deployment. Null where not yet read.
**Reference assets** One row per thing a real-world asset stands for, in `dimensions.reference_assets`, classified in `type`. Some references are broad categories, such as `etf` and `fund_strategy`, and an asset pointing at one stands for the category while its own name says which instrument it wraps.
Column Type Description
`reference_asset_id` `STRING` Identifier of the thing being tracked.
`linked_asset_id` `STRING` Its own tokenized asset in `dimensions.assets`, where one exists.
`name` `STRING` Display name.
`symbol` `STRING` Ticker symbol.
`type` `STRING` What kind of thing it is: `stock`, `crypto`, `fiat`, `pendle_pt`, `etf`, `commodity`, `fund_strategy`, `bond` or `other`.
`currency_code` `STRING` ISO currency code, filled in only on the `fiat` rows.
`unit` `STRING` The physical unit a commodity is quoted in, for example `troy ounce` or `barrel`. Empty on everything else.
`aliases` `ARRAY` Other names it is known by.
`yahoo_ticker` `STRING` Ticker the reference trades under on Yahoo Finance, where it is listed.
**Disclosure fields** One row per disclosure field of `dimensions.asset_disclosures`: the section heading, label and definition shown next to each disclosed term, and the definition of each closed-set value, in display order.
Column Type Description
`field_id` `STRING` The column of `dimensions.asset_disclosures` this row describes, such as `claim_type`.
`section_id` `STRING` Key of the section the field sits in: `identity`, `legal`, `providers`, `primary_market`, `identifiers` or `underlying`.
`section_title` `STRING` Heading shown above the section, such as `Legal and regulatory`.
`section_order` `INT64` Position of the section, from 1.
`field_order` `INT64` Position of the field within its section, from 1.
`title` `STRING` Label of the field, such as `Claim type`.
`definition` `STRING` One-sentence definition shown with the label.
`values` `ARRAY` One element per value a closed-set field can hold: `value` as stored in the column, `title`, its short display name, and `definition`, the sentence that explains it. Empty for a free-text field.
`inserted_at` `TIMESTAMP` When the registry snapshot behind the row was published.
**Underlying securities** One row per security a tokenized asset references, keyed by ISIN, with the values looked up for it in public registers (OpenFIGI, GLEIF, SEC EDGAR). An asset links to its row through `underlying_security_id` and `underlying_isin` on `dimensions.asset_disclosures`.
Column Type Description
`security_id` `STRING` Identifier of the security, formatted `{ticker}-{isin}` or `{class}-{isin}`, such as `1-kyg217651051`. Joins `dimensions.asset_disclosures.underlying_security_id`.
`security_class` `STRING` `equity` or `etf`.
`looked_up_at` `TIMESTAMP` When the register values were fetched. Null before the first lookup.
`inserted_at` `TIMESTAMP` When the registry snapshot behind the row was published.
`isin` `STRING` ISIN of the security. Joins `dimensions.asset_disclosures.underlying_isin`.
`name` `STRING` Security name as OpenFIGI records it for this ISIN, such as `BERKSHIRE HATHAWAY INC-CL B`.
`ticker` `STRING` Ticker of the US composite listing as OpenFIGI records it, such as `BRK/B`.
`security_type` `STRING` OpenFIGI security type, such as `Common Stock` or `ETP`.
`figi` `STRING` Share-class FIGI from OpenFIGI, the one FIGI that is the same in every country.
`cusip` `STRING` CUSIP embedded in a US or Canadian ISIN, kept when OpenFIGI maps it back to the same share class.
`issuer_name` `STRING` Legal name of the issuer on its GLEIF LEI record.
`issuer_lei` `STRING` LEI of the issuer from GLEIF. For a fund that is one series of a multi-fund trust, the trust's LEI.
`issuer_cik` `STRING` SEC Central Index Key of the issuer. SEC registrants only.
`issuer_jurisdiction` `STRING` Where the issuer is incorporated, as the ISO 3166 code on its GLEIF LEI record, such as `US-DE`.
`exchange` `STRING` Exchange the SEC lists for the issuer's ticker, such as `NYSE`. SEC registrants only.
`sic` `STRING` Standard Industrial Classification code the SEC assigns to the issuer. SEC registrants only.
`industry` `STRING` The SEC's description of the issuer's SIC code, such as `Fire, Marine & Casualty Insurance`.
`sector` `STRING` Sector mapped from the SIC code for equities, such as `financials`. Null where the code names no single sector, and for funds.
`sec_filings` `STRING` EDGAR page listing the issuer's SEC filings. SEC registrants only.
**Underlying security fields** One row per column of `dimensions.underlying_securities`, in `dimensions.underlying_security_fields`: the section heading, label and definition shown next to each value, in display order.
Column Type Description
`field_id` `STRING` The column of `dimensions.underlying_securities` this row describes, such as `issuer_lei`.
`section_id` `STRING` Key of the section the field sits in: `security`, `issuer` or `classification`.
`section_title` `STRING` Heading shown above the section, such as `Classification`.
`section_order` `INT64` Position of the section, from 1.
`field_order` `INT64` Position of the field within its section, from 1.
`title` `STRING` Label of the field, such as `Issuer LEI`.
`definition` `STRING` One-sentence definition shown with the label.
`values` `ARRAY` One element per value a closed-set field can hold: `value` as stored in the column, `title`, its short display name, and `definition`, the sentence that explains it. Empty for a free-text field.
`inserted_at` `TIMESTAMP` When the registry snapshot behind the row was published.
**Asset token fields** One row per column of `dimensions.asset_tokens`: the section heading, label and definition shown next to each deployment field, and the title and definition of each closed-set value: every token standard, extension and issuer permission, and the issuance and detection statuses, in display order.
Column Type Description
`field_id` `STRING` The column of `dimensions.asset_tokens` this row describes, such as `token_standard`.
`section_id` `STRING` Key of the section the field sits in: `identity`, `standard`, `permissions` or `facts`.
`section_title` `STRING` Heading shown above the section, such as `Issuer permissions`.
`section_order` `INT64` Position of the section, from 1.
`field_order` `INT64` Position of the field within its section, from 1.
`title` `STRING` Label of the field, such as `Standard`.
`definition` `STRING` One-sentence definition shown with the label.
`values` `ARRAY` One element per value a closed-set field can hold: `value` as stored in the column, `title`, its short display name, and `definition`, the sentence that explains it. For `token_standard`, `token_extensions` and `token_permissions` this is the full vocabulary. Empty for a free-text field.
`inserted_at` `TIMESTAMP` When the registry snapshot behind the row was published.
## Sample queries **Assets by type** `asset_type` separates tokenized stocks, funds and commodities from other instruments. `reference_assets.type` classifies the reference: a lending receipt keeps `asset_type = 'lending-token'` even when it references a stock. ```sql theme={null} select asset_type, count(*) as assets from `dimensions.assets` where asset_type in ( 'tokenized-stocks', 'tokenized-funds', 'tokenized-commodities' ) group by asset_type order by assets desc ``` **One reference asset's tokens** `reference_asset_id` is the join between a wrapper and the thing it tracks, and several issuers can point at the same one. Each token's name says who issued it. ```sql theme={null} select assets.asset_id, assets.name, assets.symbol from `dimensions.assets` as assets join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where reference_assets.reference_asset_id = 'nvda' and assets.asset_type = 'tokenized-stocks' order by assets.asset_id ``` **Most-tokenized reference assets** A `having` clause on the token count keeps the result to references more than one issuer has wrapped. `type` says what kind of thing the reference is, from an equity to a fund strategy. ```sql theme={null} select reference_assets.reference_asset_id, reference_assets.name, reference_assets.type, count(*) as instruments from `dimensions.assets` as assets join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where assets.asset_type in ( 'tokenized-stocks', 'tokenized-funds', 'tokenized-commodities' ) group by 1, 2, 3 having count(*) > 1 order by instruments desc ``` **Reference assets by issuer** `issuer_project_id` is the project holding the `issuer` relation, so `count(distinct ...)` on it counts issuers where `count(*)` counts tokens. Where a reference asset has more tokens than issuers, one issuer runs two wrappers on the same share. ```sql theme={null} select reference_assets.symbol as reference_asset, reference_assets.type, count(distinct assets.issuer_project_id) as issuers, count(*) as tokens, string_agg(distinct assets.issuer_project_id order by assets.issuer_project_id) as issuer_list from `dimensions.assets` as assets join `dimensions.reference_assets` as reference_assets using (reference_asset_id) where assets.asset_type = 'tokenized-stocks' group by reference_asset, reference_assets.type order by issuers desc limit 20 ``` **Return treatment of one share** `return_treatment` says what the token does with the income the underlying pays. It is keyed on the token, so the same share tokenized by two issuers reads `total_return` on one row and `price_return_with_distribution` on the next. ```sql theme={null} select assets.symbol as wrapper, projects.name as issuer, assets.return_treatment, assets.issuer_domicile from `dimensions.assets` as assets join `dimensions.reference_assets` as reference_assets using (reference_asset_id) left join `dimensions.projects` as projects on projects.project_id = assets.issuer_project_id where reference_assets.symbol = 'NVDA' and assets.asset_type = 'tokenized-stocks' order by assets.return_treatment, issuer ``` **Return treatment across an issuer** Reading `treatments` as one on every row makes the treatment a property of the issuer, held constant across every share it wraps. `string_agg` names which one the issuer settled on. ```sql theme={null} select projects.name as issuer, count(*) as tokens, count(distinct assets.return_treatment) as treatments, string_agg(distinct assets.return_treatment order by assets.return_treatment) as treatment from `dimensions.assets` as assets join `dimensions.projects` as projects on projects.project_id = assets.issuer_project_id where assets.asset_type = 'tokenized-stocks' and assets.return_treatment is not null group by issuer order by tokens desc ``` # Balances Source: https://tokenterminal.com/docs/catalog/stablecoins/balances Stablecoin holder balances at any past date, computed at query time. One row per holder of one stablecoin deployment, computed at query time from the transfer history by `functions.calculate_latest_token_balances` and `functions.calculate_historical_eod_token_balances`. `balance` is the holder's amount in whole token units, and each call takes a chain, a token address and a token standard from [Registry](/docs/catalog/stablecoins/registry). **Coming: a curated pair for stablecoins.** `functions.calculate_latest_asset_token_balances` and `functions.calculate_historical_eod_asset_token_balances` cover the tokenized asset registry, which every stablecoin here belongs to. They refuse rather than returning a number where a deployment cannot be modelled, so a figure they give back is one that has been checked. **In progress**: under test, not yet served. The generic pair above also accepts these tokens, and will answer for a rebasing stablecoin with a number that drifts below the chain. Both signatures are identical and documented at [Tokens ▸ Balances](/docs/catalog/tokens/balances). What the curated pair covers, and which stablecoins it declines, is at [Assets ▸ Balance changes](/docs/catalog/assets/balance-changes). ## Columns
Column Type Description
`balance_date` `DATE` Day the balance moved. Returned by `calculate_historical_eod_token_balances`, which writes a row per day an account's balance changed.
`account_address` `STRING` Account holding the balance. On Solana this is the token account; [`dimensions.accounts`](/docs/catalog/accounts/registry) resolves the wallet behind it.
`balance` `BIGNUMERIC` End-of-day balance in whole token units, already scaled down by `decimals`. `calculate_latest_token_balances` returns the last one per account, positive balances only.
## Sample queries **Current holders** Each call adds up the whole balance-change history of one deployment; a daily holder count is cheaper read from `metrics_assets.holders_native_daily` on [Metrics](/docs/catalog/stablecoins/metrics). Addresses are lowercased on input, so a checksummed address pasted from an explorer resolves. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'ethereum', '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48', 'erc20' ) order by balance desc limit 100 ``` **Concentration on a date** The historical function writes a row only on a day the balance moved. An account's balance on a given date is its most recent row at or before that date. ```sql theme={null} with balances_on_date as ( select account_address, balance, row_number() over (partition by account_address order by balance_date desc) as recency from `functions.calculate_historical_eod_token_balances`( 'ethereum', '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48', 'erc20' ) where balance_date <= date '2026-06-30' ), holders as ( select balance, rank() over (order by balance desc) as balance_rank from balances_on_date where recency = 1 and balance > 0 ) select count(*) as holders, sum(balance) as supply, sum(case when balance_rank <= 10 then balance end) / sum(balance) as top_10_share from holders ``` # Stablecoins Source: https://tokenterminal.com/docs/catalog/stablecoins/index Every stablecoin: supply, holders, transfers and off-peg, across every chain. Supply, holders, transfer activity, price and peg deviation for every stablecoin Token Terminal tracks, from the asset down to the token contract on each chain. ## Coverage A tab per grain, then the events and the chains. Each tab says what one row is, and a tick marks every issuer that reports it. **Stablecoin** A stablecoin is one asset pegged to a currency, such as `usdc`. One row per issuer, ticked for every measure its stablecoins report.
Issuer Daily users Holders Market cap Mints Monthly users Off peg Price Redemptions Transfer volume Transfers Weekly users
`3adao`✓✓✓✓✓✓✓✓✓✓✓
`a7a5`✓✗✗✗✓✗✗✗✗✗✓
`aave`✓✓✓✓✓✓✓✓✓✓✓
`aegis`✓✗✗✗✓✗✗✗✗✗✓
`agant`✓✓✓✓✓✓✓✓✓✓✓
`agora`✓✓✓✓✓✓✓✓✓✓✓
`alchemix`✓✓✓✓✓✓✓✓✓✓✓
`allunity`✓✓✓✓✓✓✓✓✓✓✓
`alphapartners`✓✓✓✓✓✓✓✓✓✓✓
`anchoragedigital`✓✓✓✓✓✓✓✓✓✓✓
`anchoredcoins`✓✓✓✓✓✓✓✓✓✓✓
`angle`✓✓✓✓✓✓✓✓✓✓✓
`anzen`✓✓✓✓✓✓✓✓✓✓✓
`anzens`✓✓✓✓✓✓✓✓✓✓✓
`apacx`✓✓✓✓✓✓✓✓✓✓✓
`apyx`✓✓✓✓✓✓✓✓✓✓✓
`archblock`✓✓✓✓✓✓✓✓✓✓✓
`arcus`✓✓✓✓✓✓✓✓✓✓✓
`aryze`✓✓✓✓✓✓✓✓✓✓✓
`aster`✓✓✓✓✓✓✓✓✓✓✓
`astera`✓✓✓✓✓✓✓✓✓✓✓
`audx`✓✓✓✓✓✓✓✓✓✓✓
`australiandigitaldollar`✓✓✓✓✓✓✓✓✓✓✓
`avalonfinance`✓✗✗✗✓✗✗✗✗✗✓
`avantprotocol`✓✓✓✓✓✓✓✓✓✓✓
`berachain`✓✓✓✓✓✓✓✓✓✓✓
`bilira`✓✓✓✓✓✓✓✓✓✓✓
`binance`✓✓✓✓✓✓✓✓✓✓✓
`bitso`✓✓✓✓✓✓✓✓✓✓✓
`blox`✓✓✓✓✓✗✓✓✓✓✓
`bralexyz`✓✗✗✗✓✗✗✗✗✗✓
`braza`✓✓✓✓✓✓✓✓✓✓✓
`bridge`✓✓✓✓✓✓✓✓✓✓✓
`bucket`✓✓✓✓✓✓✓✓✓✓✓
`capapp`✓✓✓✓✓✓✓✓✓✓✓
`cfxlabs`✓✓✓✓✓✓✓✓✓✓✓
`circle`✓✓✓✓✓✓✓✓✓✓✓
`cod3x`✓✓✓✓✓✓✓✓✓✓✓
`creditagricole`✓✓✓✓✓✓✓✓✓✓✓
`crown`✓✓✓✓✓✓✓✓✓✓✓
`curve`✓✓✓✓✓✓✓✓✓✓✓
`cygnusfinance`✓✓✓✓✓✓✓✓✓✓✓
`czodiac`✓✗✗✗✓✗✗✗✗✗✓
`defi`✓✗✗✗✓✗✗✗✗✗✓
`defifranc`✓✓✓✓✓✓✓✓✓✓✓
`deuro`✓✓✓✓✓✓✓✓✓✓✓
`djed`✓✗✗✗✓✗✗✗✗✗✓
`dtrinity`✓✓✓✓✓✓✓✓✓✓✓
`ebisu`✓✓✓✓✓✓✓✓✓✓✓
`elixir`✓✗✗✗✓✗✗✗✗✗✓
`ethena`✓✓✓✓✓✓✓✓✓✓✓
`falconfinance`✓✓✓✓✓✓✓✓✓✓✓
`fathom`✓✓✓✓✓✓✓✓✓✓✓
`fd121limited`✓✓✓✓✓✓✓✓✓✓✓
`felix`✓✓✓✓✓✓✓✓✓✓✓
`fidelity`✓✓✓✓✓✓✓✓✓✓✓
`fireblocks`✓✓✓✓✓✓✓✓✓✓✓
`floatprotocol`✓✓✓✓✓✗✓✓✓✓✓
`flow`✓✓✓✓✓✓✓✓✓✓✓
`flyingtulip`✓✓✓✓✓✓✓✓✓✓✓
`fortetechsolutions`✗✗✗✗✗✓✓✗✗✗✗
`frankencoin`✓✓✓✓✓✓✓✓✓✓✓
`fraxstablecoin`✓✓✓✓✓✓✓✓✓✓✓
`fxprotocol`✓✓✓✓✓✓✓✓✓✓✓
`gateio`✓✗✗✗✓✗✗✗✗✗✓
`gemini`✓✓✓✓✓✓✓✓✓✓✓
`glodollar`✓✓✓✓✓✓✓✓✓✓✓
`gmotrust`✓✓✓✓✓✓✓✓✓✓✓
`goal3`✓✓✓✓✓✓✓✓✓✓✓
`gravita`✓✓✓✓✓✓✓✓✓✓✓
`gyroscope`✓✗✗✗✓✗✗✗✗✗✓
`homecoin`✓✗✗✗✓✗✗✗✗✗✓
`hydradx`✗✗✓✗✗✓✓✗✗✗✗
`hylo`✓✓✓✓✓✓✓✓✓✓✓
`hyperstable`✓✓✓✓✓✓✓✓✓✓✓
`indigo`✓✓✓✓✓✓✓✓✓✓✓
`infinifi`✓✓✓✓✓✓✓✓✓✓✓
`interestprotocol`✓✗✗✗✓✗✗✗✗✗✓
`inversefinance`✓✓✓✓✓✓✓✓✓✓✓
`ironbank`✓✓✓✓✓✓✓✓✓✓✓
`jpycoin`✓✓✓✓✓✓✓✓✓✓✓
`jupiter`✓✓✓✓✓✓✓✓✓✓✓
`levelprotocol`✓✓✓✓✓✓✓✓✓✓✓
`liquity`✓✓✓✓✓✓✓✓✓✓✓
`listadao`✓✓✓✓✓✓✓✓✓✓✓
`mainstreet`✓✓✓✓✓✓✓✓✓✓✓
`makerdao`✓✓✓✓✓✓✓✓✓✓✓
`membranefinance`✓✓✓✓✓✓✓✓✓✓✓
`mento`✓✓✓✓✓✗✓✓✓✓✓
`mentolabs`✓✓✓✓✓✓✓✓✓✓✓
`mesh`✓✓✓✗✓✗✓✗✓✓✓
`metamask`✓✓✓✓✓✓✓✓✓✓✓
`metronome`✓✓✓✓✓✓✓✓✓✓✓
`mezo`✓✗✗✗✓✗✗✗✗✗✓
`mimocapital`✓✓✓✓✓✓✓✓✓✓✓
`mnee`✓✓✓✓✓✓✓✓✓✓✓
`moet`✓✓✓✓✓✓✓✓✓✓✓
`monerium`✓✓✓✓✓✓✓✓✓✓✓
`moneta`✓✓✓✓✓✓✓✓✓✓✓
`moneyonchain`✓✓✓✓✓✓✓✓✓✓✓
`monolithmarket`✓✗✗✗✓✗✗✗✗✗✓
`mudigital`✓✗✗✗✓✗✗✗✗✗✓
`multipli`✓✓✓✓✓✓✓✓✓✓✓
`mynth`✓✓✗✗✓✗✗✗✗✓✓
`mzero`✓✓✓✓✓✓✓✓✓✓✓
`nativemarkets`✓✓✓✓✓✓✓✓✓✓✓
`nereusfinance`✓✗✗✗✓✗✗✗✗✗✓
`neutrl`✓✓✓✓✓✓✓✓✓✓✓
`newrails`✓✓✓✓✓✓✓✓✓✓✓
`noon`✓✓✓✓✓✓✓✓✓✓✓
`ondo`✓✓✓✓✓✓✓✓✓✓✓
`palmusd`✓✓✓✓✓✓✓✓✓✓✓
`pareto`✓✓✓✓✓✓✓✓✓✓✓
`paxos`✓✓✓✓✓✓✓✓✓✓✓
`paytrie`✓✓✓✓✓✓✓✓✓✓✓
`perena`✓✓✓✓✓✓✓✓✓✓✓
`phantom`✓✓✓✓✓✓✓✓✓✓✓
`pleasinggold`✓✗✗✗✓✗✗✗✗✗✓
`plumenetwork`✓✗✗✗✓✗✗✗✗✗✓
`polymarket`✓✓✓✓✓✓✓✓✓✓✓
`prismafinance`✓✓✓✓✓✓✓✓✓✓✓
`quantoz`✓✓✓✓✓✓✓✓✓✓✓
`raac`✓✓✓✓✓✓✓✓✓✓✓
`raft`✓✗✗✗✓✗✗✗✗✗✓
`reflexer`✓✓✓✓✓✗✓✓✓✓✓
`reserve`✓✓✓✓✓✓✓✓✓✓✓
`reservoirxyz`✓✓✓✓✓✓✓✓✓✓✓
`resolv`✓✗✗✗✓✗✗✗✗✗✓
`resupply`✓✓✓✓✓✓✓✓✓✓✓
`ribdigital`✓✓✓✓✓✓✓✓✓✓✓
`rif`✓✓✓✓✓✓✓✓✓✓✓
`ripio`✓✓✓✓✓✓✓✓✓✓✓
`ripplelabs`✓✓✓✓✓✓✓✓✓✓✓
`river`✓✓✓✓✓✓✓✓✓✓✓
`saturn`✓✓✓✓✓✓✓✓✓✓✓
`sbishinseitrust`✓✓✓✓✓✓✓✓✓✓✓
`schumanfinancial`✓✓✓✓✓✓✓✓✓✓✓
`scroll`✓✓✓✓✓✓✓✓✓✓✓
`societegenerale`✓✓✓✓✓✓✓✓✓✓✓
`sofi`✓✓✓✓✓✓✓✓✓✓✓
`solomonlabs`✓✓✓✓✓✓✓✓✓✓✓
`solstice`✓✓✓✓✓✓✓✓✓✓✓
`soulpeg`✓✓✓✓✓✓✓✓✓✓✓
`sovryn`✓✓✓✓✓✓✓✓✓✓✓
`sperax`✓✓✓✓✓✓✓✓✓✓✓
`stablecoin`✓✓✓✓✓✓✓✓✓✓✓
`stablecorp`✓✗✗✗✓✗✗✗✗✗✓
`stablemint`✓✗✗✗✓✗✗✗✗✗✓
`stableslabs`✓✗✗✗✓✗✗✗✗✗✓
`stablr`✓✓✓✓✓✓✓✓✓✓✓
`standx`✓✓✓✓✓✓✓✓✓✓✓
`stasis`✓✓✓✓✓✓✓✓✓✓✓
`straitsx`✓✓✓✓✓✓✓✓✓✓✓
`synthetix`✓✓✓✓✓✓✓✓✓✓✓
`tempo`✓✓✓✓✓✓✓✓✓✓✓
`tenbinlabs`✓✓✓✓✓✓✓✓✓✓✓
`tether`✓✓✓✓✓✓✓✓✓✓✓
`threshold`✓✗✗✗✓✗✗✗✗✗✓
`token`✓✓✓✓✓✓✓✓✓✓✓
`tokenisedgbp`✓✓✓✓✓✓✓✓✓✓✓
`torifinance`✓✓✓✓✓✓✓✓✓✓✓
`transfero`✓✓✓✓✓✓✓✓✓✓✓
`tronusdd`✓✓✓✓✓✓✓✓✓✓✓
`trystable`✓✗✗✗✓✗✗✗✗✗✓
`unitas`✓✓✓✓✓✓✓✓✓✓✓
`unitedstables`✓✓✓✓✓✓✓✓✓✓✓
`unityusd`✓✓✓✓✓✓✓✓✓✓✓
`usdai`✓✓✓✓✓✓✓✓✓✓✓
`usdkg`✓✓✗✗✓✓✓✗✓✓✓
`usdm1`✓✓✓✓✓✓✓✓✓✓✓
`usdufinance`✓✓✓✓✓✓✓✓✓✓✓
`usual`✓✓✓✓✓✓✓✓✓✓✓
`venus`✓✓✓✓✓✓✓✓✓✓✓
`vnx`✓✓✓✓✓✓✓✓✓✓✓
`voltprotocol`✓✗✗✗✓✗✗✗✗✗✓
`wisdomtree`✓✓✗✗✓✗✗✗✗✓✓
`worldlibertyfinancial`✓✓✓✓✓✓✓✓✓✓✓
`wspn`✓✗✗✗✓✗✗✗✗✗✓
`wyoming`✓✓✓✓✓✓✓✓✓✓✓
`xsy`✓✗✗✗✓✗✗✗✗✗✓
`yala`✓✗✗✗✓✗✗✗✗✗✓
`yamatoprotocol`✓✓✓✓✓✓✓✓✓✓✓
`yeti`✓✓✓✓✓✓✓✓✓✓✓
`yuzumoney`✓✓✓✓✓✓✓✓✓✓✓
`zunami`✓✗✗✗✓✗✗✗✗✗✓
**Deployment** A deployment is one stablecoin's token contract on one chain, such as `usdc` on `base`. One row per issuer, ticked for every measure its deployments report.
Issuer Daily users Holders Market cap Mints Monthly users Redemptions Transfer volume Transfers Weekly users
`3adao`✓✓✓✓✓✓✓✓✓
`a7a5`✓✗✗✗✓✗✗✗✓
`aave`✓✓✓✓✓✓✓✓✓
`aegis`✓✗✗✗✓✗✗✗✓
`agant`✓✓✓✓✓✓✓✓✓
`agora`✓✓✓✓✓✓✓✓✓
`alchemix`✓✓✓✓✓✓✓✓✓
`allunity`✓✓✓✓✓✓✓✓✓
`alphapartners`✓✓✓✓✓✓✓✓✓
`anchoragedigital`✓✓✓✓✓✓✓✓✓
`anchoredcoins`✓✓✓✓✓✓✓✓✓
`angle`✓✓✓✓✓✓✓✓✓
`anzen`✓✓✓✓✓✓✓✓✓
`anzens`✓✓✓✓✓✓✓✓✓
`apacx`✓✓✓✓✓✓✓✓✓
`apyx`✓✓✓✓✓✓✓✓✓
`archblock`✓✓✓✓✓✓✓✓✓
`arcus`✓✓✓✓✓✓✓✓✓
`aryze`✓✓✓✓✓✓✓✓✓
`aster`✓✓✓✓✓✓✓✓✓
`astera`✓✓✓✓✓✓✓✓✓
`audx`✓✓✓✓✓✓✓✓✓
`australiandigitaldollar`✓✓✓✓✓✓✓✓✓
`avalonfinance`✓✗✗✗✓✗✗✗✓
`avantprotocol`✓✓✓✓✓✓✓✓✓
`berachain`✓✓✓✓✓✓✓✓✓
`bilira`✓✓✓✓✓✓✓✓✓
`binance`✓✓✓✓✓✓✓✓✓
`bitso`✓✓✓✓✓✓✓✓✓
`blox`✓✓✓✓✓✓✓✓✓
`bralexyz`✓✗✗✗✓✗✗✗✓
`braza`✓✓✓✓✓✓✓✓✓
`bridge`✓✓✓✓✓✓✓✓✓
`bucket`✓✓✓✓✓✓✓✓✓
`capapp`✓✓✓✓✓✓✓✓✓
`cfxlabs`✓✓✓✓✓✓✓✓✓
`circle`✓✓✓✓✓✓✓✓✓
`cod3x`✓✓✓✓✓✓✓✓✓
`creditagricole`✓✓✓✓✓✓✓✓✓
`crown`✓✓✓✓✓✓✓✓✓
`curve`✓✓✓✓✓✓✓✓✓
`cygnusfinance`✓✓✓✓✓✓✓✓✓
`czodiac`✓✗✗✗✓✗✗✗✓
`defi`✓✗✗✗✓✗✗✗✓
`defifranc`✓✓✓✓✓✓✓✓✓
`deuro`✓✓✓✓✓✓✓✓✓
`djed`✓✗✗✗✓✗✗✗✓
`dtrinity`✓✓✓✓✓✓✓✓✓
`ebisu`✓✓✓✓✓✓✓✓✓
`elixir`✓✗✗✗✓✗✗✗✓
`ethena`✓✓✓✓✓✓✓✓✓
`falconfinance`✓✓✓✓✓✓✓✓✓
`fathom`✓✓✓✓✓✓✓✓✓
`fd121limited`✓✓✓✓✓✓✓✓✓
`felix`✓✓✓✓✓✓✓✓✓
`fidelity`✓✓✓✓✓✓✓✓✓
`fireblocks`✓✓✓✓✓✓✓✓✓
`floatprotocol`✓✓✓✓✓✓✓✓✓
`flow`✓✓✓✓✓✓✓✓✓
`flyingtulip`✓✓✓✓✓✓✓✓✓
`frankencoin`✓✓✓✓✓✓✓✓✓
`fraxstablecoin`✓✓✓✓✓✓✓✓✓
`fxprotocol`✓✓✓✓✓✓✓✓✓
`gateio`✓✗✗✗✓✗✗✗✓
`gemini`✓✓✓✓✓✓✓✓✓
`glodollar`✓✓✓✓✓✓✓✓✓
`gmotrust`✓✓✓✓✓✓✓✓✓
`goal3`✓✓✓✓✓✓✓✓✓
`gravita`✓✓✓✓✓✓✓✓✓
`gyroscope`✓✗✗✗✓✗✗✗✓
`homecoin`✓✗✗✗✓✗✗✗✓
`hydradx`✗✗✓✗✗✗✗✗✗
`hylo`✓✓✓✓✓✓✓✓✓
`hyperstable`✓✓✓✓✓✓✓✓✓
`indigo`✓✓✓✓✓✓✓✓✓
`infinifi`✓✓✓✓✓✓✓✓✓
`interestprotocol`✓✗✗✗✓✗✗✗✓
`inversefinance`✓✓✓✓✓✓✓✓✓
`ironbank`✓✓✓✓✓✓✓✓✓
`jpycoin`✓✓✓✓✓✓✓✓✓
`jupiter`✓✓✓✓✓✓✓✓✓
`levelprotocol`✓✓✓✓✓✓✓✓✓
`liquity`✓✓✓✓✓✓✓✓✓
`listadao`✓✓✓✓✓✓✓✓✓
`mainstreet`✓✓✓✓✓✓✓✓✓
`makerdao`✓✓✓✓✓✓✓✓✓
`membranefinance`✓✓✓✓✓✓✓✓✓
`mento`✓✓✓✓✓✓✓✓✓
`mentolabs`✓✓✓✓✓✓✓✓✓
`mesh`✓✓✓✗✓✗✓✓✓
`metamask`✓✓✓✓✓✓✓✓✓
`metronome`✓✓✓✓✓✓✓✓✓
`mezo`✓✗✗✗✓✗✗✗✓
`mimocapital`✓✓✓✓✓✓✓✓✓
`mnee`✓✓✓✓✓✓✓✓✓
`moet`✓✓✓✓✓✓✓✓✓
`monerium`✓✓✓✓✓✓✓✓✓
`moneta`✓✓✓✓✓✓✓✓✓
`moneyonchain`✓✓✓✓✓✓✓✓✓
`monolithmarket`✓✗✗✗✓✗✗✗✓
`mudigital`✓✗✗✗✓✗✗✗✓
`multipli`✓✓✓✓✓✓✓✓✓
`mynth`✓✓✗✗✓✗✗✓✓
`mzero`✓✓✓✓✓✓✓✓✓
`nativemarkets`✓✓✓✓✓✓✓✓✓
`nereusfinance`✓✗✗✗✓✗✗✗✓
`neutrl`✓✓✓✓✓✓✓✓✓
`newrails`✓✓✓✓✓✓✓✓✓
`noon`✓✓✓✓✓✓✓✓✓
`ondo`✓✓✓✓✓✓✓✓✓
`palmusd`✓✓✓✓✓✓✓✓✓
`pareto`✓✓✓✓✓✓✓✓✓
`paxos`✓✓✓✓✓✓✓✓✓
`paytrie`✓✓✓✓✓✓✓✓✓
`perena`✓✓✓✓✓✓✓✓✓
`phantom`✓✓✓✓✓✓✓✓✓
`pleasinggold`✓✗✗✗✓✗✗✗✓
`plumenetwork`✓✗✗✗✓✗✗✗✓
`polymarket`✓✓✓✓✓✓✓✓✓
`prismafinance`✓✓✓✓✓✓✓✓✓
`quantoz`✓✓✓✓✓✓✓✓✓
`raac`✓✓✓✓✓✓✓✓✓
`raft`✓✗✗✗✓✗✗✗✓
`reflexer`✓✓✓✓✓✓✓✓✓
`reserve`✓✓✓✓✓✓✓✓✓
`reservoirxyz`✓✓✓✓✓✓✓✓✓
`resolv`✓✗✗✗✓✗✗✗✓
`resupply`✓✓✓✓✓✓✓✓✓
`ribdigital`✓✓✓✓✓✓✓✓✓
`rif`✓✓✓✓✓✓✓✓✓
`ripio`✓✓✓✓✓✓✓✓✓
`ripplelabs`✓✓✓✓✓✓✓✓✓
`river`✓✓✓✓✓✓✓✓✓
`saturn`✓✓✓✓✓✓✓✓✓
`sbishinseitrust`✓✓✓✓✓✓✓✓✓
`schumanfinancial`✓✓✓✓✓✓✓✓✓
`scroll`✓✓✓✓✓✓✓✓✓
`societegenerale`✓✓✓✓✓✓✓✓✓
`sofi`✓✓✓✓✓✓✓✓✓
`solomonlabs`✓✓✓✓✓✓✓✓✓
`solstice`✓✓✓✓✓✓✓✓✓
`soulpeg`✓✓✓✓✓✓✓✓✓
`sovryn`✓✓✓✓✓✓✓✓✓
`sperax`✓✓✓✓✓✓✓✓✓
`stablecoin`✓✓✓✓✓✓✓✓✓
`stablecorp`✓✗✗✗✓✗✗✗✓
`stablemint`✓✗✗✗✓✗✗✗✓
`stableslabs`✓✗✗✗✓✗✗✗✓
`stablr`✓✓✓✓✓✓✓✓✓
`standx`✓✓✓✓✓✓✓✓✓
`stasis`✓✓✓✓✓✓✓✓✓
`straitsx`✓✓✓✓✓✓✓✓✓
`synthetix`✓✓✓✓✓✓✓✓✓
`tempo`✓✓✓✓✓✓✓✓✓
`tenbinlabs`✓✓✓✓✓✓✓✓✓
`tether`✓✓✓✓✓✓✓✓✓
`threshold`✓✗✗✗✓✗✗✗✓
`token`✓✓✓✓✓✓✓✓✓
`tokenisedgbp`✓✓✓✓✓✓✓✓✓
`torifinance`✓✓✓✓✓✓✓✓✓
`transfero`✓✓✓✓✓✓✓✓✓
`tronusdd`✓✓✓✓✓✓✓✓✓
`trystable`✓✗✗✗✓✗✗✗✓
`unitas`✓✓✓✓✓✓✓✓✓
`unitedstables`✓✓✓✓✓✓✓✓✓
`unityusd`✓✓✓✓✓✓✓✓✓
`usdai`✓✓✓✓✓✓✓✓✓
`usdkg`✓✓✗✗✓✗✓✓✓
`usdm1`✓✓✓✓✓✓✓✓✓
`usdufinance`✓✓✓✓✓✓✓✓✓
`usual`✓✓✓✓✓✓✓✓✓
`venus`✓✓✓✓✓✓✓✓✓
`vnx`✓✓✓✓✓✓✓✓✓
`voltprotocol`✓✗✗✗✓✗✗✗✓
`wisdomtree`✓✓✗✗✓✗✗✓✓
`worldlibertyfinancial`✓✓✓✓✓✓✓✓✓
`wspn`✓✗✗✗✓✗✗✗✓
`wyoming`✓✓✓✓✓✓✓✓✓
`xsy`✓✗✗✗✓✗✗✗✓
`yala`✓✗✗✗✓✗✗✗✓
`yamatoprotocol`✓✓✓✓✓✓✓✓✓
`yeti`✓✓✓✓✓✓✓✓✓
`yuzumoney`✓✓✓✓✓✓✓✓✓
`zunami`✓✗✗✗✓✗✗✗✓
**Events** One row per stablecoin movement, at the moment it happened onchain. Amounts are in the token's own units; join [Prices](/docs/catalog/tokens/metrics) for a USD figure.
Issuer Transfers
`3adao`✓
`aryze`✓
`audx`✓
`aave`✓
`agant`✓
`agora`✓
`alchemix`✓
`allunity`✓
`alphapartners`✓
`anchoragedigital`✓
`anchoredcoins`✓
`angle`✓
`anzen`✓
`anzens`✓
`apacx`✓
`apyx`✓
`arcus`✓
`aster`✓
`astera`✓
`australiandigitaldollar`✓
`avantprotocol`✓
`berachain`✓
`bilira`✓
`binance`✓
`bitso`✓
`blox`✓
`braza`✓
`bridge`✓
`bucket`✓
`cfxlabs`✓
`capapp`✓
`circle`✓
`cod3x`✓
`creditagricole`✓
`crown`✓
`curve`✓
`cygnusfinance`✓
`defifranc`✓
`ebisu`✓
`ethena`✓
`falconfinance`✓
`fathom`✓
`felix`✓
`fidelity`✓
`fireblocks`✓
`fd121limited`✓
`floatprotocol`✓
`flow`✓
`flyingtulip`✓
`frankencoin`✓
`fraxstablecoin`✓
`gmotrust`✓
`gemini`✓
`glodollar`✓
`goal3`✓
`gravita`✓
`hylo`✓
`hyperstable`✓
`indigo`✓
`infinifi`✓
`inversefinance`✓
`ironbank`✓
`jpycoin`✓
`jupiter`✓
`levelprotocol`✓
`liquity`✓
`listadao`✓
`usdm1`✓
`mnee`✓
`mzero`✓
`mainstreet`✓
`membranefinance`✓
`mento`✓
`mentolabs`✓
`mesh`✓
`metamask`✓
`metronome`✓
`mimocapital`✓
`moet`✓
`monerium`✓
`moneta`✓
`moneyonchain`✓
`multipli`✓
`mynth`✓
`nativemarkets`✓
`neutrl`✓
`newrails`✓
`noon`✓
`ondo`✓
`palmusd`✓
`pareto`✓
`paxos`✓
`paytrie`✓
`perena`✓
`phantom`✓
`polymarket`✓
`prismafinance`✓
`quantoz`✓
`ribdigital`✓
`rif`✓
`raac`✓
`reflexer`✓
`reserve`✓
`reservoirxyz`✓
`resupply`✓
`ripio`✓
`ripplelabs`✓
`river`✓
`sbishinseitrust`✓
`saturn`✓
`schumanfinancial`✓
`scroll`✓
`makerdao`✓
`sofi`✓
`societegenerale`✓
`solomonlabs`✓
`solstice`✓
`soulpeg`✓
`sovryn`✓
`sperax`✓
`stablr`✓
`stablecoin`✓
`standx`✓
`stasis`✓
`straitsx`✓
`synthetix`✓
`tempo`✓
`tenbinlabs`✓
`tether`✓
`token`✓
`tokenisedgbp`✓
`torifinance`✓
`transfero`✓
`tronusdd`✓
`archblock`✓
`usdkg`✓
`usdufinance`✓
`usdai`✓
`unitas`✓
`unitedstables`✓
`unityusd`✓
`usual`✓
`vnx`✓
`venus`✓
`wisdomtree`✓
`worldlibertyfinancial`✓
`wyoming`✓
`yamatoprotocol`✓
`yeti`✓
`yuzumoney`✓
`deuro`✓
`dtrinity`✓
`fxprotocol`✓
**Chains** Every chain the section covers.
Chain Issuers
`algorand``circle`, `quantoz`, `stasis`, `transfero`
`aptos``circle`, `fraxstablecoin`, `tether`, `worldlibertyfinancial`
`arbitrum``aave`, `agora`, `allunity`, `angle`, `archblock`, `bitso`, `blox`, `circle`, `curve`, `defi`, `deuro`, `ethena`, `fd121limited`, `frankencoin`, `fraxstablecoin`, `glodollar`, `gmotrust`, `gravita`, `gyroscope`, `inversefinance`, `liquity`, `makerdao`, `membranefinance`, `monerium`, `moneyonchain`, `multipli`, `paxos`, `paytrie`, `pleasinggold`, `reserve`, `resolv`, `rif`, `river`, `sperax`, `stablecoin`, `stablemint`, `stableslabs`, `stasis`, `straitsx`, `tether`, `transfero`, `tronusdd`, `usdai`, `usual`, `vnx`, `voltprotocol`, `wyoming`
`avalanche``aave`, `aegis`, `agora`, `archblock`, `avantprotocol`, `bilira`, `binance`, `bitso`, `circle`, `elixir`, `ethena`, `fortetechsolutions`, `frankencoin`, `fraxstablecoin`, `gyroscope`, `jpycoin`, `liquity`, `nereusfinance`, `reflexer`, `schumanfinancial`, `stablecoin`, `straitsx`, `tether`, `token`, `tokenisedgbp`, `transfero`, `tronusdd`, `vnx`, `wyoming`, `yeti`
`base``aave`, `agant`, `allunity`, `angle`, `anzen`, `apyx`, `australiandigitaldollar`, `bilira`, `blox`, `bralexyz`, `circle`, `cod3x`, `crown`, `curve`, `cygnusfinance`, `deuro`, `ethena`, `frankencoin`, `fraxstablecoin`, `glodollar`, `gyroscope`, `inversefinance`, `liquity`, `makerdao`, `metronome`, `mezo`, `monerium`, `multipli`, `paytrie`, `reserve`, `resolv`, `ripio`, `river`, `stablecoin`, `stablemint`, `stableslabs`, `straitsx`, `tokenisedgbp`, `transfero`, `vnx`, `wyoming`, `xsy`, `yala`
`berachain``berachain`, `ethena`, `fraxstablecoin`, `liquity`, `resolv`, `tether`
`blast``anzen`, `ethena`, `fraxstablecoin`
`bob``river`
`bsc``aegis`, `agora`, `alphapartners`, `anchoredcoins`, `angle`, `archblock`, `aryze`, `aster`, `avalonfinance`, `bilira`, `binance`, `circle`, `curve`, `czodiac`, `ethena`, `falconfinance`, `fd121limited`, `fireblocks`, `fraxstablecoin`, `inversefinance`, `listadao`, `ondo`, `resolv`, `ribdigital`, `ripio`, `river`, `soulpeg`, `stableslabs`, `standx`, `tether`, `tokenisedgbp`, `transfero`, `tronusdd`, `unitas`, `unitedstables`, `unityusd`, `venus`, `worldlibertyfinancial`, `yala`
`cardano``anzens`, `circle`, `djed`, `indigo`, `makerdao`, `moneta`, `mynth`, `paxos`, `tether`
`celo``angle`, `circle`, `glodollar`, `mento`, `mentolabs`, `tether`, `transfero`, `vnx`
`coredao``agora`
`ethereum``a7a5`, `aave`, `aegis`, `agant`, `agora`, `alchemix`, `allunity`, `anchoredcoins`, `angle`, `anzen`, `apacx`, `apyx`, `archblock`, `aryze`, `audx`, `australiandigitaldollar`, `avalonfinance`, `bilira`, `bitso`, `bridge`, `capapp`, `circle`, `creditagricole`, `crown`, `curve`, `defifranc`, `deuro`, `dtrinity`, `ebisu`, `elixir`, `ethena`, `falconfinance`, `fd121limited`, `fidelity`, `fireblocks`, `floatprotocol`, `flyingtulip`, `frankencoin`, `fraxstablecoin`, `fxprotocol`, `gateio`, `gemini`, `glodollar`, `gmotrust`, `gravita`, `gyroscope`, `homecoin`, `infinifi`, `interestprotocol`, `inversefinance`, `ironbank`, `jpycoin`, `levelprotocol`, `liquity`, `mainstreet`, `makerdao`, `membranefinance`, `metamask`, `metronome`, `mezo`, `mimocapital`, `mnee`, `monerium`, `monolithmarket`, `multipli`, `mzero`, `neutrl`, `noon`, `ondo`, `palmusd`, `pareto`, `paxos`, `paytrie`, `plumenetwork`, `prismafinance`, `quantoz`, `raac`, `raft`, `reflexer`, `reserve`, `reservoirxyz`, `resolv`, `resupply`, `ribdigital`, `ripio`, `ripplelabs`, `river`, `saturn`, `sbishinseitrust`, `schumanfinancial`, `societegenerale`, `sofi`, `stablecoin`, `stablecorp`, `stablemint`, `stableslabs`, `stablr`, `stasis`, `straitsx`, `synthetix`, `tenbinlabs`, `tether`, `threshold`, `tokenisedgbp`, `torifinance`, `transfero`, `tronusdd`, `unitedstables`, `usdai`, `usdkg`, `usdm1`, `usdufinance`, `usual`, `vnx`, `voltprotocol`, `wisdomtree`, `worldlibertyfinancial`, `wspn`, `wyoming`, `yala`, `yamatoprotocol`, `zunami`
`fantom``angle`, `archblock`, `fraxstablecoin`, `inversefinance`, `mimocapital`
`flowevm``circle`, `flow`, `moet`, `paxos`, `tether`
`fraxtal``dtrinity`, `ethena`, `fraxstablecoin`, `vnx`
`gnosis``aave`, `angle`, `circle`, `curve`, `frankencoin`, `gyroscope`, `monerium`, `ripio`, `stasis`, `transfero`
`hedera``australiandigitaldollar`, `circle`, `straitsx`, `wyoming`
`hydradxevm``hydradx`
`hyperevm``circle`, `ethena`, `felix`, `hyperstable`, `liquity`, `nativemarkets`, `resolv`, `tether`
`immutablezkevm``agora`
`injective``circle`
`injectiveevm``circle`
`ink``aave`, `circle`, `ethena`, `fraxstablecoin`, `paxos`, `tether`
`iota``virtue`
`katananetwork``agora`, `capapp`, `dtrinity`, `fraxstablecoin`
`linea``3adao`, `aryze`, `astera`, `circle`, `ethena`, `fraxstablecoin`, `metamask`, `monerium`, `paytrie`, `transfero`
`manta``ethena`
`mantle``agora`
`megaeth``capapp`, `ethena`, `tether`
`monad``agora`, `circle`, `ethena`, `metamask`, `mudigital`, `multipli`, `newrails`, `worldlibertyfinancial`, `yuzumoney`
`near``archblock`, `circle`, `makerdao`, `tether`
`optimism``allunity`, `angle`, `archblock`, `binance`, `circle`, `curve`, `defi`, `deuro`, `ethena`, `frankencoin`, `fraxstablecoin`, `glodollar`, `gyroscope`, `inversefinance`, `liquity`, `makerdao`, `metronome`, `reflexer`, `stablecoin`, `synthetix`, `tether`, `transfero`, `wyoming`
`osmosis``monerium`
`plasma``bilira`, `ethena`, `metronome`, `schumanfinancial`, `tether`, `usdai`, `yuzumoney`
`plumenetwork``fraxstablecoin`
`polkadotassethub``circle`, `tether`
`polygon``3adao`, `agora`, `allunity`, `angle`, `apacx`, `archblock`, `aryze`, `audx`, `bilira`, `binance`, `bitso`, `bridge`, `circle`, `curve`, `deuro`, `frankencoin`, `fraxstablecoin`, `glodollar`, `gyroscope`, `jpycoin`, `makerdao`, `membranefinance`, `mimocapital`, `monerium`, `paxos`, `paytrie`, `polymarket`, `quantoz`, `reflexer`, `ripio`, `schumanfinancial`, `stablecoin`, `stasis`, `straitsx`, `tether`, `token`, `tokenisedgbp`, `transfero`, `vnx`, `wspn`, `wyoming`
`ripple``australiandigitaldollar`, `braza`, `circle`, `quantoz`, `ripplelabs`, `schumanfinancial`, `societegenerale`, `straitsx`, `vnx`
`robinhoodchain``arcus`, `ethena`, `paxos`
`ronin``dtrinity`
`rootstock``moneyonchain`, `rif`, `sovryn`, `transfero`
`scroll``ethena`, `fraxstablecoin`, `liquity`, `monerium`, `scroll`
`seievm``circle`, `fraxstablecoin`, `tether`
`solana``agant`, `agora`, `allunity`, `anchoragedigital`, `angle`, `australiandigitaldollar`, `bilira`, `blox`, `bralexyz`, `cfxlabs`, `circle`, `deficarrot`, `ethena`, `fd121limited`, `fraxstablecoin`, `gmotrust`, `hylo`, `jupiter`, `makerdao`, `membranefinance`, `ondo`, `paxos`, `perena`, `phantom`, `societegenerale`, `sofi`, `solomonlabs`, `solstice`, `stablecoin`, `standx`, `tether`, `tokenisedgbp`, `transfero`, `trystable`, `unitas`, `usdm1`, `vnx`, `worldlibertyfinancial`, `wyoming`, `yala`
`sonic``circle`, `flyingtulip`, `frankencoin`, `fraxstablecoin`, `liquity`, `mainstreet`, `river`, `tether`
`starknet``circle`, `makerdao`, `noon`
`stellar``allunity`, `australiandigitaldollar`, `circle`, `glodollar`, `gmotrust`, `mesh`, `paxos`, `societegenerale`, `stablecoin`, `stablecorp`, `stasis`, `tether`, `usdm1`, `vnx`
`sui``agora`, `bucket`, `circle`, `fd121limited`, `tether`
`tempo``agant`, `allunity`, `capapp`, `circle`, `ethena`, `fraxstablecoin`, `infinifi`, `reservoirxyz`, `stablecoin`, `tempo`, `tether`
`ton``tether`
`tron``a7a5`, `apacx`, `archblock`, `circle`, `ribdigital`, `tether`, `transfero`, `tronusdd`, `unitedstables`, `usdkg`, `worldlibertyfinancial`
`unichain``circle`, `fraxstablecoin`, `makerdao`, `tether`
`viction``wspn`
`worldchain``bilira`, `circle`, `fraxstablecoin`, `ripio`
`xdc``australiandigitaldollar`, `circle`, `falconfinance`, `fathom`, `stasis`
`xlayer``circle`, `ethena`, `makerdao`, `paxos`, `tether`
`zksyncera``circle`, `ethena`, `fraxstablecoin`, `goal3`, `gravita`, `noon`, `tether`
## Tables [Metrics](/docs/catalog/stablecoins/metrics) holds the daily table schemas at each grain and example queries. [Registry](/docs/catalog/stablecoins/registry) holds the identity tables, and [Balances](/docs/catalog/stablecoins/balances) computes holder balances at any past date. Each event has its own page and its own table: [Transfers](/docs/catalog/stablecoins/transfers) and [Supply changes](/docs/catalog/stablecoins/supply-changes). # Metrics Source: https://tokenterminal.com/docs/catalog/stablecoins/metrics Daily stablecoin figures per stablecoin and per deployment. Supply, holders, transfer activity, price and peg deviation. One row per thing per day, at three grains: stablecoin, stablecoin and chain, and deployment. ## Tables A tab per grain. [Coverage](/docs/catalog/stablecoins) shows which issuers report which measure. **Stablecoin** One row per stablecoin per day.
Table Value column What it holds
`metrics_assets.market_cap_circulating_daily``market_cap_circulating`Circulating market cap across every representation of the asset, native issuance plus bridged wrappers plus any off-chain component.
`metrics_assets.app_tvl_daily``app_tvl`Value of the asset deposited into onchain apps -- lending markets, DEX pools and vaults
`metrics_assets.app_trading_volume_daily``app_trading_volume`Value of spot trades involving the asset on onchain venues -- DEX pools and onchain order books -- USD
`metrics_assets.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of natively-issued deployments only.
`metrics_assets.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of bridged deployments only, wrapped representations of supply issued elsewhere.
`metrics_assets.market_cap_circulating_offchain_daily``market_cap_circulating_offchain`Circulating market cap the issuer reports off-chain, the portion of a fund's NAV no token contract represents.
`metrics_assets.price_daily``price`Asset price in USD (canonical across sources).
`metrics_assets.off_peg_daily``off_peg`Deviation from the asset's peg.
`metrics_assets.holders_daily``holders`Distinct holders summed across every deployment of the asset; an address on two chains counts twice.
`metrics_assets.holders_native_daily``holders_native`Distinct holders across the asset's natively-issued deployments only.
`metrics_assets.holders_bridged_daily``holders_bridged`Distinct holders across the asset's bridged deployments only.
`metrics_assets.mints_daily``mints`Value minted (issued) across every deployment; a bridged mint is a distinct event, so this is a real total.
`metrics_assets.mints_native_daily``mints_native`Value minted (issued) on natively-issued deployments only.
`metrics_assets.mints_bridged_daily``mints_bridged`Value minted (issued) on bridged deployments only.
`metrics_assets.redemptions_daily``redemptions`Value redeemed (burned) across every deployment; a bridged burn is a distinct event, so this is a real total.
`metrics_assets.redemptions_native_daily``redemptions_native`Value redeemed (burned) on natively-issued deployments only.
`metrics_assets.redemptions_bridged_daily``redemptions_bridged`Value redeemed (burned) on bridged deployments only.
`metrics_assets.transfer_count_daily``transfer_count`Number of transfers across every deployment; a bridged transfer is a distinct event, so this is a real total.
`metrics_assets.transfer_count_native_daily``transfer_count_native`Number of transfers on natively-issued deployments only.
`metrics_assets.transfer_count_bridged_daily``transfer_count_bridged`Number of transfers on bridged deployments only.
`metrics_assets.transfer_volume_daily``transfer_volume`Value transferred across every deployment; a bridged transfer is a distinct event, so this is a real total.
`metrics_assets.transfer_volume_native_daily``transfer_volume_native`Value transferred on natively-issued deployments only.
`metrics_assets.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on bridged deployments only.
`metrics_assets.daily_active_users_daily``daily_active_users`Distinct addresses sending the asset on the day, across every deployment.
`metrics_assets.weekly_active_users_daily``weekly_active_users`Distinct addresses sending the asset in the trailing 7 days, across every deployment.
`metrics_assets.monthly_active_users_daily``monthly_active_users`Distinct addresses sending the asset in the trailing 30 days, across every deployment.
**Stablecoin and chain** One row per stablecoin per chain per day. Keyed on `asset_chain_id` and `timestamp`, which is written `{asset_id}-{chain_id}` and joins `dimensions.assets_by_chain`. Every measure rolls up the stablecoin's deployments on that chain.
Table Value column What it holds
`metrics_assets_by_chain.app_tvl_daily``app_tvl`Value of the asset deposited into onchain apps -- lending markets, DEX pools and vaults
`metrics_assets_by_chain.app_trading_volume_daily``app_trading_volume`Value of spot trades involving the asset on onchain venues -- DEX pools and onchain order books -- USD
`metrics_assets_by_chain.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of natively-issued deployments only
`metrics_assets_by_chain.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of bridged deployments only, wrapped representations of supply issued elsewhere
`metrics_assets_by_chain.market_cap_circulating_daily``market_cap_circulating`Circulating market cap of the asset on the chain, USD, summed across every deployment there, native and bridged.
`metrics_assets_by_chain.holders_daily``holders`Distinct holders summed across every deployment of the asset, native and bridged
`metrics_assets_by_chain.holders_native_daily``holders_native`Distinct holders across the asset's natively-issued deployments only
`metrics_assets_by_chain.holders_bridged_daily``holders_bridged`Distinct holders across the asset's bridged deployments only
`metrics_assets_by_chain.mints_native_daily``mints_native`Value minted (issued) on natively-issued deployments only
`metrics_assets_by_chain.mints_bridged_daily``mints_bridged`Value minted (issued) on bridged deployments only
`metrics_assets_by_chain.mints_daily``mints`Value minted (issued) across every deployment; a bridged mint is a distinct event, so this is a real total
`metrics_assets_by_chain.redemptions_native_daily``redemptions_native`Value redeemed (burned) on natively-issued deployments only
`metrics_assets_by_chain.redemptions_bridged_daily``redemptions_bridged`Value redeemed (burned) on bridged deployments only
`metrics_assets_by_chain.redemptions_daily``redemptions`Value redeemed (burned) across every deployment; a bridged burn is a distinct event, so this is a real total
`metrics_assets_by_chain.transfer_count_native_daily``transfer_count_native`Number of transfers on natively-issued deployments only
`metrics_assets_by_chain.transfer_count_bridged_daily``transfer_count_bridged`Number of transfers on bridged deployments only
`metrics_assets_by_chain.transfer_count_daily``transfer_count`Number of transfers across every deployment; a bridged transfer is a distinct event, so this is a real total
`metrics_assets_by_chain.transfer_volume_native_daily``transfer_volume_native`Value transferred on natively-issued deployments only
`metrics_assets_by_chain.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on bridged deployments only
`metrics_assets_by_chain.transfer_volume_daily``transfer_volume`Value transferred across every deployment; a bridged transfer is a distinct event, so this is a real total
`metrics_assets_by_chain.daily_active_users_daily``daily_active_users`Distinct addresses sending the asset on the day, across every deployment
`metrics_assets_by_chain.weekly_active_users_daily``weekly_active_users`Distinct addresses sending the asset in the trailing 7 days, across every deployment
`metrics_assets_by_chain.monthly_active_users_daily``monthly_active_users`Distinct addresses sending the asset in the trailing 30 days, across every deployment
**Deployment** One row per deployment per day.
Table Value column What it holds
`metrics_asset_tokens.app_tvl_daily``app_tvl`Value of the deployment deposited into onchain apps -- lending markets, DEX pools and vaults
`metrics_asset_tokens.app_trading_volume_daily``app_trading_volume`Value of spot trades involving the deployment on onchain venues -- DEX pools and onchain order books -- USD, all venues together
`metrics_asset_tokens.market_cap_circulating_daily``market_cap_circulating`Circulating market cap of the deployment, native or bridged.
`metrics_asset_tokens.market_cap_circulating_native_daily``market_cap_circulating_native`Circulating market cap of the deployment; natively-issued deployments only.
`metrics_asset_tokens.market_cap_circulating_bridged_daily``market_cap_circulating_bridged`Circulating market cap of the deployment; bridged deployments only, wrapped representations of supply issued elsewhere.
`metrics_asset_tokens.holders_daily``holders`Addresses holding a non-zero balance of the deployment, native or bridged.
`metrics_asset_tokens.holders_native_daily``holders_native`Addresses holding a non-zero balance of the deployment; natively-issued deployments only.
`metrics_asset_tokens.holders_bridged_daily``holders_bridged`Addresses holding a non-zero balance of the deployment; bridged deployments only.
`metrics_asset_tokens.mints_daily``mints`Value minted (issued) on the deployment, native or bridged.
`metrics_asset_tokens.mints_native_daily``mints_native`Value minted (issued) on the deployment; natively-issued deployments only.
`metrics_asset_tokens.mints_bridged_daily``mints_bridged`Value minted (issued) on the deployment; bridged deployments only.
`metrics_asset_tokens.redemptions_daily``redemptions`Value redeemed (burned) on the deployment, native or bridged.
`metrics_asset_tokens.redemptions_native_daily``redemptions_native`Value redeemed (burned) on the deployment; natively-issued deployments only.
`metrics_asset_tokens.redemptions_bridged_daily``redemptions_bridged`Value redeemed (burned) on the deployment; bridged deployments only.
`metrics_asset_tokens.transfer_count_daily``transfer_count`Transfers on the deployment, native or bridged.
`metrics_asset_tokens.transfer_count_native_daily``transfer_count_native`Transfers on the deployment; natively-issued deployments only.
`metrics_asset_tokens.transfer_count_bridged_daily``transfer_count_bridged`Transfers on the deployment; bridged deployments only.
`metrics_asset_tokens.transfer_volume_daily``transfer_volume`Value transferred on the deployment, native or bridged.
`metrics_asset_tokens.transfer_volume_native_daily``transfer_volume_native`Value transferred on the deployment; natively-issued deployments only.
`metrics_asset_tokens.transfer_volume_bridged_daily``transfer_volume_bridged`Value transferred on the deployment; bridged deployments only.
`metrics_asset_tokens.daily_active_users_native_daily``daily_active_users_native`Distinct addresses sending the deployment's token on the day; natively-issued deployments only.
`metrics_asset_tokens.daily_active_users_bridged_daily``daily_active_users_bridged`Distinct addresses sending the deployment's token on the day; bridged deployments only.
`metrics_asset_tokens.weekly_active_users_native_daily``weekly_active_users_native`Distinct addresses sending the deployment's token in the trailing 7 days; natively-issued deployments only.
`metrics_asset_tokens.weekly_active_users_bridged_daily``weekly_active_users_bridged`Distinct addresses sending the deployment's token in the trailing 7 days; bridged deployments only.
`metrics_asset_tokens.monthly_active_users_native_daily``monthly_active_users_native`Distinct addresses sending the deployment's token in the trailing 30 days; natively-issued deployments only.
`metrics_asset_tokens.monthly_active_users_bridged_daily``monthly_active_users_bridged`Distinct addresses sending the deployment's token in the trailing 30 days; bridged deployments only.
## Sample queries **Supply and peg together** Each measure is its own table, so a row with both is a join on `asset_id` and `timestamp`, bounded on each side. `off_peg` reads as a decimal fraction of the peg measured against the peg currency's end-of-day rate, so `-0.02` is two percent below. ```sql theme={null} with supply as ( select timestamp, market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` where asset_id = 'usdt' and timestamp >= timestamp('2026-06-01') ), peg as ( select timestamp, off_peg from `metrics_assets.off_peg_daily` where asset_id = 'usdt' and timestamp >= timestamp('2026-06-01') ) select timestamp, supply.market_cap_circulating_native, peg.off_peg from supply full join peg using (timestamp) order by timestamp ``` **Stablecoins by supply** `dimensions.assets` has `asset_type`, so the stablecoin filter is a join to it. ```sql theme={null} select assets.symbol, daily.market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` as daily join `dimensions.assets` as assets using (asset_id) where daily.timestamp = timestamp('2026-08-01') and assets.asset_type = 'stablecoin' order by daily.market_cap_circulating_native desc limit 25 ``` **One stablecoin by chain** The deployment tables key on `asset_token_id`, and `dimensions.asset_tokens` has the chain and the issuance status behind that key. ```sql theme={null} select deployments.chain_id, deployments.bridged_status, daily.market_cap_circulating from `metrics_asset_tokens.market_cap_circulating_daily` as daily join `dimensions.asset_tokens` as deployments using (asset_token_id) where daily.timestamp = timestamp('2026-08-01') and deployments.asset_id = 'usdc' order by daily.market_cap_circulating desc ``` **Native against bridged** Native and bridged supply are separate measures in separate tables, and the product total is the native column added up. A bridged row has supply with an empty `mints`, because a wrapper arrives by bridge. ```sql theme={null} with deployments as ( select asset_token_id, chain_id, token_address, bridged_status from `dimensions.asset_tokens` where asset_id = 'eurc' ), native as ( select asset_token_id, market_cap_circulating_native from `metrics_asset_tokens.market_cap_circulating_native_daily` where timestamp = timestamp('2026-08-01') ), bridged as ( select asset_token_id, market_cap_circulating_bridged from `metrics_asset_tokens.market_cap_circulating_bridged_daily` where timestamp = timestamp('2026-08-01') ), mints as ( select asset_token_id, mints from `metrics_asset_tokens.mints_daily` where timestamp = timestamp('2026-08-01') ), redemptions as ( select asset_token_id, redemptions from `metrics_asset_tokens.redemptions_daily` where timestamp = timestamp('2026-08-01') ) select deployments.chain_id, deployments.token_address, deployments.bridged_status, native.market_cap_circulating_native, bridged.market_cap_circulating_bridged, mints.mints, redemptions.redemptions from deployments left join native using (asset_token_id) left join bridged using (asset_token_id) left join mints using (asset_token_id) left join redemptions using (asset_token_id) order by native.market_cap_circulating_native desc ``` **Stablecoin against its deployments** Circulating supply is the one measure where the two grains can differ. Supply an issuer reports off-chain sits in the stablecoin row and in `metrics_assets.market_cap_circulating_offchain_daily`, and accounts for the difference. ```sql theme={null} with deployment_sum as ( select tokens.asset_id, daily.timestamp, sum(daily.market_cap_circulating_native) as summed from `metrics_asset_tokens.market_cap_circulating_native_daily` as daily join `dimensions.asset_tokens` as tokens using (asset_token_id) where tokens.asset_id = 'usdt' and daily.timestamp >= timestamp('2026-08-01') group by tokens.asset_id, daily.timestamp ), asset_level as ( select asset_id, timestamp, market_cap_circulating_native from `metrics_assets.market_cap_circulating_native_daily` where asset_id = 'usdt' and timestamp >= timestamp('2026-08-01') ) select timestamp, asset_level.market_cap_circulating_native as stablecoin_grain, deployment_sum.summed as deployment_grain from asset_level left join deployment_sum using (asset_id, timestamp) order by timestamp ``` **Peg deviation across the sector** Some stablecoins take their price from the peg rate itself, marked `price_source = 'peg'` on `metrics_assets.price_daily`, and their `off_peg` is zero by construction. Joining that table filters them out of a ranking by tightest peg. ```sql theme={null} select assets.symbol, assets.peg_currency, peg.off_peg from `metrics_assets.off_peg_daily` as peg join `metrics_assets.price_daily` as prices using (asset_id, timestamp) join `dimensions.assets` as assets using (asset_id) where peg.timestamp = timestamp('2026-08-01') and assets.asset_type = 'stablecoin' and prices.price_source != 'peg' order by abs(peg.off_peg) desc limit 25 ``` # Registry Source: https://tokenterminal.com/docs/catalog/stablecoins/registry Stablecoin identity: peg currency, MiCA classification, the issuer behind it and every chain it is deployed on. The identity tables behind every stablecoin figure. Every fact and metric joins to one of them, and [Coverage](/docs/catalog/stablecoins) introduces each grain. ## Tables **Stablecoins** One row per stablecoin: `dimensions.assets` filtered on `asset_type = 'stablecoin'`.
Column Type Description
`asset_id` `STRING` Identifier of the asset, for example `usdc`.
`reference_asset_id` `STRING` What the asset tracks or wraps. Joins `dimensions.reference_assets`.
`name` `STRING` Display name of the asset.
`symbol` `STRING` Ticker symbol of the asset.
`asset_type` `STRING` What kind of instrument it is: `stablecoin`, `tokenized-stocks`, `tokenized-funds`, `lending-token`, `tokenized-commodities`, `liquid-staking-token`, `tokenized-cryptoasset` or `wrapped_native`.
`description` `STRING` Short description of the asset.
`custom_price_fx_peg` `STRUCT` A fixed rate the asset is priced at rather than a market quote, in `currency`, `multiplier` and `priority`. Set only where the asset declares one, and `priority` says whether the rate overrides the market price or only fills in where there is none.
`created_at` `TIMESTAMP` When the asset entered the registry.
`metrics_verified_at` `TIMESTAMP` When the asset's published metrics were last verified. Null while unverified.
`mica_marker` `STRING` Which MiCA category the peg implies: `emt_by_peg` for single-currency stablecoins, `art_by_peg` for other stablecoins, `other_crypto_asset` or `out_of_scope_financial_instrument` for everything else. A marker, not a regulatory ruling.
`mica_authorization_status` `STRING` Whether the token is authorized under MiCA according to the official register: `emt_authorized`, `art_authorized`, `not_authorized`, `application_withdrawn`, `out_of_scope_mifid`, `other_crypto_asset` or `not_checked`. A sourced regulatory fact, unlike `mica_marker`, which is read off the peg.
`regulatory_supervised` `STRING` What the issuer discloses about its own supervision: `true`, `false` or `unknown`. A disclosure, never an inference.
`regulator` `STRING` The authority the issuer names as its supervisor, such as `NYDFS/FinCEN`. Empty where the issuer names none.
`reserves_source` `STRING` Where the reserve figure comes from: `attestation` for an issuer-published report, `onchain` where the backing addresses are identified and the balance computed here, `none` where the issuer publishes nothing.
`reserves_attestor` `STRING` The firm signing the attestation, filled in where `reserves_source` is `attestation`.
`return_treatment` `STRING` How the token treats the income the underlying pays: `total_return`, `price_return`, `price_return_with_distribution` or `not_applicable`. Keyed on the token rather than on what it tracks, so two tokenizations of one share can differ.
`issuer_legal_name` `STRING` The issuing entity as a government register spells it, which is routinely not the brand.
`issuer_domicile` `STRING` ISO 3166-1 alpha-2 country code of where the issuing entity is registered, such as `US`. Resolved from the issuing project, so it is null when that project has no domicile on file.
`issuer_lei` `STRING` Legal Entity Identifier of the issuing entity.
`issuer_cik` `STRING` SEC Central Index Key of the issuing entity.
`issuer_regulatory_framework` `ARRAY` Regimes the issuing entity operates under. An array because an entity can sit under several at once.
`issuer_legal_source_url` `STRING` The filing or register the legal fields above were read from, with `issuer_legal_retrieved_at` recording when.
`issuer_legal_retrieved_at` `STRING` When `issuer_legal_source_url` was last read.
`use_of_income` `STRING` What the issuer says it does with the income the underlying pays, in its own words. `return_treatment` is the coded answer to the same question.
`isin` `STRING` International Securities Identification Number of the instrument, where it has one.
`cusip` `STRING` CUSIP of the instrument, where it has one.
`peg_currency` `STRING` ISO currency code of the peg, set when the asset tracks a national currency. Empty otherwise: a fund strategy, a share or a commodity is not a peg.
`project_relations` `ARRAY` Every project linked to the asset, one element per `(project_id, relation)`. `relation` is `issuer`, `asset_manager`, `risk_curator` or `manager`. Most assets link to one project; a few link to several, such as an issuer alongside a separate manager.
`issuer_project_id` `STRING` The project whose relation is `issuer`, when exactly one project holds that relation. Empty when none do, and empty when more than one does; read `project_relations` for the full set.
`coingecko_id` `STRING` Identifier of the same asset in the CoinGecko catalogue, for joining our record to a public one.
`coinmarketcap_id` `STRING` Identifier of the same asset in the CoinMarketCap catalogue, for the same purpose.
`yahoo_ticker` `STRING` Ticker the underlying trades under on Yahoo Finance, where it is listed.
**Deployments** One row per token contract on one chain, in `dimensions.asset_tokens`. `bridged_status` is the classification the supply measures split on.
Column Type Description
`asset_token_id` `STRING` Identifier of the deployment, formatted `{asset_id}-{token_address}-{chain_id}`.
`asset_id` `STRING` Asset the deployment belongs to. Joins `dimensions.assets`.
`token_id` `STRING` Key of the deployment in `dimensions.tokens`, formatted `{token_address}-{chain_id}`.
`chain_id` `STRING` Chain the contract is deployed on.
`token_address` `STRING` Address of the token contract.
`is_bridged` `BOOL` Raw registry flag: bridged in rather than issued natively. Always present, so `false` means native or unstated. Filter on `bridged_status` instead.
`bridged_status` `STRING` The classification supply measures split on: `native`, `bridged` or `unclassified`.
## Sample queries **By peg currency** `peg_currency` holds the ISO code of the national currency the asset tracks, and `off_peg` on [Metrics](/docs/catalog/stablecoins/metrics) measures against that currency's end-of-day rate. ```sql theme={null} select peg_currency, count(*) as assets from `dimensions.assets` where asset_type = 'stablecoin' group by peg_currency order by assets desc ``` **MiCA candidates** `mica_marker` follows from the peg alone: `art_by_peg` marks a stablecoin that references something other than a single currency, and `emt_by_peg` a single-currency one. ```sql theme={null} select asset_id, symbol, peg_currency, reference_asset_id, mica_marker from `dimensions.assets` where asset_type = 'stablecoin' and mica_marker = 'art_by_peg' order by asset_id ``` **Who issues what** `issuer_project_id` is the project holding the `issuer` relation, and it is the row subject of the matrix on [Coverage](/docs/catalog/stablecoins). ```sql theme={null} select assets.issuer_project_id, projects.name, count(*) as stablecoins from `dimensions.assets` as assets join `dimensions.projects` as projects on projects.project_id = assets.issuer_project_id where assets.asset_type = 'stablecoin' group by assets.issuer_project_id, projects.name order by stablecoins desc limit 25 ``` **Pegs against deployments** Counting native and bridged deployments apart shows where wrappers concentrate, and so where a careless supply total double counts. ```sql theme={null} select assets.peg_currency, assets.mica_marker, count(distinct assets.asset_id) as stablecoins, countif(deployments.bridged_status = 'native') as native_deployments, countif(deployments.bridged_status = 'bridged') as bridged_deployments, count(distinct deployments.chain_id) as chains from `dimensions.assets` as assets left join `dimensions.asset_tokens` as deployments using (asset_id) where assets.asset_type = 'stablecoin' group by assets.peg_currency, assets.mica_marker order by stablecoins desc ``` **Deployments of one stablecoin** `bridged_status` reads `native`, `bridged` or `unclassified`, and it is the column issuance filters on. ```sql theme={null} select deployments.asset_token_id, deployments.chain_id, deployments.token_address, deployments.bridged_status from `dimensions.asset_tokens` as deployments join `dimensions.assets` as assets using (asset_id) where assets.asset_type = 'stablecoin' and assets.asset_id = 'usdc' order by deployments.chain_id ``` # Supply changes Source: https://tokenterminal.com/docs/catalog/stablecoins/supply-changes Every stablecoin mint and burn. > [!NOTE] > > **In progress.** This table is on the way. [Contact us](mailto:sales@tokenterminal.xyz) if you are interested in this dataset. We want to hear more about your use case! One row per stablecoin mint and burn, at the moment it happened onchain, which resolves a day's supply movement to the issuance events behind it. `mints` and `redemptions` on [Metrics](/docs/catalog/stablecoins/metrics) hold the daily totals of the same events, and `event_type` on [Transfers](/docs/catalog/stablecoins/transfers) marks them one by one. # Transfers Source: https://tokenterminal.com/docs/catalog/stablecoins/transfers Every stablecoin transfer, mint and burn. One row per stablecoin movement: a transfer, a mint or a burn of one deployment, at the moment it happened onchain. `amount_raw` is the movement in the token's smallest unit; divide by `10^decimals` from [`dimensions.tokens`](/docs/catalog/tokens/registry) for a token amount. ## Columns
Column Type Description
`partition_key``TIMESTAMP`The month the row belongs to. The table is partitioned on it, so a date filter is cheapest when it names this alongside `block_timestamp`.
`block_timestamp``TIMESTAMP`When the block was produced.
`block_number``INT64`Block height, or the slot on Solana.
`transaction_hash``STRING`Transaction the movement belongs to. Null on `hydradx`, where a transfer can be emitted by a block hook rather than by a transaction.
`transaction_index``INT64`Position of the transaction in its block. Solana only.
`outer_event_index``INT64`Enclosing instruction position on Solana. Null on the log-shaped chains, which have one nesting level, and null on Solana wherever the instruction is top level and has nothing enclosing it.
`event_index``INT64`Position within the transaction: the log index, or the instruction index on Solana.
`chain_id``STRING`Chain the movement happened on.
`token_type``STRING`Token standard: `erc20`, `spl` or `trc20`.
`token_id``STRING`Join key to [`dimensions.tokens`](/docs/catalog/tokens/registry) and to [`dimensions.asset_tokens`](/docs/catalog/assets/registry), which is what names the stablecoin.
`token_address``STRING`The token. Filter on this. Null on the Solana transfers whose token account the upstream decode could not resolve, which also leaves `token_id` null.
`event_type``STRING``transfer`, `mint` or `burn`.
`from_address``STRING`Account debited. Null on a mint.
`to_address``STRING`Account credited. Null on a burn.
`to_owner``STRING`Holder behind `to_address`. Solana transfers only: null on exactly the rows where `token_address` is, and always null on mints and burns.
`authority_address``STRING`Account that authorised the instruction. Solana only.
`transaction_signer``STRING`Signer of the enclosing transaction. Solana only.
`executing_account``STRING`Program that executed the instruction. Solana only.
`amount_raw``STRING`Amount in the token's smallest unit, as a decimal string, because a uint256 exceeds every BigQuery numeric type. Divide by `10^decimals`.
`surrogate_key``BYTES`Row identity, a 128-bit hash of the columns that define the grain. Stable across rebuilds; nothing else needs it.
## Sample queries > [!WARNING] > > This table is large and split by day. Bound `block_timestamp` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One stablecoin, one day** Joining `dimensions.asset_tokens` on `token_id` is what keeps the stablecoin rows, and the same join names the asset. The table is clustered on `token_address` then `chain_id`, and naming the pair reads less than the address alone. ```sql theme={null} select transfers.block_timestamp, transfers.transaction_hash, transfers.from_address, transfers.to_address, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.asset_tokens` as deployments using (token_id) join `dimensions.tokens` as tokens on tokens.token_id = transfers.token_id where deployments.asset_id = 'usdc' and transfers.chain_id = 'ethereum' and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-02') limit 100 ``` **Largest native movements** `bridged_status` keeps the natively issued deployments, the side that answers a question about the issuer. ```sql theme={null} select assets.symbol, transfers.block_timestamp, transfers.transaction_hash, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.asset_tokens` as deployments using (token_id) join `dimensions.assets` as assets on assets.asset_id = deployments.asset_id join `dimensions.tokens` as tokens on tokens.token_id = transfers.token_id where assets.asset_type = 'stablecoin' and deployments.bridged_status = 'native' and transfers.chain_id = 'ethereum' and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') order by amount desc limit 20 ``` **Issuance in a window** `event_type` separates the three movements, and a mint leaves `from_address` empty and a burn `to_address`. The daily totals behind the same events are `mints` and `redemptions` on [Metrics](/docs/catalog/stablecoins/metrics). ```sql theme={null} select transfers.event_type, count(*) as movements, sum(cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals)) as amount from `facts_tokens.transfers` as transfers join `dimensions.asset_tokens` as deployments using (token_id) join `dimensions.tokens` as tokens on tokens.token_id = transfers.token_id where deployments.asset_id = 'usdc' and transfers.chain_id = 'ethereum' and transfers.event_type in ('mint', 'burn') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') group by transfers.event_type ``` # Balances Source: https://tokenterminal.com/docs/catalog/tokens/balances Holder balances on any past date, computed at query time. Holder balances are computed at query time from [Transfers](/docs/catalog/tokens/transfers): every movement splits into its debit and its credit leg, and the legs add up per account. Each function takes a chain, a token address and a token standard, and reads that token's whole movement history. **There are two pairs, and which one you want depends on the token.** The generic pair below works on any token on any chain the catalog conforms, from transfer records alone. The curated pair works only on the tokenized assets in the registry, and for those it is the one to use: its numbers are reconciled against the supply the mint and burn events account for, and it refuses to answer where the answer would be wrong rather than returning a figure nobody checked. > **Any token** > > `calculate_latest_token_balances` and `calculate_historical_eod_token_balances`, documented below. Broad coverage, no per-issuer handling. On a rebasing token these drift, because a balance that grows without a transfer leaves no record to add up. > **[Tokenized assets](/docs/catalog/assets/balance-changes)** > > `calculate_latest_asset_token_balances` and `calculate_historical_eod_asset_token_balances`. Registry assets only, and they return a refusal rather than a number where a deployment cannot be modelled. **In progress**: under test, not yet served. ## Functions **Latest** `functions.calculate_latest_token_balances` returns the current holders of one token: each account's most recent end-of-day balance, kept where it is positive. Picking the most recent row first and applying the positive filter second is what makes the result the holder set today.
Parameter Type Description
`p_chain_id` `STRING` Chain the token is deployed on, for example `ethereum`.
`p_token_address` `STRING` Contract address of the token. An `erc20` address is lowercased for you, so a checksummed address copied from an explorer resolves; every other standard is matched as the chain writes it, `spl` and `trc20` being base58.
`p_token_type` `STRING` Token standard: `erc20`, `spl` or `trc20`.
Return column Type Description
`account_address` `STRING` Account holding a positive balance: a wallet on the log-shaped chains, an SPL token account on Solana.
`balance` `BIGNUMERIC` Latest end-of-day balance in token units. Added up in exact whole-number arithmetic and scaled by the token's `decimals`, so a drained account reads exactly zero and leaves the holder set.
**Historical** `functions.calculate_historical_eod_token_balances` returns each holder's end-of-day balance, one row per day the balance moved. A balance on any date is the most recent row at or before that date, so an account that moved tokens on Monday and again on Friday reads its Monday balance until Friday's row replaces it.
Parameter Type Description
`p_chain_id` `STRING` Chain the token is deployed on, for example `ethereum`.
`p_token_address` `STRING` Contract address of the token. An `erc20` address is lowercased for you, so a checksummed address copied from an explorer resolves; every other standard is matched as the chain writes it, `spl` and `trc20` being base58.
`p_token_type` `STRING` Token standard: `erc20`, `spl` or `trc20`.
Return column Type Description
`balance_date` `DATE` Day the balance moved.
`account_address` `STRING` Account holding the balance: a wallet on the log-shaped chains, an SPL token account on Solana.
`balance` `BIGNUMERIC` End-of-day balance in token units. Added up in exact whole-number arithmetic and scaled by the token's `decimals`, so a drained account reads exactly zero.
**Curated (tokenized assets)** > [!NOTE] > > **In progress.** The curated pair is under test and not yet served. [Contact us](mailto:sales@tokenterminal.xyz) if you want early access. `functions.calculate_latest_asset_token_balances` and `functions.calculate_historical_eod_asset_token_balances` take the same three parameters and cover the [tokenized asset registry](/docs/catalog/assets/registry) only. They add two columns to the ones above, because a curated answer states whether it is trustworthy. **A refusal is a row, not an empty result.** Where a deployment is unmodelled, fails to reconcile, or falls outside the curated registry, the function returns exactly one row with `served` false, a reason, and `NULL` in every numeric column. An empty result would be indistinguishable from a token nobody holds or from a mistyped address, and an aggregate over a refusal reads `NULL` rather than a plausible wrong total. Check `served` before using a number. A caller who ignores it and sums `balance` gets `NULL`. That is the right answer to an unanswerable question. `account_owner` below resolves the Solana token accounts that otherwise count one wallet as several holders.
Return column Type Description
`served` `BOOL` Whether the numbers in this row mean anything. False on the single refusal row.
`refusal_reason` `STRING` Why, in plain language, when `served` is false. Names the generic function where the token simply is not a curated asset.
`account_owner` `STRING` The holder, where the chain distinguishes a holding account from its owner as Solana does. **Group by this for a cap table**, or one wallet's several token accounts each count as a holder.
## Sample queries **Current holders** Each call adds up the token's whole movement history, so a one-off holder set costs a full scan. [Assets ▸ Metrics](/docs/catalog/assets/metrics) holds a daily supply and holder-count series for curated assets. ```sql theme={null} select account_address, balance from `functions.calculate_latest_token_balances`( 'ethereum', '0xdac17f958d2ee523a2206206994597c13d831ec7', 'erc20' ) order by balance desc limit 100 ``` **Holders on a date** The most recent row at or before the date is the balance on that date, so `row_number()` picks it per account. Accounts at zero are filtered after that row is picked. ```sql theme={null} with balances_on_date as ( select account_address, balance, row_number() over (partition by account_address order by balance_date desc) as recency from `functions.calculate_historical_eod_token_balances`( 'ethereum', '0xdac17f958d2ee523a2206206994597c13d831ec7', 'erc20' ) where balance_date <= date '2026-06-30' ) select account_address, balance from balances_on_date where recency = 1 and balance > 0 order by balance desc limit 100 ``` **Holder concentration** The holder set is every address holding the token on that date, so a share of supply is worked out over the whole set. [`dimensions.accounts`](/docs/catalog/accounts/registry) names the addresses somebody has attributed, so pools and receipt-token contracts read as themselves. ```sql theme={null} with balances_on_date as ( select account_address, balance, row_number() over (partition by account_address order by balance_date desc) as recency from `functions.calculate_historical_eod_token_balances`( 'ethereum', '0x6c3ea9036406852006290770bedfcaba0e23a0e8', 'erc20' ) where balance_date <= date '2026-06-30' ), holders as ( select account_address, balance, row_number() over (order by balance desc) as holder_rank, sum(balance) over () as supply_held, count(*) over () as holders from balances_on_date where recency = 1 and balance > 0 ) select holders.holder_rank, holders.account_address, accounts.contract_name, projects.name as project, holders.balance, holders.balance / holders.supply_held as share_of_supply, holders.holders as holders_on_date from holders left join `dimensions.accounts` as accounts on accounts.account_id = concat(holders.account_address, '-ethereum') left join `dimensions.projects` as projects on projects.project_id = accounts.project_id where holders.holder_rank <= 20 order by holders.holder_rank ``` # Tokens Source: https://tokenterminal.com/docs/catalog/tokens/index Every token we see onchain: the contracts, their movements, balances and prices. A token is one contract on one chain: * USDT on Ethereum, `0xdac17f958d2ee523a2206206994597c13d831ec7` * USDC on Solana, `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` Every table in this section keys on `token_id`, which is `{token_address}-{chain_id}`, so the same instrument issued on two chains is two tokens and a bridged wrapper of it is a third. Grouping several tokens into one instrument is a judgment somebody makes, and it lives on [Assets](/docs/catalog/assets/index). Where a token has been matched to a curated asset, `dimensions.asset_tokens` names it on the same `token_id`. ## Coverage Every chain we cover tokens on. `acala` `alephzeroevm` `algorand` `aptos` `arbitrum` `astar` `avalanche` `base` `berachain` `blast` `bob` `bobanetwork` `bsc` `cardano` `celestia` `celo` `centrifuge` `chainflip` `cosmoshub` `dydx` `ethereum` `fantom` `flow` `flowevm` `fraxtal` `gnosis` `gravityalpha` `hedera` `hydradx` `hydradxevm` `hyperevm` `immutablezkevm` `injective` `injectiveevm` `ink` `interlay` `iotex` `katananetwork` `linea` `manta` `mantaatlantic` `mantra` `mantrachain` `mantraevm` `megaeth` `monad` `moonbeam` `movement` `near` `neuroweb` `noble` `opbnb` `optimism` `osmosis` `peaq` `phala` `plasma` `polimec` `polkadex` `polkadotassethub` `polygon` `ripple` `robinhoodchain` `ronin` `rootstock` `scroll` `sei` `seievm` `solana` `sonic` `stacks` `starknet` `stellar` `sui` `tempo` `ton` `tron` `unichain` `viction` `worldchain` `xai` `xdc` `xlayer` `zksyncera` ## Tables [Registry](/docs/catalog/tokens/registry) holds the identity table, and [Transfers](/docs/catalog/tokens/transfers) every fungible movement. [Balances](/docs/catalog/tokens/balances) adds those movements up into holder balances at query time, and [Prices](/docs/catalog/tokens/metrics) holds the USD price per token, by day and by hour. # Metrics Source: https://tokenterminal.com/docs/catalog/tokens/metrics One USD price per token per day, and per hour. `metrics_tokens.price_daily` holds one row per token per day: the price in USD at midnight UTC. `metrics_tokens.price_hourly` holds the same figure at the top of every hour. ## Columns Both tables share one schema.
Column Type Description
`timestamp` `TIMESTAMP` The moment the price was taken: midnight UTC in the daily table, the top of the hour in the hourly one.
`token_id` `STRING` Token the price belongs to: `{token_address}-{chain_id}`. Joins [`dimensions.tokens`](/docs/catalog/tokens/registry).
`chain_id` `STRING` Chain the token is deployed on.
`price` `FLOAT64` The price in US dollars at that moment. Every row has a value, and a token has a row on each day it was priced, so a null after a left join is a missing row.
## Sample queries **Daily** The daily table suits long histories and joins to the other daily tables at a fraction of the hourly table's size. `token_id` is the key on both sides of the join. ```sql theme={null} select prices.timestamp, tokens.symbol, tokens.name, prices.price from `metrics_tokens.price_daily` as prices join `dimensions.tokens` as tokens using (token_id) where prices.token_id = '0xdac17f958d2ee523a2206206994597c13d831ec7-ethereum' and prices.timestamp >= timestamp('2026-07-01') order by prices.timestamp ``` **Hourly** The hourly table suits analysis within a day, and pricing individual events. Both tables key the same way, so moving a query between them means swapping the table name and the time bounds. ```sql theme={null} select timestamp, price from `metrics_tokens.price_hourly` where token_id = '0xdac17f958d2ee523a2206206994597c13d831ec7-ethereum' and timestamp >= timestamp('2026-08-20') and timestamp < timestamp('2026-08-23') order by timestamp ``` # Registry Source: https://tokenterminal.com/docs/catalog/tokens/registry One row per token: address, symbol, decimals and launch. The identity table behind every token figure. Every other table about tokens joins to it, and [Coverage](/docs/catalog/tokens) names the chains. ## Columns
Column Type Description
`token_id` `STRING` Token identifier: `{token_address}-{chain_id}`. The key every other token table joins on, and every row has a real address in it.
`chain_id` `STRING` Chain the contract is deployed on.
`token_address` `STRING` Contract address. Hex addresses are stored lowercase, and base58 addresses as the chain writes them.
`symbol` `STRING` Symbol read from the contract, unverified. Any contract can call itself USDC, so read `token_address` to know what a token is, or the `asset_id` on `dimensions.asset_tokens` where somebody has already made that judgment.
`name` `STRING` Name read from the contract, unverified.
`decimals` `INT64` How many decimal places to move to turn a raw amount into a token amount.
`created_at` `TIMESTAMP` When the token launched onchain.
## Sample queries **By address** `token_id` is the address and the chain joined by a dash, so one literal names one contract on one chain. `symbol` and `name` come off the contract, so read the address to know what the token is. ```sql theme={null} select token_id, chain_id, token_address, symbol, name, decimals, created_at from `dimensions.tokens` where token_id = '0xdac17f958d2ee523a2206206994597c13d831ec7-ethereum' ``` **Its curated asset** Whether a token is a tokenized asset, and which one, lives on `dimensions.asset_tokens`, one row per deployment, joined on the same `token_id`. The join keeps the tokens somebody has matched to a curated asset. ```sql theme={null} select tokens.token_id, tokens.symbol, deployments.asset_id, deployments.bridged_status from `dimensions.tokens` as tokens join `dimensions.asset_tokens` as deployments using (token_id) where tokens.token_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum' ``` # Transfers Source: https://tokenterminal.com/docs/catalog/tokens/transfers Every fungible token movement, on every chain we decode. One row per fungible token movement: a transfer, a mint or a burn, on every chain we decode. `amount_raw` is the amount in the token's smallest unit, so divide it by `10^decimals` from [`dimensions.tokens`](/docs/catalog/tokens/registry) to read whole tokens. ## Columns
ColumnTypeDescription
`partition_key``TIMESTAMP`The month the row belongs to, as its first instant. The table is partitioned on it, so bound it alongside `block_timestamp`.
`block_timestamp``TIMESTAMP`Time of the block containing the movement.
`block_number``INT64`Block height, or the slot on Solana.
`transaction_hash``STRING`Transaction the movement belongs to. Null on `hydradx`, where a transfer can be emitted by a block hook rather than by a transaction.
`transaction_index``INT64`Position of the transaction in its block. Solana only: a decoded Transfer event on the log-shaped chains is the log, and the transaction around it lives in that chain's own transaction table.
`outer_event_index``INT64`Enclosing instruction position on Solana. A log has one position and an instruction has two, so this is null on the log-shaped chains, and null on a top-level Solana instruction, which has nothing enclosing it.
`event_index``INT64`Position within the transaction: the log index, or the instruction index on Solana.
`chain_id``STRING`Chain the movement happened on.
`token_type``STRING`Token standard: `erc20`, `spl` or `trc20`.
`token_id``STRING`Join key to [`dimensions.tokens`](/docs/catalog/tokens/registry) and the asset tables, which are laid out on it: `{token_address}-{chain_id}`.
`token_address``STRING`The token, and the leading cluster key: filter on this with `chain_id` to read one token, and on this alone to read the address across every chain in one pass. `erc20` addresses are stored lowercase and every other standard as the chain writes it, `spl` and `trc20` being base58. Null on the Solana transfers whose token account the upstream decode could not resolve, which leaves `token_id` null with it.
`event_type``STRING``transfer`, `mint` or `burn`. Solana's token program names it; on the log-shaped chains it is read from the EIP-20 zero address, so a burn sent to some other dead address reads as `transfer`.
`from_address``STRING`Account debited: a wallet on the log-shaped chains, an SPL token account on Solana. Null on a mint.
`to_address``STRING`Account credited: a wallet on the log-shaped chains, an SPL token account on Solana. Null on a burn.
`to_owner``STRING`Holder behind `to_address`, on Solana transfers, where one wallet can own several token accounts. On the log-shaped chains `to_address` is already the holder. Null on exactly the rows where `token_address` is null, since one upstream decode resolves a token account to both its mint and its owner, and null on Solana mints and burns, whose upstream tables hold no owner column.
`authority_address``STRING`Account that authorised the instruction. Solana only.
`transaction_signer``STRING`Signer of the enclosing transaction. Solana only.
`executing_account``STRING`Program that executed the instruction. Solana only.
`amount_raw``STRING`Amount in the token's smallest unit, as a decimal string, because a uint256 exceeds every BigQuery numeric type. Divide by `10^decimals`.
`surrogate_key``BYTES`Row identity: a 128-bit hash of the columns that define the grain, stable across rebuilds. Compare it with `from_hex`.
## Sample queries > [!WARNING] > > This table is large and split by month. Bound `partition_key` and filter `chain_id` on every query, or you read the whole table and the whole table is billed to you. **One token, one day** `token_address` and `chain_id` are the cluster keys and `partition_key` names the month, so the three together read only the blocks this token occupies. Cast `amount_raw` to `BIGNUMERIC` and divide by `10^decimals` from `dimensions.tokens` for whole tokens. ```sql theme={null} select transfers.block_timestamp, transfers.transaction_hash, transfers.from_address, transfers.to_address, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.token_address = '0xdac17f958d2ee523a2206206994597c13d831ec7' and transfers.chain_id = 'ethereum' and transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-02') limit 100 ``` **One token, every chain** Leaving `chain_id` out reads the address on every chain it is deployed at in one pass, which the clustering is built for. `partition_key` still bounds the months the query reads. ```sql theme={null} select transfers.chain_id, count(*) as movements, count(distinct transfers.from_address) as senders from `facts_tokens.transfers` as transfers where transfers.token_address = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48' and transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') group by transfers.chain_id order by movements desc ``` **Largest movements** `amount_raw` is a decimal string, so ordering on it directly sorts lexically. Order on the decimal-corrected amount instead, as here. ```sql theme={null} select transfers.block_timestamp, transfers.transaction_hash, transfers.from_address, transfers.to_address, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.token_address = '0xdac17f958d2ee523a2206206994597c13d831ec7' and transfers.chain_id = 'ethereum' and transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') order by amount desc limit 20 ``` **One token on Solana** An SPL mint address is base58 and is matched as the chain writes it. `from_address` and `to_address` are token accounts here, `to_owner` is the wallet behind the credited one, and [`dimensions.accounts`](/docs/catalog/accounts/registry) names the addresses somebody has attributed. ```sql theme={null} select transfers.block_timestamp, transfers.transaction_hash, transfers.from_address, transfers.to_address, transfers.to_owner, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.token_address = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' and transfers.chain_id = 'solana' and transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-02') limit 100 ``` **Movements in order** `outer_event_index` is null where a chain has one nesting level, so `nulls first` groups those rows together and `event_index` decides inside the group. The same ordering holds on every chain. ```sql theme={null} select transfers.block_timestamp, transfers.transaction_hash, transfers.outer_event_index, transfers.event_index, transfers.from_address, transfers.to_address, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.token_address = '0xdac17f958d2ee523a2206206994597c13d831ec7' and transfers.chain_id = 'ethereum' and transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-02') order by transfers.block_number, transfers.outer_event_index nulls first, transfers.event_index limit 100 ``` **Supply movements** A mint fills `to_address` and a burn fills `from_address`, so `coalesce` picks whichever side the row has. Supply read off these rows stays exact even for a rebasing token, whose holder balances accrue between movements. ```sql theme={null} select transfers.block_timestamp, transfers.event_type, transfers.transaction_hash, coalesce(transfers.to_address, transfers.from_address) as account, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.token_address = '2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo' and transfers.chain_id = 'solana' and transfers.event_type in ('mint', 'burn') and transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') order by transfers.block_timestamp limit 100 ``` **Net flow per account** Splitting each movement into its credit and its debit and summing them replays a balance where a balance moves by movement alone. A rebasing token accrues between movements, and an SPL mint configured for confidential transfers moves value the instruction keeps private, so [the balance functions](/docs/catalog/tokens/balances) inherit the same limit. ```sql theme={null} with legs as ( select transfers.to_address as account_address, cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) as amount from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.token_address = '0xdac17f958d2ee523a2206206994597c13d831ec7' and transfers.chain_id = 'ethereum' and transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') union all select transfers.from_address, -cast(transfers.amount_raw as bignumeric) / pow(10, tokens.decimals) from `facts_tokens.transfers` as transfers join `dimensions.tokens` as tokens using (token_id) where transfers.token_address = '0xdac17f958d2ee523a2206206994597c13d831ec7' and transfers.chain_id = 'ethereum' and transfers.partition_key >= timestamp('2026-08-01') and transfers.partition_key < timestamp('2026-09-01') and transfers.block_timestamp >= timestamp('2026-08-01') and transfers.block_timestamp < timestamp('2026-08-08') ) select account_address, sum(amount) as net_amount from legs where account_address is not null group by account_address order by net_amount desc limit 20 ``` # Contact Source: https://tokenterminal.com/docs/contact Contact us directly, get your project listed, follow us and schedule a demo. ## Contact us directly Reach us on email [people@tokenterminal.xyz](mailto:people@tokenterminal.xyz) or on [Telegram](https://t.me/tokenterminalhq). ## Follow us > Follow us on X for the latest analysis and product updates. > > [Open](https://x.com/tokenterminal) > Follow us on LinkedIn for the latest analysis and product updates. > > [Open](https://www.linkedin.com/company/tokenterminal) > Follow us on YouTube for the latest interviews, demos, and more. > > [Open](https://www.youtube.com/@tokenterminal) ## More way to connect > **[Schedule a demo](https://tokenterminal.com/contact)** > > Want to learn more about Token Terminal? Schedule a demo or introductory call with our partnership team. > **[Get your project listed](https://tokenterminal.com/contact?interest=listing)** > > Tell us about your project through the contact form. Our team will review your submission. # Our data approach Source: https://tokenterminal.com/docs/data-approach We process and store over a petabyte of transaction-level onchain data every day directly from the source, to deliver accurate, auditable metrics you can trust. Token Terminal uses an **ELT (Extract, Load, Transform)** paradigm to process raw blockchain data into standardized metrics. This approach ensures data is transparent, reproducible, and auditable at every stage. In a typical **ETL** workflow, data is transformed before it is stored. This can work well if the structure of your data is stable. But in our industry, things change constantly in ways that are different from most traditional data pipelines. For example: * **Protocol upgrades** Blockchains regularly introduce upgrades that can include breaking changes to data schemas. A protocol might add new transaction types, restructure contract storage, or modify how events are emitted. * **Smart contract deployments** Decentralized applications are continuously launching new products or business lines, often across multiple chains. Each new contract introduces additional data that needs to be standardized and integrated. * **Methodology changes** Even the meaning of common metrics evolves over time. How you define metrics like fees, active users, or token incentives can change as protocols mature and industry practices develop. These factors all make blockchain data feel like ongoing R\&D that happens in production. Because we use **ELT**, we don’t have to re-ingest everything from scratch when something changes. Instead, we can re-process the same raw data and update our standardized metrics quickly, without interrupting downstream workflows. ![ETL vs ELT paradigm](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/etl-vs-elt.png?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=165f882238a450645373e19b185b6099) By keeping raw data in its original form, we gain a few important advantages over the traditional ETL approach: * **Traceability** Every metric can be linked directly back to the source. * **Reproducibility** When new smart contracts are deployed or methodologies change, we can re-process historical data within minutes without waiting days to re-ingest it. * **Scale** This approach allows us to maintain standardized metrics across hundreds of blockchains and thousands of applications efficiently. Whether you're exploring our dashboards, doing analysis in spreadsheets, or querying the API, all data comes from this same high-fidelity data infrastructure. # Discover Source: https://tokenterminal.com/docs/explorer/discover Explore curated dashboards to discover insights and build your own ![Discover hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/discover.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=2a28984f8a656bb89ac07a230feda78d) Discover features curated dashboards created by our research team in collaboration with project teams, as well as select dashboards submitted by external analysts. It serves both as a source of novel insights and as a template library for users who want to fork, modify, and improve dashboards. Forked dashboards remain private and appear only in a user’s personal library. All dashboards refresh automatically once a day. > [!NOTE] > > If you have an interesting dashboard you’d like to feature, reach out to us at [people@tokenterminal.xyz](mailto:people@tokenterminal.xyz). # Introduction Source: https://tokenterminal.com/docs/explorer/index ![Explorer Hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/homepage.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=1d57e110ae36387c084b7d9cd4b82aae) Explorer is our primary no-code interface for accessing standardized metrics. Built on top of our internal data warehouse, Explorer allows users to view data through customizable charts and tables, all of which can be downloaded in CSV format. # Market sectors Source: https://tokenterminal.com/docs/explorer/market-sectors Analyze top market sectors with dashboards and direct project comparisons ![Market sectors hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/market-sectors.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=ad1165d38b5b11b9bce54b6f3ec88af3) We’ve categorized the entire crypto market into **19 distinct market sectors**, with each project on Token Terminal assigned to one sector. This structure enables sector-level analysis and direct comparisons between projects within the same category. Each market sector includes its own dedicated dashboard experience with relevant projects and custom metrics. All views can be filtered by one or more blockchains. # Metrics Source: https://tokenterminal.com/docs/explorer/metrics Understand every metric with clear definitions and project-specific context ![Metrics hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/metrics.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=f6707e3b105b7ce0c8cb6f27bb7ff318) Our Metrics repository contains detailed explanations for every metric maintained by Token Terminal. Each metric includes both a general definition and project-specific descriptions, helping users understand and contextualize the data more effectively. > [!NOTE] > > If there's a metric definiton that is unclear, reach out to us at [people@tokenterminal.xyz](mailto:people@tokenterminal.xyz). # Projects Source: https://tokenterminal.com/docs/explorer/projects Explore all projects in a customizable data table ![Projects hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/projects.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=f086de04c923119c84c54b0a66effe41) The Projects section is the central repository for all projects listed on Token Terminal. It features a dynamic, filterable data table that supports chain, market sector, and column-specific filtering. Users can customize the table by adding or editing columns and selecting specific time ranges. Each row also links to the project’s individual data page. > [!NOTE] > > Want to see a project listed on Token Terminal? Submit information for the [app](https://tokenterminal.com/get-listed/apps) or [chain](https://tokenterminal.com/get-listed/chains). # General FAQ Source: https://tokenterminal.com/docs/faq Frequently asked questions about Token Terminal. ## What does Token Terminal do? Token Terminal is a platform that aggregates financial and alternative data on blockchains and decentralized applications that run on blockchains. We measure and evaluate the performance of blockchains and decentralized applications using traditional financial key performance indicators. ## Where does Token Terminal get data from? We run our own blockchain infrastructure for 14+ blockchains. Our research team then transforms the raw data to standardised project specific metrics. For some metrics we also rely on 3rd party APIs. The data source for each metric can be found on all dashboards. ## How often do you add new projects to the site? We add new projects on a weekly basis. All the latest projects can be found in the search bar by clicking on the "New projects" button. ## How can I add my project's data to Token Terminal? Tell us about your project on our [contact page](https://tokenterminal.com/contact?interest=listing) to kickstart the process. ## How can I schedule a demo of the platform? You can book a demo on our [contact page](https://tokenterminal.com/contact). Alternatively, you can schedule a demo by emailing us at [people@tokenterminal.xyz](mailto:people@tokenterminal.xyz). ## What payment methods do you support? We support credit card payments (Visa, MasterCard & American Express) and wire transfers. ## How do I get the invoice for my subscription? Please email us at [people@tokenterminal.xyz](mailto:people@tokenterminal.xyz) ## Is there a discounted pricing option for students to access Token Terminal? Yes, email us at [people@tokenterminal.xyz](mailto:people@tokenterminal.xyz) using your official student email, and we'll set up a student account for you. ## Where can I find my API key? You can find your API key under your account page. ## Can I download the data visible on Token Terminal? Yes, with an active Pro or API subscription you are able to download all data in CSV / Excel files. ## Why does the data reported by TT differ from other data providers? In most cases, the data differs due to the fact that we use a different methodology, track different versions, and/or chains. You can find all details regarding the chains and versions that we support on the project-specific dashboards. If you have any questions regarding the reported data, you can always message [people@tokenterminal.xyz](mailto:people@tokenterminal.xyz). # Introduction Source: https://tokenterminal.com/docs/index Token Terminal is a full stack onchain data platform focused on standardizing financial and alternative data for the most widely used blockchains and decentralized applications. Token Terminal lets you analyze both blockchains and decentralized applications using the same frameworks applied to traditional marketplace businesses. With Token Terminal, you can measure and compare the financial performance of these crypto networks using standardized key performance indicators (KPIs) from traditional finance. > **[Explore standardized onchain data](/docs/explorer)** > > Discover the financial and business performance of hundreds of projects. > **[Create your own dashboards](/docs/studio)** > > Build and share your own charts and dashboards using standardized onchain data. > **[Analyze data in your spreadsheets](/docs/sheets)** > > Analyze standardized onchain data directly in your Excel and Google Sheets. > **[Access metrics via API](/docs/api-reference)** > > Get started with querying standardized onchain data programmatically. > **[Query the full data catalog](/docs/catalog/index)** > > Query raw, decoded, and standardized datasets in your own BigQuery project with Datashare. # ChatGPT Source: https://tokenterminal.com/docs/mcp/chatgpt Set up the Token Terminal MCP server in ChatGPT There are two ways to use Token Terminal in ChatGPT: either install the Token Terminal app from the ChatGPT app directory, or add the MCP server directly as a custom connector. ## Option 1: Token Terminal app Token Terminal is available as an app in the ChatGPT app directory — no developer mode or manual connector setup required. 1. Open the [Token Terminal app on ChatGPT](https://chatgpt.com/apps/token-terminal/asdk_app_698cc05c31308191b8d5e3ff1676c76a). 2. Click "Connect" and complete the authentication flow in your browser when prompted. 3. The Token Terminal app should now be available in your ChatGPT conversations — invoke it with `@token-terminal` or via the "+" menu. > [!NOTE] > > The ChatGPT app has not yet been updated to [Token Terminal MCP 2.0](https://tokenterminal.com/resources/newsletter/introducing-token-terminal-mcp-2-0) and still runs the previous version of the server. To use the 2.0 server in ChatGPT today, add it as a custom connector (option 2 below). Learn more about apps in ChatGPT in [the OpenAI documentation](https://help.openai.com/en/articles/11487775-connectors-in-chatgpt). ## Option 2: Custom connector Adding the MCP server as a custom connector ensures you are always using the latest version of the server, including MCP 2.0. Note that custom connectors require developer mode, which is available on paid ChatGPT plans. 1. Open ChatGPT and go to Settings, then navigate to "Apps". 2. Open "Advanced settings" at the bottom of the page and toggle "Developer mode" on. 3. Back in the "Apps" settings, click "Create app". 4. Fill in the app details: * **Name**: Token Terminal MCP (use a name distinct from the Token Terminal app if you have it installed, to keep the two apart in the app picker) * **MCP server URL**: `https://mcp.tokenterminal.com/mcp` * **Authentication**: OAuth 5. Create the app and complete the authentication flow in your browser when prompted. 6. The app should now be available in your ChatGPT conversations — select "Developer mode" from the "+" menu and choose the app you created. Learn more about developer mode and MCP apps in [the OpenAI documentation](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt-beta). # Claude Code Source: https://tokenterminal.com/docs/mcp/claude-code Set up the Token Terminal MCP server in Claude Code 1. Run the following command in your terminal to add the Token Terminal MCP server: ```bash theme={null} claude mcp add --transport http tokenterminal https://mcp.tokenterminal.com/mcp ``` 2. In Claude Code, type `/mcp`, select `tokenterminal`, select auth, and complete the authentication flow in your browser. 3. The Token Terminal MCP server should now be available in your Claude Code conversations. # Claude Desktop Source: https://tokenterminal.com/docs/mcp/claude-desktop Set up the Token Terminal MCP server in Claude Desktop Token Terminal is available as a connector in the Claude directory. Connectors are shared across your Claude account, so connecting once enables Token Terminal in Claude Desktop, on [claude.ai](https://claude.ai), and in the mobile apps. Connect using either option below. Connecting does not open a chat — once you are connected, start a new conversation and ask a question. Claude reaches for Token Terminal on its own when the question needs our data. ## Try asking * Give me Hyperliquid's fees and revenue over the last 30 days * Compare Ethereum and Solana active users over the last 90 days * What are the top 5 lending projects by TVL? It works the same way for any chain, app or tokenized asset we cover — just swap the name. ## Option 1: Connect from the directory 1. Open the [Token Terminal connector in the Claude directory](https://claude.ai/directory/token-terminal). 2. Click "Connect to Claude" and complete the authentication flow in your browser when prompted. 3. Log in with the email or Google account connected to your Token Terminal account, then select the organization the session should operate under. 4. You land back on the connector page, now marked "Connected". > [!NOTE] > > On Team and Enterprise plans, connectors are managed by workspace owners. If "Connect to Claude" is unavailable, ask an owner to add Token Terminal under Organization settings, then Connectors. ## Option 2: Add as a custom connector If you prefer to add the server by URL — for example to point at it from a workspace that does not use the directory — add it as a custom connector instead. 1. Open Claude Desktop and go to Settings, then navigate to "Connectors". 2. Click "Add custom connector". 3. Fill in the connector details: * **Name**: Token Terminal * **Remote MCP server URL**: `https://mcp.tokenterminal.com/mcp` 4. Click "Add" and complete the authentication flow in your browser when prompted. Learn more about connectors in [the Anthropic documentation](https://support.claude.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp). # Codex CLI Source: https://tokenterminal.com/docs/mcp/codex Set up the Token Terminal MCP server in Codex CLI 1. Run the following command in your terminal to add the Token Terminal MCP server: ```bash theme={null} codex mcp add tokenterminal --url https://mcp.tokenterminal.com/mcp ``` 2. Open Codex and complete the authentication flow in your browser when prompted. 3. The Token Terminal MCP server should now be available in your Codex conversations. # Microsoft Copilot Studio Source: https://tokenterminal.com/docs/mcp/copilot-studio Set up the Token Terminal MCP server in Microsoft Copilot Studio 1. Open [Microsoft Copilot Studio](https://copilotstudio.microsoft.com) and create a new agent or open an existing one 2. Navigate to the **Tools** section in the left sidebar 3. Click **+ Add a tool** and select **Model Context Protocol** 4. Click **+ New tool** and select **Model Context Protocol** from the dialog 5. Configure the MCP server: * **Name**: Token Terminal * **Description**: Access Token Terminal's standardized onchain data including projects, metrics, financial statements, and market sectors * **URL**: `https://mcp.tokenterminal.com/mcp` * **Authentication**: OAuth 2.0 6. Click **Create** and then **Create a new connection** when prompted 7. The Token Terminal MCP server will open a browser tab to authenticate with Token Terminal 8. Login with your connected Token Terminal account 9. Complete the connection setup in the dialog (you may see options like **Add to agent** or **Add and configure**) 10. Publish your agent to start using the Token Terminal `research` tool in your Copilot Studio conversations Learn more about MCP integration in [the Microsoft Copilot Studio documentation](https://microsoft.github.io/copilot-camp/pages/make/copilot-studio/06-mcp/). # Cursor Source: https://tokenterminal.com/docs/mcp/cursor Set up the Token Terminal MCP server in Cursor 1. Open Cursor and go to Settings under the gear icon in the top right or in the Cursor menu item. 2. Navigate to "Tools & MCP" in the left sidebar 3. Click "Add new MCP Server" 4. Add the Token Terminal MCP server configuration to the `mcp.json` file: ```json theme={null} { "mcpServers": { "token-terminal": { "command": "npx", "args": ["-y", "mcp-remote@latest", "https://mcp.tokenterminal.com/mcp"] } } } ``` 5. Save and close the `mcp.json` file. 6. The Token Terminal MCP server will open up a new browser tab to authenticate with Token Terminal. 7. Login with your connected Token Terminal account. 8. The Token Terminal MCP server should now be available in your Cursor conversations. # Gemini CLI Source: https://tokenterminal.com/docs/mcp/gemini-cli Set up the Token Terminal MCP server in Gemini CLI 1. Run the following command in your terminal to add the Token Terminal MCP server: ```bash theme={null} gemini mcp add --transport http tokenterminal https://mcp.tokenterminal.com/mcp ``` 2. Open Gemini CLI by running `gemini`. 3. In Gemini CLI, run `/mcp auth tokenterminal` and complete the authentication flow in your browser. 4. The Token Terminal MCP server should now be available in your Gemini CLI conversations. Learn more about MCP setup in [the Gemini CLI documentation](https://geminicli.com/docs/tools/mcp-server/). # MCP Server Source: https://tokenterminal.com/docs/mcp/introduction Query Token Terminal data from any MCP-compatible AI client. The Token Terminal MCP server gives AI clients structured access to our onchain dataset — projects, products, chains, market sectors, financial metrics, and methodologies — through the [Model Context Protocol](https://modelcontextprotocol.io/). It is a centrally hosted remote server compatible with Claude, ChatGPT, Cursor, and any other MCP-compatible client. ## Availability The MCP server is available on every Token Terminal plan. The free tier includes access to the `research` tool with limited usage; paid plans raise the usage limits. For higher limits or enterprise options, contact our team at [sales@tokenterminal.xyz](mailto:sales@tokenterminal.xyz). ## Setup guides > **[Claude Code](/docs/mcp/claude-code)** > > Set up MCP in Claude Code via the CLI. > **[Claude Desktop](/docs/mcp/claude-desktop)** > > Connect Token Terminal from the Claude directory, or add it as a custom connector. > **[ChatGPT](/docs/mcp/chatgpt)** > > Install the Token Terminal app or add the MCP server as a custom connector. > **[Codex CLI](/docs/mcp/codex)** > > Set up MCP in Codex CLI. > **[Cursor](/docs/mcp/cursor)** > > Set up MCP in the Cursor IDE. > **[Gemini CLI](/docs/mcp/gemini-cli)** > > Set up MCP in Gemini CLI. > **[OpenCode](/docs/mcp/opencode)** > > Set up MCP in OpenCode. > **[Microsoft Copilot Studio](/docs/mcp/copilot-studio)** > > Set up MCP in Microsoft Copilot Studio. > **[Other clients](/docs/mcp/other-clients)** > > Use MCP with any compatible client. ## How it works The server is hosted at `https://mcp.tokenterminal.com/mcp` and implements the [authenticated remote MCP specification](https://modelcontextprotocol.io/specification) over the Streamable HTTP transport. Clients connect directly — there is no local proxy or companion process to run. Authentication is handled by **OAuth 2.1 with PKCE**, so no API keys or long-lived secrets are exchanged with your client. The first connection opens a browser window in which you sign in to Token Terminal and select the user account and organization the session will operate under. Your client stores the resulting access token and refreshes it transparently. ## Available tool The server exposes a single tool to connected clients. **research** AI-powered analyst for Token Terminal data across projects, chains, ecosystems, assets, products, metrics, methodologies, and mixed analytical questions. # OpenCode Source: https://tokenterminal.com/docs/mcp/opencode Set up the Token Terminal MCP server in OpenCode 1. Run `opencode mcp add` in your terminal and follow the prompts: * **Location**: Global * **Name**: `tokenterminal` * **Type**: Remote * **URL**: `https://mcp.tokenterminal.com/mcp` * **OAuth authentication**: Yes * **Pre-registered client ID**: No 2. Run `opencode mcp auth tokenterminal` to complete the authentication flow in your browser. 3. The Token Terminal MCP server should now be available in your OpenCode conversations. # Other clients Source: https://tokenterminal.com/docs/mcp/other-clients Use the Token Terminal MCP server with any compatible client You should be able to use the MCP server with any client that supports MCP using settings similar to those used with Claude or Cursor. The MCP server URL is: ``` https://mcp.tokenterminal.com/mcp ``` Reach out to our team at [sales@tokenterminal.xyz](mailto:sales@tokenterminal.xyz) if you have any questions about using the MCP server with your client. # Google Sheets Source: https://tokenterminal.com/docs/sheets/google-sheets Access Token Terminal's data in Google Sheets ![Google Sheets hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/sheets-marketplace.png?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=caaeaa793bc186b12379ea636cd6a05b) ## Installing Token Terminal for Sheets You can find the [Token Terminal for Sheets](https://workspace.google.com/marketplace/app/token_terminal_for_sheets/702043887467) plugin in the Google Workspace Marketplace. 1. Click the **Install** button in the upper right hand corner. 2. Choose the account where you'd like to add the plugin and follow the prompts to allow the appropriate permissions to your Google account. 3. Once installed, you can access the Token Terminal for Sheets plugin from the **Extensions** menu in Google Sheets. ## Using Token Terminal for Sheets Once the plugin is installed, you can start using Token Terminal functions in your Google Sheets. 1. Create a new spreadsheet 2. Start the plugin by navigating to **Extensions** -> **Token Terminal Sheets** -> **Open** 3. In any cell, begin using functions by typing "TT", e.g. `=TT("ethereum", "fees")` > **[Syntax Guide](/docs/sheets/syntax)** > > Check out our syntax guide for more information on how to use the TT function. ## Common issues ### Fetch limits Google limits plugin users to 20,000 data pulls per day. If you run into this limit, you will observe the following error: `Service invoked too many times for one day: urlfetch.` You can read more about this [in the Google documentation](https://developers.google.com/apps-script/guides/services/quotas). ### Sharing Sheets When sharing sheets, be advised that the URL Fetch Limit counts towards the owner of the sheet. Therefore if you share a sheet, it is recommended you share it in **View Only** mode in order to reduce data pulls counted towards yourself. ### Performance Google Sheets has a few performance limitations that ultimately reduce the quality of offering we can provide. * Only 30 functions can run simultaneously. * If more than 30 functions are requested, the remaining functions are queued and will wait until upstream functions are finished. # Introduction Source: https://tokenterminal.com/docs/sheets/index Access Token Terminal's data in Google Sheets and Microsoft Excel ![Sheets hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/sheets.png?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=0c5f80f4f301ed5ea86b91aad7eacb07) Sheets is a powerful tool for accessing and analyzing Token Terminal's data directly in spreadsheets. All data can be programmatically updated and downloaded, with historical and daily coverage for hundreds of chains and projects. Sheets is available for both [Google Sheets](https://workspace.google.com/marketplace/app/token_terminal_for_sheets/702043887467) and [Microsoft Excel](https://appsource.microsoft.com/en-us/product/office/wa200007719). # Microsoft Excel Source: https://tokenterminal.com/docs/sheets/microsoft-excel Access Token Terminal's data in Microsoft Excel ![Microsoft Excel hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/excel-sheets-marketplace.png?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=16b380795aef66bde3e1833d1ef4cf5b) ## Installing Token Terminal for Excel You can find the [Token Terminal for Excel](https://appsource.microsoft.com/en-us/product/Office365/WA200007719) plugin in the Appsource Marketplace. 1. Click the "Get it Now" button on the plugin page. 2. Login with your Microsoft 365 account 3. Open Excel 4. Start the plug-in by clicking the Token Terminal for Excel button in the Home ribbon In any cell, begin using TT functions: `=TT("ethereum", "price")` ## Using Token Terminal for Excel 1. Create or open a spreadsheet 2. Start the plug-in by clicking the Token Terminal for Excel button in the Home ribbon 3. In any cell, begin using TT functions: `=TT("ethereum", "price")` > **[Syntax Guide](/docs/sheets/syntax)** > > Check out our syntax guide for more information on how to use the TT function. # Syntax Source: https://tokenterminal.com/docs/sheets/syntax Syntax for using Token Terminal Sheets ## Types When using TT functions in Token Terminal Sheets, there are a few inputs that are important to understand: * `TICKER`: ticker, token symbol, project name, or project id. (from `=TT_PROJECTS`) * `METRIC_ID`: the `metric_id` returned from a metric row (`=TT_METRICS`) * `GRANULARITY`: `week` | `month` | `quarter` | `year` * `TIME_INTERVAL`: `7d` | `30d` | `90d` | `180d` | `365d` | `1m` | `1y` | `2y` | `3y` | `5y` | `max` > [!NOTE] > > **Single tickers and arrays**: Anywhere that you can pass a `TICKER` to a function, you can also pass an array of tickers or a range reference (i.e. `A1:A2`) that has ticker values in it. Arrays can be defined using the syntax `{'ticker_1', 'ticker_2'}` ## Functions Functions in Token Terminal Sheets allows you to easily access data from Token Terminal inside of your spreadsheet. There a few useful functions to help you retrieve a list of projects or metrics and then to retrieve specific data points for those projects and metrics. ### Get latest data for a project The simplest way to get data with Token Terminal Sheets is to use the `=TT()` function. You can pass it a ticker or array of tickers to receive the latest data point for any metric. ```javascript theme={null} =TT("TICKER", "METRIC_ID") ``` Here are a few examples to demonstrate how you can pull metrics for different projects. ```javascript theme={null} // Pull latest Circulating market cap from Aave =TT("aave", "market_cap_circulating") // Pull latest Ethereum TVL =TT("ethereum", "tvl") // Pull latest Solana daily active users count =TT("solana", "user_dau") // Pull latest Polygon revenue =TT("polygon", "revenue") ``` ### Get list of supported projects If you're not sure about what ticker you should use for a project, asset, or chain, you can use `TT_PROJECTS` to get a list of all supported projects. ```javascript theme={null} =TT_PROJECTS() ``` You can check out a list of all supported projects in our [**Projects**](https://tokenterminal.com/explorer/projects). ### Get list of supported metrics Like the projects function, `TT_METRICS` helps you know which metrics are available and how they're abbreviated with the Token Terminal API. You can use this function as a reference point for getting the correct metrics names when building out your spreadsheet models. When using this function, you will get a list of all supported metrics. ```javascript theme={null} =TT_METRICS() ``` You can check out a list of all supported metrics in our [**Metrics**](https://tokenterminal.com/explorer/metrics). ### Get a financial statement for a project Financial Statements on Token Terminal allow users to easily understand a project in a familiar format: quarterly financial statements for key metrics. You can easily generate a quarterly statement for any project inside of your sheet. ```javascript theme={null} =TT_FINANCIAL_STATEMENT("TICKER", "GRANULARITY", "TIME_INTERVAL") ``` In the following example, we'll pull a full year's financial statement broken into quarters for Ethereum. ```javascript theme={null} =TT_FINANCIAL_STATEMENT("ethereum", "quarter", "365d") ``` ### Get time series data for a project Time series allow pulling historical data for a specific project, pulling in daily metrics for the time range specified in the function. ```javascript theme={null} =TT_TIMESERIES("TICKER", "METRIC_ID", "START_TIME", "END_TIME") ``` In the following example, we'll pull the Bitcoin price from 2022-01-01 to 2022-10-01 in ascending order. ```javascript theme={null} =TT_TIMESERIES("bitcoin", "price", "2022-01-01", "2022-10-01") ``` We also allow you to pull data in descending order by adding the param `"DESC"`. ```javascript theme={null} =TT_TIMESERIES("bitcoin", "price", "2022-01-01", "2022-10-01", "DESC") ``` ### Get time series data for multiple metrics for a project Project time series allows pulling historical data for multiple metrics for a specific project, pulling in daily data for each metric for the time range specified in the function. ```javascript theme={null} =TT_TIMESERIES("bitcoin", {"price", "market_cap"}, "2022-01-01", "2022-10-01") ``` # Charts Source: https://tokenterminal.com/docs/studio/charts Create no-code custom charts with Token Terminal’s standardized data ![Studio chart hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/studio-chart.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=a8fc818d13c0b0f56e937abf85d9d180) Charts offer a no-code way to create custom charts that help you track your investing ideas or operational goals using onchain data across hundreds of chains and projects. ## Creating charts The first step in building a chart is configuring the data you want to visualize. You can use the left-hand panel to select the metric, filters, groupings, and chart type you want to use. In the chart view, you can finalize the chart by selecting the title, description, footnote, time range, and granularity of the data. ### Metric First, select one of our ** metrics**. Once you've selected a metric, the other filters will update to only show options available for that metric. For instance, if you select **Active loans**, you will only see projects associated with the Lending market sector. ### Filters Next, you can filter by one of following options: * **Project**: Any project tracked by Token Terminal. * **Market sector**: Any market sector associated with a project. * **Chain deployed on**: All apps that have deployed on the selected chain. * **Product**: Any product line of a project. ### Group by Next, you can aggregate the data by one of the following options: * **Project**: Aggregate the data by project, e.g. Aave. * **Market sector**: Aggregate the data by market sector, e.g. Lending. * **Chain**: Split the data by chain, e.g. Ethereum, Arbitrum One, Avalanche. * **Product**: Split the data by product line, e.g. Aave v2, Aave v3, and GHO. * **Project & product**: Split the data by project and product line. * **Project & chain**: Split the data by project and chain. * **Product & chain**: Split the data by product line and chain, e.g. Aave v3 on Ethereum, Aave v3 on Arbitrum One, and Aave v3 on Avalanche. ### Chart type Once you've selected your filters and aggregations, you can configure the chart to your liking: * **Bar**: A standard bar chart that shows the data for each date unit. * **Stacked bar**: A standard stacked bar chart that shows the data for each date unit, with each grouping stacked on top of each other. * **Line**: A standard line chart that shows the data for each date unit. * **Area**: A standard area chart that shows the data for each date unit. * **Stacked area**: A standard stacked area chart that shows the data for each date unit, with each grouping stacked on top of each other. * **Number**: These will change your Group by setting to "None" and will aggregate the data into a single value for the selected date range. ### Display value as You can choose how the data is displayed in the chart. Options include: * **Time series (default)** - data for each day is shown as a total value for only the date unit of that metric. * **Cumulative** - data is summed up day over day up until the latest date. * **Percent share** - data is split between groupings within the data adding up to 100% per day/week/month/quarter. ### Y-axis Choose where the axis is located and what label should be applied for the metric. ### Label Choose the label for the chart. This will be used in the legend when added to a dashboard. ### Legend Choose the colors for each of the legend items. Use our default palette, select a common brand color, or choose a custom color for each item. ### Adding multiple metrics You can add additional metrics to your charts by clicking the **Add metric** button at the bottom of the left hand panel. Each metric will be displayed on the same chart with whatever unique settings you add for that metric. ### Title & description You can add add a title and description to your chart. Both will be displayed with the data when the chart is added to a dashboard or shared with others. ### Footnote Footnotes are a great way to add additional context to your chart. You can use footnotes to explain the methodology behind the chart, provide links to sources, or add any other relevant information. ## Working with charts After you've saved the chart, you have a number of options for working with your charts. You can also find the chart in your library under the **Charts** tab. ### Share You can share your chart with others by clicking the **Share** button in the top right corner of the chart editor. This will generate a unique URL that you can share with anyone. ### Clone You can clone any Studio chart on Token Terminal, whether it's from your team or not. Clicking **Clone** will open up the chart editor with a fresh copy of the chart that you can now adapt for your own needs. ### Preview With **Preview**, you can see how your chart will look when added to a dashboard. This is a great way to check that your chart is configured correctly before adding it to a dashboard. ### Copy as image You can copy your chart as an image by clicking the **Copy as image** button in the top right corner of the chart editor. This will copy the chart to your clipboard, which you can then paste into any document or image editor. This is a great way to share your chart with others in social media or to use it in presentations. We offer three options for copying your chart as an image: * **Default**: This will copy the chart as it is displayed in the editor. * **Social media**: This will copy the chart in a format optimized for social media, with a square aspect ratio and a smaller size. * **Slide deck**: This will copy the chart in a format optimized for slide decks, with a brand colored background. ### Sheets formula You can use the **Sheets formula** button to get the equivalent data in a format that can be used in Google Sheets or Excel. This will generate a formula that you can copy and paste into your spreadsheet. ### Download as CSV You can download the data in your chart as a CSV file by clicking the **Download as CSV** button in the top right corner of the chart editor. This will download the data in a format that can be used in any spreadsheet application. # Dashboards Source: https://tokenterminal.com/docs/studio/dashboards Create custom dashboards with charts, datasets, and text to track onchain activity ![Studio dashboard hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/studio-dashboard.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=3b205997d698f1bf9ba505ec7436796e) Dashboards in Studio allow you to bring together charts, datasets, and text to create a custom dashboard that helps you track your investing ideas or operational goals using onchain data across dozens of chains and hundreds of projects. For Pro users, charts and datasets can be downloaded to use in your own local models. ## Charts Charts can be added to a dashboard either by creating a new chart in the dashboard or by reusing charts from your chart library. Charts stored in the library can be reused across multiple dashboards. ## Datasets Similarly, datasets can be added to a dashboard by creating a new dataset in the dashboard or by reusing datasets from your dataset library. Datasets are based on base datasets that are maintained by the Token Terminal team. ## Text & Headings Whether publishing for external audiences or your own team, you can use text and headings to add context and commentary about the charts and datasets in your dashboards. # Datasets Source: https://tokenterminal.com/docs/studio/datasets Create custom datasets from ready-made templates ![Studio datasets hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/studio-dataset.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=af18969942c277f5a74f903c87b0a4a5) Datasets allow you to customize any of the datasets built by Token Terminal. These datasets give you a table-first view to the data, allowing you to filter, group, and sort the data in a way that makes sense for your analysis. ## Creating datasets The first step in creating a dataset is selecting a template. You can do this by clicking the **Create new** button under the **Datasets** tab in Studio. After that you can aggregate and add or remove columns to the dataset. ### Dataset If you want to change from the dataset you chose previously, you can do it here. ### Group by Next, you can aggregate the data by one of the following options: * **Market sector**: Aggregate the data by market sector, e.g. Lending. * **Project**: Aggregate the data by project, e.g. Aave. * **Listing date**: Aggregate the data by listing date, e.g. 2023-01-01. ### Columns You can select which columns you want to include in the dataset. You can also change the order of the columns by dragging and dropping them in the list. ## Working with datasets After you've saved the dataset, you have a number of options for working with your dataset. You can also find the dataset in your library under the **Datasets** tab. ### Share You can share your dataset with others by clicking the **Share** button in the top right corner of the dataset editor. This will generate a unique URL that you can share with anyone. ### Clone You can clone any Studio dataset on Token Terminal, whether it's from your team or not. Clicking **Clone** will open up the dataset editor with a fresh copy of the dataset that you can now adapt for your own needs. ### Preview With **Preview**, you can see how your dataset will look when added to a dashboard. This is a great way to check that your dataset is configured correctly before adding it to a dashboard. # Introduction Source: https://tokenterminal.com/docs/studio/index ![Studio hero](https://mintcdn.com/tokenterminal/ePVzUc4Jyl2mhQdQ/images/Studio.jpg?fit=max\&auto=format\&n=ePVzUc4Jyl2mhQdQ\&q=85\&s=7a107e981a09eec95e814816343df7a2) Studio is a flexible workspace for creating custom, private dashboards. Users can build dashboards from scratch using charts, tables, and text boxes—no code required. All components can be downloaded as CSVs, and dashboards can be shared via private URLs with team members or the wider community. Additionally, any chart in Explorer can be forked and used as a template in Studio.