Transfers

One cross-chain transfer, one row. Sending a token from one chain to another leaves an event on the chain it departs from and another on the chain it arrives at, and facts.bridge_transfers pairs those two sides into that single row. Each side is called a leg. Where only one leg turns up, the row carries the leg it has and says why the other is missing. The table puts LayerZero v1 and v2, Circle CCTP v1 and v2, and Chainlink CCIP onto the same columns, matching each bridge’s legs on identifiers of its own, with token amounts and USD values worked out once before publication. A row is keyed on the onchain identity of whichever leg it is anchored on: the source leg for a matched pair or a departure with no arrival, the destination leg for an arrival with no departure.

Columns

Column	Type	Description
`block_timestamp`	`TIMESTAMP`	The column the table is partitioned on: the sending leg’s time, or the arriving leg’s where there is no sending leg.
`project_id`	`STRING`	Project operating the bridge.
`product_id`	`STRING`	Version of the bridge within that project.
`app_id`	`STRING`	Bridge app: `layerzero-v1`, `layerzero-v2`, `circle-cctp-v1`, `circle-cctp-v2` or `chainlink-ccip`.
`match_key`	`STRING`	The identifier the two legs were paired on, provided by the bridge.
`match_method`	`STRING`	`exact` on matched rows, empty otherwise.
`latency_seconds`	`INT64`	How long the transfer took, in seconds. Empty on unmatched rows.
`unmatched_reason`	`STRING`	Why the other leg was not found. Empty on matched rows.
`intermediary_address`	`STRING`	Address of the relayer that carried the message. Empty on every row.
`source_chain_id`	`STRING`	Chain the transfer left. Empty where no sending leg was found.
`source_transaction_hash`	`STRING`	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, within a sending event that moved more than one. Zero everywhere except CCIP sending legs.
`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`	Who the sending leg says should receive it.
`source_token_address`	`STRING`	Token contract on the chain it left.
`source_token_id`	`STRING`	That token’s key in `dimensions.tokens`. Empty where we do not carry the token.
`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. Empty where no arrival was found.
`destination_transaction_hash`	`STRING`	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 it arrived on.
`destination_token_id`	`STRING`	That token’s key in `dimensions.tokens`. Empty where we do not carry the token.
`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.
`destination_transfer_amount`	`FLOAT64`	Amount arriving, in whole token units, with the fallback described above.
`destination_transfer_amount_usd`	`FLOAT64`	Amount arriving, in USD, with the same fallback.
`transfer_amount`	`FLOAT64`	The transfer counted once, in whole token units: the sending side’s amount, or the arriving side’s where there is no sending leg.
`transfer_amount_usd`	`FLOAT64`	The transfer counted once, in USD. Total volume by summing this column, never by adding the two directional columns.

Sample queries

The table is partitioned on block_timestamp. Put a filter on that column in every query. Leave it out and the query reads every day we hold.

Daily volume by app
Routes by volume
Unmatched breakdown

Total daily bridged USD volume per app, counting each transfer once. transfer_amount_usd takes the sending side’s value, or the arriving side’s where there is no sending leg, so every transfer contributes exactly once.

select
    timestamp_trunc(block_timestamp, day) as day,
    app_id,
    sum(transfer_amount_usd) as volume_usd,
    count(*) as transfers
from `facts.bridge_transfers`
where block_timestamp >= timestamp('2026-08-01')
group by day, app_id
order by day, volume_usd desc

Rank routes by volume over one week. Filtering on unmatched_reason is null keeps matched pairs, where both chains are known.

select
    source_chain_id,
    destination_chain_id,
    sum(transfer_amount_usd) as volume_usd,
    count(*) as transfers
from `facts.bridge_transfers`
where block_timestamp >= timestamp('2026-08-01')
  and block_timestamp < timestamp('2026-08-08')
  and unmatched_reason is null
group by source_chain_id, destination_chain_id
order by volume_usd desc
limit 20

Break the unmatched rows down by what went wrong.

select
    app_id,
    unmatched_reason,
    count(*) as legs
from `facts.bridge_transfers`
where block_timestamp >= timestamp('2026-08-01')
  and unmatched_reason is not null
group by app_id, unmatched_reason
order by legs desc

Notes

Every transfer has a sending side and an arriving side, and this table values both. source_transfer_amount_usd is the money leaving. destination_transfer_amount_usd is that same money arriving. Add the two columns together and you have counted the same money twice. To total volume, use transfer_amount_usd, or transfer_amount for token units. Each takes the sending side’s value, falling back to the arriving side’s where there is no sending leg, so a transfer counts exactly once however many legs were found. Use the two directional columns only when you want to credit volume to the chain it left or the chain it reached. destination_transfer_amount and destination_transfer_amount_usd describe the money arriving. Each carries the arriving leg’s own amount where the event states one. Some bridges do not state it, CCIP’s arrival event among them, so where the row is matched but the arriving event names no amount, these columns fall back to the sending side’s value. Where no arriving leg was found at all, both stay empty. The legs are paired on match_key, an identifier each bridge provides of its own, such as LayerZero’s GUID or CCIP’s message id, with the arriving leg required to fall within a window around the sending leg’s time. match_method reads exact on a matched row and is empty otherwise. latency_seconds is how long the transfer took: the arriving block’s time minus the sending block’s. block_timestamp, the column the table is partitioned on, is the sending leg’s time, or the arriving leg’s where there is no sending leg. unmatched_reason is empty on a matched row and says what went wrong on every other one. A row with a sending leg but no arrival reads source_key_missing, destination_chain_not_indexed, destination_leg_not_decoded or destination_pending_or_failed. A row with an arrival but no sending leg has the mirror image: destination_key_missing, source_chain_not_indexed, source_leg_not_decoded or source_leg_missing.

Overview

Core entities

Market verticals

Chain verticals

Columns

Sample queries

Notes

​Columns

​Sample queries

​Notes

Columns

Sample queries

Notes