Skip to main content
Schema: somnia.defi Table: ez_bridge_activity Type: View

What

This table provides a comprehensive view of cross-chain bridge activity across EVM-compatible blockchains. It consolidates bridge-related events from multiple sources (event_logs, traces, and transfers) to create a unified dataset for analyzing cross-chain asset movements.

Key Use Cases

  • Tracking cross-chain asset flows and bridge volumes
  • Analyzing user bridging behavior and patterns
  • Comparing bridge protocol market share and performance
  • Monitoring token distribution across multiple chains
  • Identifying popular bridge routes and corridors

Important Relationships

  • Join with core.fact_event_logs: Use tx_hash for raw event details
  • Join with core.dim_contracts: Use bridge_address or token_address for contract metadata
  • Join with price.ez_prices_hourly: For additional price validation
  • Join with core.dim_labels: Use sender addresses for entity identification

Commonly-used Fields

  • platform: Bridge protocol name
  • sender: Address sending tokens to bridge
  • destination_chain: Target blockchain for assets
  • token_address: Token being bridged
  • amount: Decimal-adjusted token amount
  • amount_usd: USD value at transaction time
  • block_timestamp: When bridge transaction occurred

Sample queries

-- Daily bridge volume by protocol
SELECT 
    DATE_TRUNC('day', block_timestamp) AS date,
    platform,
    COUNT(DISTINCT tx_hash) AS bridge_txns,
    SUM(amount_usd) AS volume_usd
FROM <blockchain_name>.defi.ez_bridge_activity
WHERE block_timestamp >= CURRENT_DATE - 30
    AND amount_usd IS NOT NULL
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC;

-- Top bridge routes (source to destination chains)
SELECT 
    blockchain AS source_chain,
    destination_chain,
    platform,
    COUNT(*) AS transfer_count,
    SUM(amount_usd) AS total_volume_usd
FROM <blockchain_name>.defi.ez_bridge_activity
WHERE block_timestamp >= CURRENT_DATE - 7
    AND destination_chain IS NOT NULL
GROUP BY 1, 2, 3
ORDER BY 5 DESC
LIMIT 20;

-- User bridge activity analysis
SELECT 
    sender,
    COUNT(DISTINCT DATE_TRUNC('day', block_timestamp)) AS active_days,
    COUNT(DISTINCT platform) AS protocols_used,
    COUNT(DISTINCT destination_chain) AS chains_bridged_to,
    SUM(amount_usd) AS total_bridged_usd
FROM <blockchain_name>.defi.ez_bridge_activity
WHERE block_timestamp >= CURRENT_DATE - 30
    AND amount_usd > 100  -- Filter small transfers
GROUP BY 1
HAVING COUNT(*) > 5  -- Active bridgers
ORDER BY 5 DESC
LIMIT 100;

-- Token flow analysis
SELECT 
    token_symbol,
    token_address,
    blockchain AS source_chain,
    destination_chain,
    COUNT(*) AS bridge_count,
    SUM(amount) AS total_amount,
    AVG(amount_usd) AS avg_transfer_usd
FROM <blockchain_name>.defi.ez_bridge_activity
WHERE block_timestamp >= CURRENT_DATE - 7
    AND token_symbol IS NOT NULL
GROUP BY 1, 2, 3, 4
HAVING COUNT(*) > 10
ORDER BY 5 DESC;

-- Bridge protocol comparison
WITH protocol_stats AS (
    SELECT 
        platform,
        COUNT(DISTINCT sender) AS unique_users,
        COUNT(*) AS total_transfers,
        AVG(amount_usd) AS avg_transfer_size,
        PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY amount_usd) AS median_transfer_size,
        SUM(amount_usd) AS total_volume
    FROM <blockchain_name>.defi.ez_bridge_activity
    WHERE block_timestamp >= CURRENT_DATE - 30
        AND amount_usd IS NOT NULL
    GROUP BY 1
)
SELECT *
FROM protocol_stats
ORDER BY total_volume DESC;

Columns

Column NameData TypeDescription
BLOCK_NUMBERNUMBERSequential counter representing the position of a block in the blockchain since genesis (block 0). Key Facts: Immutable once finalized Primary ordering mechanism for blockchain data Increments by 1 for each new block Used as a proxy for time in many analyses Usage in Queries: Important: Block numbers are chain-specific. Block 15000000 on Ethereum ≠ block 15000000 on Polygon.
BLOCK_TIMESTAMPTIMESTAMP_NTZUTC timestamp when the block was produced by validators/miners. Format: TIMESTAMP_NTZ (no timezone) Precision: Second-level accuracy Reliability: Set by block producer Can have minor variations (±15 seconds) Always increasing (newer blocks = later timestamps) Best Practices: Note: Use for time-series analysis, but be aware that block production rates vary by chain.
ORIGIN_FROM_ADDRESSTEXTThe externally-owned account (EOA) or contract address that initiated the transaction. Key Points: Always 42 characters (0x + 40 hex chars) Lowercase normalized in all tables Cannot be NULL for valid transactions For contract creation: sender of creation transaction Common Patterns: EOA → EOA: Simple transfer EOA → Contract: User interaction Contract → Contract: Internal calls (see fact_traces) Known addresses: Exchange hot wallets, protocol deployers Query Examples:
ORIGIN_TO_ADDRESSTEXTThe destination address for the transaction - either an EOA or contract address. Special Cases: NULL: Contract creation transaction Contract address: Interacting with smart contract EOA address: Simple transfer or receiving funds Important Patterns: Note: For token transfers, this is the token contract, not the recipient. See eztokentransfers tables for recipient.
ORIGIN_FUNCTION_SIGNATURETEXTFunction signature (first 4 bytes) of the called method. Format: 0x + 8 hex characters Common Signatures: 0xa9059cbb: transfer(address,uint256) 0x095ea7b3: approve(address,uint256) 0x23b872dd: transferFrom(address,address,uint256) Note: NULL for simple transfers or invalid calls
TX_HASHTEXTUnique 66-character identifier for the transaction. Format: 0x + 64 hexadecimal characters Usage: Primary key for transaction lookups Join key for traces, logs, and token transfers Immutable once confirmed Example: 0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060
EVENT_INDEXNUMBERZero-based sequential position of the event within a transaction’s execution. Key Facts: Starts at 0 for first event Increments across all contracts in transaction Preserves execution order Essential for deterministic event ordering Usage Example:
BRIDGE_ADDRESSTEXTThe smart contract address handling the bridge operation. Example: ‘0x296f55f8fb28e498b858d0bcda06d955b2cb3f97’
EVENT_NAMETEXTThe event name as defined in the contract’s ABI. Format: PascalCase event identifier Examples: Transfer - Token transfers Swap - DEX trades OwnershipTransferred - Admin changes Approval - Token approvals Usage Pattern:
PLATFORMTEXTThe protocol or application facilitating the cross-chain bridge transfer. Example: ‘stargate’
PROTOCOLTEXTPROTOCOL column
PROTOCOL_VERSIONTEXTPROTOCOL_VERSION column
SENDERTEXTThe address that directly sent tokens to the bridge contract. Example: ‘0xabcdefabcdefabcdefabcdefabcdefabcdefabcd’
RECEIVERTEXTThe address designated to receive tokens on the destination chain (or on the source chain, for intermediate steps). Example: ‘0x9876543210987654321098765432109876543210’
DESTINATION_CHAIN_RECEIVERTEXTThe final recipient address on the destination blockchain. Example: ‘0xfedcbafedcbafedcbafedcbafedcbafedcbafed’
DESTINATION_CHAINTEXTThe target blockchain network for the bridged assets. Example: ‘arbitrum’
DESTINATION_CHAIN_IDTEXTThe numeric identifier for the destination blockchain. Example: 42161
TOKEN_ADDRESSTEXTThe contract address of the token being bridged. Example: ‘0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48’
TOKEN_SYMBOLTEXTThe symbol identifier for the bridged token. Example: ‘USDC’
AMOUNT_UNADJFLOATThe raw token amount without decimal adjustment. Example: 1000000
AMOUNTFLOATThe decimal-adjusted amount of tokens bridged. Example: 1.0
AMOUNT_USDFLOATThe hourly close USD value of bridged tokens at the time of the transaction. Example: 1000.50
TOKEN_IS_VERIFIEDBOOLEANWhether the token is verified by the Flipside team. Example: true
EZ_BRIDGE_ACTIVITY_IDTEXTPrimary key - unique identifier for each row ensuring data integrity. Format: Usually VARCHAR containing composite key generated using MD5 hash of the relevant columns. Example: MD5(blocknumber, txhash, trace_index) Usage: Deduplication in incremental loads Join operations for data quality checks Troubleshooting specific records Important: Implementation varies by table - check table-specific documentation.
INSERTED_TIMESTAMPTIMESTAMP_NTZUTC timestamp when the record was first added to the Flipside database. Format: TIMESTAMP_NTZ Use Cases: Data freshness monitoring Incremental processing markers Debugging data pipeline issues SLA tracking Query Example:
MODIFIED_TIMESTAMPTIMESTAMP_NTZUTC timestamp of the most recent update to this record. Format: TIMESTAMP_NTZ Triggers for Updates: Data corrections Enrichment additions Reprocessing for accuracy Schema migrations Monitoring Usage: