Skip to main content
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 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, 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.
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.
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.