Skip to main content
Schema: somnia.defi Table: ez_dex_liquidity_pool_actions Type: Base Table

What

This table provides a comprehensive view of liquidity pool actions across major decentralized exchanges (DEXs) on EVM blockchains. Each row represents one token in a liquidity pool action. For example, if a user adds WETH and USDC to a pool, there will be 2 rows: one for WETH and one for USDC.

Key Use Cases

  • Analyzing liquidity provision patterns and LP behavior
  • Tracking token-specific liquidity flows
  • Monitoring large liquidity additions/removals by token
  • Calculating LP rewards and impermanent loss
  • Identifying popular tokens in liquidity pools

Important Relationships

  • Join with ez_dex_swaps: Correlate LP actions with trading activity
  • Join with ez_prices_hourly: Get historical token prices
  • Self-join on ez_dex_liquidity_pool_actions_id: Group tokens from the same action

Commonly-used Fields

  • platform: DEX protocol (uniswap-v3, uniswap-v2 etc.)
  • event_name: Type of action (Mint, Burn, AddLiquidity, RemoveLiquidity, Deposit, Withdraw etc.)
  • liquidity_provider: Address providing/removing liquidity
  • pool_address: Liquidity pool where action occurred
  • token_address: Individual token in the action
  • amount: Decimal-adjusted token amount
  • amount_usd: USD value of the token amount

Sample queries

-- Top tokens by liquidity additions (last 7 days)
SELECT 
    token_address,
    symbol,
    COUNT(DISTINCT tx_hash) AS add_count,
    SUM(amount_usd) AS total_usd_added
FROM <blockchain_name>.defi.ez_dex_liquidity_pool_actions
WHERE block_timestamp >= CURRENT_DATE - 7
    AND event_name IN ('Mint', 'AddLiquidity', 'Deposit')
GROUP BY 1, 2
ORDER BY total_usd_added DESC
LIMIT 50;

-- Largest single token liquidity actions
SELECT 
    block_timestamp,
    tx_hash,
    platform,
    pool_name,
    liquidity_provider,
    symbol,
    amount,
    amount_usd
FROM <blockchain_name>.defi.ez_dex_liquidity_pool_actions
WHERE block_timestamp >= CURRENT_DATE - 7
    AND amount_usd > 0
ORDER BY amount_usd DESC
LIMIT 100;

-- Daily LP activity by platform
SELECT 
    DATE_TRUNC('day', block_timestamp) AS date,
    platform,
    COUNT(DISTINCT liquidity_provider) AS unique_lps,
    COUNT(DISTINCT pool_address) AS active_pools,
    SUM(amount_usd) AS total_volume_usd
FROM <blockchain_name>.defi.ez_dex_liquidity_pool_actions
WHERE block_timestamp >= CURRENT_DATE - 30
GROUP BY 1, 2
ORDER BY 1 DESC, 5 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.
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:
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:
LIQUIDITY_PROVIDERTEXTThe address that is providing or removing liquidity from the pool. Example: ‘0x1234567890123456789012345678901234567890’
SENDERTEXTThe address that initiated the liquidity pool action function. Example: ‘0x7a250d5630b4cf539739df2c5dacb4c659f2488d’
RECEIVERTEXTThe recipient address of the LP tokens or withdrawn assets. Example: ‘0x1234567890123456789012345678901234567890’
POOL_ADDRESSTEXTThe liquidity pool contract address where the action occurred. Example: ‘0x8ad599c3a0ff1de082011efddc58f1908eb6e6d8’
POOL_NAMETEXTHuman-readable name for the liquidity pool. Example: ‘WETH/USDC’
TOKEN_ADDRESSTEXTThe contract address of the individual token in this liquidity pool action. Example: ‘0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2’
SYMBOLTEXTThe symbol of the individual token. Example: ‘WETH’
DECIMALSNUMBERThe number of decimal places for the individual token. Example: 18
AMOUNT_UNADJFLOATRaw, non-decimal adjusted amount of the individual token in this action. Example: 1000500000000000000000
AMOUNTFLOATDecimal-adjusted amount of the individual token in this action. Example: 1000.5
AMOUNT_USDFLOATUSD value of the individual token amount at the time of the transaction. Example: 1500.75
TOKEN_IS_VERIFIEDBOOLEANWhether the individual token is verified in the Flipside token metadata. Example: true
PLATFORMTEXTThe DEX protocol and version where the liquidity action occurred. Example: ‘uniswap-v3’
PROTOCOLTEXTThe protocol used for the liquidity action. This is the clean name of the protocol without the version. Example: ‘uniswap’
PROTOCOL_VERSIONTEXTThe version of the protocol used for the liquidity action. Example: ‘v3’
EZ_DEX_LIQUIDITY_POOL_ACTIONS_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: