> ## 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.
# Liquidity Pools
> Canonical AMM liquidity pool registry — exchange, factory, token pairs, config. 10 EVM chains. REST API and bulk export.
## 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](/api-reference/evm/entities/pools)
* **CSV Sample:** [Download](https://huggingface.co/datasets/BlockDB/Liquidity-Pools-Ethereum-And-EVM-Cryptocurrency-Data/resolve/main/data/blockdb_evm.b0211_liquidity_pools_v1.csv?download=true)
* **JSON Sample:** [Download](https://huggingface.co/datasets/BlockDB/Liquidity-Pools-Ethereum-And-EVM-Cryptocurrency-Data/resolve/main/data/blockdb_evm.b0211_liquidity_pools_v1.json?download=true)
### How we recognize Liquidity Pools
BlockDB builds the pool registry from **factory-style events** (e.g. Uniswap V2-like `PairCreated` / 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 **`create`** and the new pool contract
[`0x9011586359ddfc2660fe5bcdf2b53f1d4238ab4f4f998bc79a8cd69aa7c9040d#internal`](https://etherscan.io/tx/0x9011586359ddfc2660fe5bcdf2b53f1d4238ab4f4f998bc79a8cd69aa7c9040d#internal)
* **No deploy:** internal txs show only calls like **`staticcall`** (e.g. `getPair`) — **no** `create` matching the pair
[`0xa3b1c46152f564a2c3f8a870833225360aad4c6a6feb27b1207e79349d59e55c#internal`](https://etherscan.io/tx/0xa3b1c46152f564a2c3f8a870833225360aad4c6a6feb27b1207e79349d59e55c/advanced#internal)
Non-address pools (e.g. some **V4-style** identifiers) use different discovery rules.
**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
Per-block reserve snapshots for these pools.
Dynamic fee configurations per pool.
Per-swap fee revenue across these pools.