Metrics

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

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 shows which apps report which measure.

Project
Project × chain
App
App × chain
Bridge token

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.

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_project_chains.transfer_volume_daily`	`transfer_volume`	USD value of assets moved through the project’s bridge transfers, counted once per transfer.
`metrics_project_chains.source_transfer_volume_daily`	`source_transfer_volume`	USD value sent out through the project’s bridge transfers, measured on the source chain leg.
`metrics_project_chains.destination_transfer_volume_daily`	`destination_transfer_volume`	USD value received through the project’s bridge transfers, measured on the destination chain leg.
`metrics_project_chains.fees_daily`	`fees`	Total fees paid by users.
`metrics_project_chains.revenue_daily`	`revenue`	Fees retained by the protocol.

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.

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_app_chains.source_transfer_volume_daily`	`source_transfer_volume`	USD value sent out through the app’s bridge transfers, measured on the source chain leg.
`metrics_app_chains.destination_transfer_volume_daily`	`destination_transfer_volume`	USD value received through the app’s bridge transfers, measured on the destination chain leg.

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.source_transfer_volume_daily`	`source_transfer_volume`	USD value of the token sent out through a bridge, measured on the source chain leg.
`metrics_bridge_tokens.destination_transfer_volume_daily`	`destination_transfer_volume`	USD value of the token received through a bridge, measured on the destination chain leg.

Sample queries

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.

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

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.

with counted_once as (
    select timestamp, chain_id, transfer_volume
    from `metrics_project_chains.transfer_volume_daily`
    where project_id = 'layerzero'
      and timestamp >= timestamp('2026-08-01')
),

leaving as (
    select timestamp, chain_id, source_transfer_volume
    from `metrics_project_chains.source_transfer_volume_daily`
    where project_id = 'layerzero'
      and timestamp >= timestamp('2026-08-01')
),

arriving as (
    select timestamp, chain_id, destination_transfer_volume
    from `metrics_project_chains.destination_transfer_volume_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.source_transfer_volume,
    arriving.destination_transfer_volume
from counted_once
full join leaving
    using (timestamp, chain_id)
full join arriving
    using (timestamp, chain_id)
order by timestamp, chain_id

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.

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

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 source_transfer_volume when it is where value leaves from, and high on destination_transfer_volume when it is where value lands.

with leaving as (
    select timestamp, chain_id, source_transfer_volume
    from `metrics_app_chains.source_transfer_volume_daily`
    where app_id = 'layerzero-v2'
      and timestamp >= timestamp('2026-08-01')
),

arriving as (
    select timestamp, chain_id, destination_transfer_volume
    from `metrics_app_chains.destination_transfer_volume_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.source_transfer_volume,
    arriving.destination_transfer_volume
from leaving
full join arriving
    using (timestamp, chain_id)
order by timestamp, chain_id

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.

with leaving as (
    select timestamp, source_transfer_volume
    from `metrics_bridge_tokens.source_transfer_volume_daily`
    where token_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum'
      and timestamp >= timestamp('2026-08-01')
),

arriving as (
    select timestamp, destination_transfer_volume
    from `metrics_bridge_tokens.destination_transfer_volume_daily`
    where token_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum'
      and timestamp >= timestamp('2026-08-01')
)

select
    coalesce(leaving.timestamp, arriving.timestamp) as timestamp,
    leaving.source_transfer_volume,
    arriving.destination_transfer_volume
from leaving
full join arriving
    using (timestamp)
order by timestamp

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.

select
    daily.token_id,
    tokens.symbol,
    sum(daily.source_transfer_volume) as source_transfer_volume
from `metrics_bridge_tokens.source_transfer_volume_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 source_transfer_volume desc
limit 25

Overview

Popular datasets

Market verticals

Chain ecosystems

Core entities

Tables

Sample queries

​Tables

​Sample queries

Tables

Sample queries