Skip to main content
Schema: solana.defi Table: ez_bridge_activity Type: Base Table

What

Description

This table provides a comprehensive view of cross-chain bridge activity on Solana, capturing token transfers via major protocols including Wormhole, DeBridge, and Mayan Finance. It standardizes inbound and outbound bridge transactions, includes protocol/platform identification, and enriches each event with USD pricing and token metadata where available. Each row represents a single bridge transaction, supporting analytics on cross-chain liquidity flows, protocol usage, and multi-chain DeFi activity.

Key Use Cases

  • Analyze cross-chain liquidity flows and bridge protocol adoption
  • Track token movements between Solana and other blockchains
  • Study user behavior and protocol usage patterns for bridging
  • Monitor USD-denominated bridge flows and capital movement
  • Support analytics on multi-chain DeFi ecosystem growth and integration

Important Relationships

  • Closely related to defi.fact_bridge_activity (raw bridge events), defi.ez_liquidity_pool_actions (for liquidity flows after bridging), and defi.ez_dex_swaps (for DEX activity of bridged tokens)
  • Use defi.fact_bridge_activity for protocol-level bridge event details
  • Use defi.ez_liquidity_pool_actions to analyze liquidity provision/removal after bridging
  • Use defi.ez_dex_swaps to track trading activity of tokens post-bridge
  • core.fact_transactions for transaction context

Commonly-used Fields

  • block_timestamp: For time-series and bridge flow analysis
  • platform: For protocol identification (Wormhole, DeBridge, Mayan, etc.)
  • direction: For filtering inbound vs outbound transfers
  • source_chain, destination_chain: For cross-chain analytics
  • source_address, destination_address: For user and address-level analysis
  • amount, amount_usd: For value and USD-denominated analytics
  • mint, symbol, token_is_verified: For token and asset analytics
  • succeeded: For transaction success analysis

Sample Queries

Daily bridge volume by protocol

-- Daily bridge volume by protocol
SELECT 
    DATE_TRUNC('day', block_timestamp) AS date,
    platform,
    COUNT(DISTINCT tx_id) AS bridge_txns,
    SUM(amount_usd) AS volume_usd,
    COUNT(DISTINCT source_address) AS unique_users
FROM solana.defi.ez_bridge_activity
WHERE block_timestamp >= CURRENT_DATE - 30
    AND amount_usd IS NOT NULL
    AND succeeded = true
GROUP BY 1, 2
ORDER BY 1 DESC, 4 DESC;

Top bridge routes (source to destination chains)

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

User bridge activity analysis

-- User bridge activity analysis
SELECT 
    source_address,
    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,
    COUNT(*) AS total_transfers
FROM solana.defi.ez_bridge_activity
WHERE block_timestamp >= CURRENT_DATE - 30
    AND amount_usd > 100  -- Filter small transfers
    AND succeeded = true
GROUP BY 1
HAVING COUNT(*) > 5  -- Active bridgers
ORDER BY 5 DESC
LIMIT 100;

Token flow analysis

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

Bridge protocol comparison

-- Bridge protocol comparison
WITH protocol_stats AS (
    SELECT 
        platform,
        COUNT(DISTINCT source_address) 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 solana.defi.ez_bridge_activity
    WHERE block_timestamp >= CURRENT_DATE - 30
        AND amount_usd IS NOT NULL
        AND succeeded = true
    GROUP BY 1
)
SELECT 
    platform,
    unique_users,
    total_transfers,
    avg_transfer_size,
    median_transfer_size,
    total_volume,
    total_volume * 100.0 / SUM(total_volume) OVER () AS market_share_pct
FROM protocol_stats
ORDER BY total_volume DESC;

Inbound vs Outbound flow analysis

-- Inbound vs Outbound flow analysis
SELECT 
    DATE_TRUNC('day', block_timestamp) AS date,
    direction,
    platform,
    COUNT(*) AS transfer_count,
    SUM(amount_usd) AS volume_usd,
    COUNT(DISTINCT source_address) AS unique_users
FROM solana.defi.ez_bridge_activity
WHERE block_timestamp >= CURRENT_DATE - 14
    AND amount_usd IS NOT NULL
    AND succeeded = true
GROUP BY 1, 2, 3
ORDER BY 1 DESC, 5 DESC;

Large bridge transfers monitoring (whale activity)

-- Large bridge transfers monitoring (whale activity)
SELECT 
    block_timestamp,
    tx_id,
    platform,
    direction,
    source_chain,
    destination_chain,
    source_address,
    destination_address,
    symbol,
    amount,
    amount_usd
FROM solana.defi.ez_bridge_activity
WHERE amount_usd >= 100000
    AND block_timestamp >= CURRENT_DATE - 7
    AND succeeded = true
ORDER BY amount_usd DESC;

Columns

Column NameData TypeDescription
BLOCK_TIMESTAMPTIMESTAMP_NTZThe timestamp (UTC) at which the block was produced on the Solana blockchain. This field is recorded as a TIMESTAMP data type and represents the precise moment the block was finalized and added to the chain. It is essential for time-series analysis, block production monitoring, and aligning transaction and event data to specific points in time. Used extensively for analytics involving block intervals, network activity trends, and historical lookups. Format: YYYY-MM-DD HH:MI:SS (UTC).
BLOCK_IDNUMBERA unique identifier for the block in which this transaction was included on the Solana blockchain. Typically a sequential integer or hash, depending on the data source. Used to group transactions by block and analyze block-level activity. Example: 123456789 Business Context: Supports block-level analytics, such as block production rate and transaction throughput. Useful for tracing transaction inclusion and block explorer integrations. Relationships: All transactions with the same ‘blockid’ s…
TX_IDTEXTThe unique transaction signature (hash) for each transaction on the Solana blockchain. This field is a base58-encoded string, typically 88 characters in length, and serves as the primary identifier for transactions across all Solana data models. Used to join transaction data with related tables (blocks, events, transfers, logs, decoded instructions) and to trace the full lifecycle and effects of a transaction. Essential for transaction-level analytics, debugging, and cross-referencing with bl…
SUCCEEDEDBOOLEANBoolean flag indicating whether the transaction was successfully executed and confirmed on the Solana blockchain. A value of TRUE means the transaction was processed without errors; FALSE indicates failure due to program errors, insufficient funds, or other issues. Example: true false Business Context: Used to filter for successful transactions in analytics and reporting. Important for error analysis, user experience, and program debugging.
INDEXNUMBERINDEX column
PROGRAM_IDTEXTThe unique public key (base58-encoded address) of a Solana program. This field identifies the on-chain program (smart contract) responsible for processing instructions, emitting events, or managing accounts. Used throughout Solana analytics models—including events, transactions, IDLs, and program activity tables—to join, filter, and analyze program-level data. Example: “4Nd1mY…” “TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA” Business Context: Used as a join key for program activity, deployme…
PLATFORMTEXTThe platform or protocol from which the bridge transaction or event originates.
DIRECTIONTEXTIndicates the direction in which the assets are being bridged, either inbound to Solana or outbound from Solana.
SOURCE_CHAINTEXTThe name of the blockchain network to which the assets are being bridged from.
DESTINATION_CHAINTEXTThe name of the blockchain network to which the assets are being bridged to.
SOURCE_ADDRESSTEXTThe address that initiated the bridge deposit or transfer. This address is the sender of the tokens/assets being bridged to the destination chain.
DESTINATION_ADDRESSTEXTThe designated address set to receive the bridged tokens on the target chain after the completion of the bridge transaction.
AMOUNTFLOATThe decimal adjusted amount of tokens involved in the bridge transaction, where available.
AMOUNT_USDFLOATThe value of the bridged tokens in USD at the time of the bridge transaction, where available.
MINTTEXTThe address associated with the token that is being bridged. It provides a unique identifier for the token within Solana.
SYMBOLTEXTThe symbol representing the token being bridged. This provides a shorthand representation of the token.
TOKEN_IS_VERIFIEDBOOLEANA flag indicating if the asset has been verified by the Flipside team.
EZ_BRIDGE_ACTIVITY_IDTEXTA unique, stable identifier for each record in this table. The primary key (PK) ensures that every row is uniquely identifiable and supports efficient joins, lookups, and data integrity across models. The PK may be a natural key (such as a blockchain transaction hash) or a surrogate key generated from one or more fields, depending on the table’s structure and requirements.
INSERTED_TIMESTAMPTIMESTAMP_NTZThe timestamp when this transaction record was first inserted into the analytics database. Used for data freshness tracking and incremental model logic. Format: YYYY-MM-DD HH:MI:SS. Not derived from the blockchain, but from the ETL process.
MODIFIED_TIMESTAMPTIMESTAMP_NTZThe timestamp when this transaction record was last updated in the analytics database. Used for tracking updates and supporting incremental model logic. Format: YYYY-MM-DD HH:MI:SS. Not derived from the blockchain, but from the ETL process.