AMM Liquidity Pools Registry | Ethereum EVM Blockchain Data

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-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
No deploy: internal txs show only calls like staticcall (e.g. getPair) — no create matching the pair 0xa3b1c46152f564a2c3f8a870833225360aad4c6a6feb27b1207e79349d59e55c#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

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.

​Overview

​How we recognize Liquidity Pools

​Sample Viewer

​Columns

​Use Cases

​Related Datasets

Liquidity Pools Reserves

Liquidity Pools Fee Terms

Swap Fees

Overview

How we recognize Liquidity Pools

Sample Viewer

Columns

Use Cases

Related Datasets