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

​
Description

This table captures liquidity pool actions (deposits and withdrawals) across major Solana DeFi protocols including Raydium, Orca, and Meteora. It provides a unified view of liquidity provision and removal events with USD pricing, token verification status, and platform identification. Each row represents a single liquidity pool action, supporting analytics on DeFi protocol usage, liquidity provision patterns, and yield farming activities.

​
Key Use Cases

  • Analyze liquidity provision and removal patterns across DeFi protocols
  • Track yield farming activities and liquidity mining incentives
  • Study protocol adoption and user behavior in liquidity pools
  • Monitor USD-denominated liquidity flows and TVL changes
  • Support analytics on DeFi protocol performance and user engagement

​
Important Relationships

  • Closely related to defi.fact_swaps (for swap activity), defi.ez_dex_swaps (for DEX activity), and defi.fact_bridge_activity (for cross-chain flows)
  • Use defi.fact_swaps and defi.ez_dex_swaps to analyze trading activity in liquidity pools
  • Use defi.fact_bridge_activity to understand cross-chain liquidity flows
  • Joins with core.fact_blocks for block context and core.fact_transactions for transaction context

​
Commonly-used Fields

  • block_timestamp: For time-series and liquidity flow analysis
  • action_type: For filtering deposits vs withdrawals
  • provider_address, pool_address: For user and pool identification
  • token_a_mint, token_b_mint, token_a_amount_usd, token_b_amount_usd: For token and value analytics
  • platform: For protocol-specific analysis

​
Columns

Column NameData TypeDescription
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’. | | BLOCK_TIMESTAMP | TIMESTAMP_NTZ | The 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). | | 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 | | INDEX | NUMBER | The position of the event (instruction) within the list of instructions for a given Solana transaction. Used to order and reference events within a transaction. Indexing starts at 0 for the first event.
Example:
  • 0
  • 3
Business Context:
  • Enables precise identification and ordering of events within a transaction, which is critical for reconstructing transaction flows and analyzing protocol behavior.
  • Used to join or filter event-level data, especially when multiple events occur in a single transaction. | | INNER_INDEX | NUMBER | The position of the inner instruction or event within the list of inner instructions for a given Solana transaction. Used to order and reference nested (CPI) instructions. Indexing starts at 0 for the first inner instruction.
Example:
  • 0
  • 2
Business Context:
  • Enables precise identification and ordering of nested program calls (Cross-Program Invocations) within a transaction.
  • Critical for analyzing composability, protocol integrations, and the full execution path of complex transactions. | | ACTION_TYPE | TEXT | A string categorizing the type of event or instruction, such as ‘transfer’, ‘mint’, ‘burn’, or protocol-specific actions.
Example:
  • ‘transfer’
  • ‘mint’
  • ‘burn’
Business Context:
  • Enables segmentation and filtering of on-chain activity for analytics and dashboards.
  • Used to group and analyze protocol-specific actions and user behaviors.
Relationships:
  • May be derived from decoded instruction data or protocol-specific logic. | | PROVIDER_ADDRESS | TEXT | The address of the liquidity provider who is performing the deposit or withdrawal action. This field identifies the user providing or removing liquidity from the pool.
  • Data type: STRING (base58 Solana address)
  • Business context: Used to track liquidity providers, analyze provider behavior, and identify active liquidity participants.
  • Analytics use cases: Liquidity provider analysis, provider behavior studies, and liquidity provision tracking.
  • Example: ‘4Nd1mYw4r…’ | | TOKEN_A_MINT | TEXT | Address of the mint representing the first token in a liquidity pool pair | | TOKEN_A_SYMBOL | TEXT | The symbol of the token involved in the action (e.g., SOL, USDC, RAY). Used to identify the asset type in analytics and reporting.
Data type: String Example:
  • SOL
  • USDC
Business Context:
  • Enables grouping and filtering of transfers by token.
  • Supports analytics on asset flows, protocol usage, and user preferences. | | TOKEN_A_AMOUNT | FLOAT | Amount of the first token in a liquidity pool pair transferred during a liquidity pool action | | TOKEN_A_AMOUNT_USD | NUMBER | The USD value of token A involved in the liquidity pool action, calculated using the token’s price at the time of the action.
  • Data type: NUMBER (float, USD value)
  • Business context: Used to calculate USD-denominated liquidity flows and measure the economic impact of liquidity actions.
  • Analytics use cases: USD liquidity flow analysis, economic impact measurement, and value-based liquidity studies.
  • Example: 150.25 | | TOKEN_B_MINT | TEXT | Address of the mint representing the second token in a liquidity pool pair | | TOKEN_B_SYMBOL | TEXT | The symbol of the token involved in the action (e.g., SOL, USDC, RAY). Used to identify the asset type in analytics and reporting.
Data type: String Example:
  • SOL
  • USDC
Business Context:
  • Enables grouping and filtering of transfers by token.
  • Supports analytics on asset flows, protocol usage, and user preferences. | | TOKEN_B_AMOUNT | FLOAT | Amount of the second token in a liquidity pool pair transferred during a liquidity pool action | | TOKEN_B_AMOUNT_USD | NUMBER | The USD value of token B involved in the liquidity pool action, calculated using the token’s price at the time of the action.
  • Data type: NUMBER (float, USD value)
  • Business context: Used to calculate USD-denominated liquidity flows and measure the economic impact of liquidity actions.
  • Analytics use cases: USD liquidity flow analysis, economic impact measurement, and value-based liquidity studies.
  • Example: 75.50 | | TOKEN_C_MINT | TEXT | The mint address of the third token in a liquidity pool pair. This field identifies the third token involved in multi-token liquidity pool actions.
  • Data type: STRING (base58 Solana mint address)
  • Business context: Used to identify the third token in multi-token pools, analyze token-specific liquidity flows, and track multi-token pool activity.
  • Analytics use cases: Multi-token pool analysis, token-specific liquidity tracking, and cross-token liquidity studies.
  • Example: ‘So11111111111111111111111111111111111111112’ | | TOKEN_C_SYMBOL | TEXT | The symbol of the token involved in the action (e.g., SOL, USDC, RAY). Used to identify the asset type in analytics and reporting.
Data type: String Example:
  • SOL
  • USDC
Business Context:
  • Enables grouping and filtering of transfers by token.
  • Supports analytics on asset flows, protocol usage, and user preferences. | | TOKEN_C_AMOUNT | FLOAT | The amount of the third token involved in the liquidity pool action, already decimal adjusted according to the token’s standard decimals.
  • Data type: NUMBER (float or integer, depending on token)
  • Business context: Used to track the third token’s liquidity flows, analyze multi-token pool activity, and measure token-specific liquidity provision.
  • Analytics use cases: Multi-token liquidity analysis, token-specific flow tracking, and cross-token liquidity studies.
  • Example: For SOL, a value of 5.0 means 5 SOL. | | TOKEN_C_AMOUNT_USD | NUMBER | The USD value of token C involved in the liquidity pool action, calculated using the token’s price at the time of the action. This field is used for pools with more than two tokens.
  • Data type: NUMBER (float, USD value)
  • Business context: Used to calculate USD-denominated liquidity flows for multi-token pools and measure the economic impact of liquidity actions.
  • Analytics use cases: USD liquidity flow analysis for multi-token pools, economic impact measurement, and value-based liquidity studies.
  • Example: 25.75 | | TOKEN_D_MINT | TEXT | The mint address of the fourth token in a liquidity pool pair. This field identifies the fourth token involved in four-token liquidity pool actions.
  • Data type: STRING (base58 Solana mint address)
  • Business context: Used to identify the fourth token in four-token pools, analyze token-specific liquidity flows, and track four-token pool activity.
  • Analytics use cases: Four-token pool analysis, token-specific liquidity tracking, and cross-token liquidity studies.
  • Example: ‘So11111111111111111111111111111111111111112’ | | TOKEN_D_SYMBOL | TEXT | The symbol of the token involved in the action (e.g., SOL, USDC, RAY). Used to identify the asset type in analytics and reporting.
Data type: String Example:
  • SOL
  • USDC
Business Context:
  • Enables grouping and filtering of transfers by token.
  • Supports analytics on asset flows, protocol usage, and user preferences. | | TOKEN_D_AMOUNT | FLOAT | The amount of the fourth token involved in the liquidity pool action, already decimal adjusted according to the token’s standard decimals.
  • Data type: NUMBER (float or integer, depending on token)
  • Business context: Used to track the fourth token’s liquidity flows, analyze four-token pool activity, and measure token-specific liquidity provision.
  • Analytics use cases: Four-token liquidity analysis, token-specific flow tracking, and cross-token liquidity studies.
  • Example: For USDC, a value of 100.0 means 100 USDC. | | TOKEN_D_AMOUNT_USD | NUMBER | The USD value of token D involved in the liquidity pool action, calculated using the token’s price at the time of the action. This field is used for pools with four tokens.
  • Data type: NUMBER (float, USD value)
  • Business context: Used to calculate USD-denominated liquidity flows for four-token pools and measure the economic impact of liquidity actions.
  • Analytics use cases: USD liquidity flow analysis for four-token pools, economic impact measurement, and value-based liquidity studies.
  • Example: 10.25 | | POOL_ADDRESS | TEXT | The address of the liquidity pool where the action is being performed. This field identifies the specific pool involved in the liquidity action.
  • Data type: STRING (base58 Solana address)
  • Business context: Used to identify specific liquidity pools, analyze pool activity, and track pool-specific liquidity flows.
  • Analytics use cases: Pool-level analysis, liquidity flow tracking, and pool performance studies.
  • Example: ‘4Nd1mYw4r…’ | | POOL_NAME | TEXT | The name of the liquidity pool where the action is being performed. This field provides a human-readable identifier for the specific pool.
  • Data type: STRING (pool name or identifier)
  • Business context: Used to identify specific liquidity pools, analyze pool activity, and track pool-specific liquidity flows.
  • Analytics use cases: Pool-level analysis, liquidity flow tracking, and pool performance studies.
  • Example: ‘SOL-USDC Pool’ | | 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 name of the liquidity pool protocol or platform (e.g., Raydium, Orca, Meteora) that manages the pool. This field enables protocol-level analytics.
  • Data type: STRING (e.g., ‘Raydium’, ‘Orca’, ‘Meteora’)
  • Business context: Used to identify the liquidity pool protocol, analyze protocol adoption, and compare protocol performance.
  • Analytics use cases: Protocol market share analysis, protocol adoption tracking, and cross-protocol liquidity studies.
  • Example: ‘Raydium’ | | EZ_LIQUIDITY_POOL_ACTIONS_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. | | TOKEN_A_IS_VERIFIED | BOOLEAN | A flag indicating if the asset has been verified by the Flipside team. | | TOKEN_B_IS_VERIFIED | BOOLEAN | A flag indicating if the asset has been verified by the Flipside team. | | TOKEN_C_IS_VERIFIED | BOOLEAN | A flag indicating if the asset has been verified by the Flipside team. | | TOKEN_D_IS_VERIFIED | BOOLEAN | A flag indicating if the asset has been verified by the Flipside team. |