Bridge Analysis

Bridge transfer tables are asymmetric by design — they don't always record both legs of a transfer. Get the directionality model right before summing anything.

Bridge transfer tables record net single-directional flows, not always both legs

The exact coverage shape depends on the bridge type:

• Canonical bridges on Ethereum typically carry both inbound and outbound rows.
• Application-level bridges, and bridge activity on non-Ethereum chains, typically carry only the outbound leg from the chain that initiated the transfer.

This is a deliberate anti-double-counting design, not a coverage gap — but it means SUM(usd_amount) behaves differently depending on which chain/bridge-type combination you're querying. Check what direction values actually exist for the specific bridge/chain before summing across them, rather than assuming every transfer has a matching inbound+outbound pair somewhere in the table.

Filtering to ≥2 target chains creates a double-counting trap a single-chain filter doesn't have