Metrics

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

Daily HyperEVM gas fees and revenue cover closed UTC days and follow HyperEVM’s availability cutoff.

A tab per grain. Coverage shows which chains report which measure.

Chain
Apps on the 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.
`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.

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
Monthly fees
Fees by project
Fee split

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.

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

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.

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

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.

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

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.

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

Overview

Popular datasets

Market verticals

Chain ecosystems

Core entities

Tables

Sample queries

​Tables

​Sample queries

Tables

Sample queries