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

​
Description

This table contains bridging actions across major cross-chain protocols including Wormhole, DeBridge, and Mayan Finance. It tracks token transfers between Solana and other blockchains, capturing both inbound (to Solana) and outbound (from Solana) bridge activity. Each row represents a single bridge transaction, supporting analytics on cross-chain liquidity flows, bridge 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 bridge protocol usage patterns and user behavior
  • Monitor cross-chain DeFi activity and capital flows
  • Support analytics on multi-chain ecosystem growth and integration

​
Important Relationships

  • Closely related to defi.ez_bridge_activity (preferred for most analytics), defi.ez_liquidity_pool_actions (for liquidity flows), and defi.ez_dex_swaps (for DEX activity)
  • Use defi.ez_bridge_activity for enhanced bridge analytics with USD pricing and token metadata
  • Use defi.ez_liquidity_pool_actions to analyze liquidity provision after bridging
  • Use defi.ez_dex_swaps to track trading activity of bridged tokens
  • Joins with core.fact_blocks for block context and core.fact_transactions for transaction context

​
Commonly-used Fields

  • block_timestamp: For time-series and bridge flow analysis
  • direction: For filtering inbound vs outbound transfers
  • platform: For protocol-specific analysis
  • user_address, amount, mint: For user and token analytics
  • succeeded: For transaction success analysis

​
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 ‘block_id’ share the same ‘block_timestamp’. | | TX_ID | TEXT | The 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 block explorers or Solana APIs.
Example:
  • 5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw
Business Context:
  • Enables precise tracking, auditing, and attribution of on-chain activity
  • Used for linking transactions to events, logs, and protocol actions
  • Critical for compliance, monitoring, and analytics workflows | | SUCCEEDED | BOOLEAN | Boolean 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. | | INDEX | NUMBER | | | PROGRAM_ID | TEXT | The 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, deployments, events, and interface changes.
  • Supports segmentation of activity by protocol, DEX, NFT marketplace, or other on-chain application. | | PLATFORM | TEXT | The platform or protocol from which the bridge transaction or event originates. | | DIRECTION | TEXT | Indicates the direction in which the assets are being bridged, either inbound to Solana or outbound from Solana. | | USER_ADDRESS | TEXT | The Solana address that is receiving or sending bridged tokens. This field identifies the user involved in the cross-chain transfer.
  • Data type: STRING (base58 Solana address)
  • Business context: Used to track user bridge activity, analyze bridge user behavior, and identify bridge power users.
  • Analytics use cases: User bridge activity analysis, whale tracking, and bridge adoption studies.
  • Example: ‘4Nd1mYw4r…’ | | AMOUNT | FLOAT | The amount of the asset transferred in the event. For native SOL, this is decimal adjusted and is not in Lamports. For SPL tokens, this is decimal adjusted according to the token’s mint. Represents the value moved from sender to recipient in a single transfer event.
Data type: Numeric (integer for lamports, decimal for tokens) Example:
  • USDC: 50.00 (represents 50 USDC tokens)
Business Context:
  • Used to analyze transaction volumes, user activity, and protocol flows.
  • Supports aggregation of asset movement for analytics and reporting. | | MINT | TEXT | Unique address representing a specific token | | FACT_BRIDGE_ACTIVITY_ID | TEXT | A 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_TIMESTAMP | TIMESTAMP_NTZ | The 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_TIMESTAMP | TIMESTAMP_NTZ | The 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. |