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_transfers pairs those two events into one row. The table has no single chain_id column, because one transfer belongs to two chains: 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 column is documented at Bridges โ–ธ Transfers, including how an unmatched leg is recorded.

Sample queries

The table splits by day on block_timestamp. Bound that column in every query; without a bound the query reads the whole table.
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.

Notes

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. Every row holds a full pair of columns for each side: chain, transaction hash, block, sender, recipient, token address and amount, prefixed source_ or destination_. Some rows have only one leg: a transfer whose other side was never found still appears, carrying the leg it has, with unmatched_reason saying why the other is missing. Counting only matched pairs means requiring both chain columns to be present. For daily totals, metrics.bridge_tokens_daily carries the answer per token at a fraction of the cost.