Documentation Index
Fetch the complete documentation index at: https://docs.blockdb.io/llms.txt
Use this file to discover all available pages before exploring further.
Overview
- Dataset ID:
0211 - Table:
blockdb_evm.b0211_liquidity_pools_v1 - Description: Canonical list of pools; child time-series tables FK to blockdb_evm.b0211_liquidity_pools_v1(pool_uid).
- Primary key:
pool_uid - API: POST /evm/entities/pools
- CSV Sample: Download
- JSON Sample: Download
How we recognize Liquidity Pools
BlockDB builds the pool registry from factory-style events (e.g. Uniswap V2-likePairCreated / pool-creation topics) decoded from chain logs, scoped to known DEX factories in our exchange metadata.
Logs alone are not sufficient. The same pair address can appear in more than one PairCreated-style log over time—for example when a factory or router path re-references an existing pair without deploying a new contract. On-chain, a real new pool is introduced by a CREATE / CREATE2 in that transaction’s trace; a follow-up transaction may only show reads (e.g. STATICCALL to getPair) while still emitting a creation-shaped log. Treating every such log as a new pool would pollute the registry.
So for address-based pools we cross-check each candidate creation log against internal transactions for the same (block_number, transaction_index) - we require a successful internal create / create2 whose deployed address matches the pair/pool address from the log before we accept it as a new pool.
Example on Ethereum mainnet (Internal Traces tab) pool address 0x397FF1542f962076d0BFE58eA045FfA2d347ACa0:
- Real deploy: internal tx shows
createand the new pool contract0x9011586359ddfc2660fe5bcdf2b53f1d4238ab4f4f998bc79a8cd69aa7c9040d#internal - No deploy: internal txs show only calls like
staticcall(e.g.getPair) — nocreatematching the pair0xa3b1c46152f564a2c3f8a870833225360aad4c6a6feb27b1207e79349d59e55c#internal
Takeaway: we use pool-creation logs as the signal, and internal transaction traces as a sanity check when traces exist—because multiple creation-shaped logs can refer to one pool, and only the trace proves a new deployment in that transaction.
Sample Viewer
Columns
| Column | Type | Description |
|---|---|---|
pool_uid | BYTEA | Stable surrogate key derived from address or pool_id (used across datasets). |
exchange_id | INTEGER | Exchange identifier (e.g., 1 for Uniswap, 2 for Sushiswap, etc.). |
type_id | INTEGER | Pool type identifier (e.g. 201 for Uniswap V2, 301 for Uniswap V3). |
block_number | BIGINT | Block number where pool was first recognized/derived. |
block_time | TIMESTAMPTZ | UTC timestamp for the block that produced this record. |
tx_index | INTEGER | Zero-based transaction index within the block. |
log_index | INTEGER | Zero-based log index within the transaction. |
factory | BYTEA | Factory/pool-manager contract address. |
tokens | BYTEA[] | Array of token addresses that compose the pool, ordered as stored on-chain. |
contract_id | BYTEA | Incarnation ID for v2/v3 pools: 20B address + 4B creation block (BE) + 2B tx_index (BE). NULL for v4-style pools. |
contract_address | BYTEA | 20B address for v2/v3-style pools (nullable for id-only v4). |
pool_id | BYTEA | 32B identifier for v4-style pools (nullable for v2/v3). |
pairnum | NUMERIC(6) | Internal index representing the slot/order of the token pair within the pool. |
asset_managers | BYTEA[] | Optional array of asset manager addresses for Balancer-style custodial pools. |
amp | NUMERIC(6) | Amplification coefficient for stable or hybrid pools (NULL for constant product pools). |
weights | NUMERIC(6,5)[] | Array of normalized token weights for weighted pools (e.g., Balancer). |
tick_spacing | SMALLINT | Tick spacing parameter for concentrated liquidity pools. |
_tracing_id | BYTEA | BlockDB lineage identifier that links this record to lineage APIs. |
_parent_tracing_ids | BYTEA[] | Tracing identifiers for upstream derived records referenced during computation. |
_created_at | TIMESTAMPTZ | Record creation timestamp. |
_updated_at | TIMESTAMPTZ | Record last update timestamp. |
Use Cases
- Building the complete DEX pool registry for routing and analytics
- Filtering pools by fee, type, or token pair
- Integrating with reserves, price, and swap datasets for liquidity intelligence
- MEV routing, arbitrage path optimization, and chain-wide pool analytics
- Constructing pool-level AI or quantitative features
Related Datasets
Liquidity Pools Reserves
Per-block reserve snapshots for these pools.
Liquidity Pools Fee Terms
Dynamic fee configurations per pool.
Swap Fees
Per-swap fee revenue across these pools.